Hubspot will not recognise & log to CRM my BCC emails from AMndrill - email

I'm using Zapier plus Mandrill to send transactional emails to customers, and want these emails to be logged to the relevant customer account in my Hubspot CRM.
Hubspot supports a BCC address that can do this, and works for my sending domain when I send BCC email directly out of Gmail - so the actual Hubspot BCC functionality works.
However, when I send email from that same domain via Mandrill, the Hubspot BCC does not work.
Comparing the address headers generated by Gmail and by Zapier/Mandrill, I can see that Zapier is creating the BCC address using 'bcc' type for the 'to' array, resulting in a secondary 'to' address for the BCC. Gmail generates an explicit 'bcc' field:
Example BCC-ed address block from Gmail
From: Richard Foxworthy <richard.foxworthy#4thparty.com.au>
Date: Sun, 1 Mar 2020 09:24:24 +1100
Message-ID: <CAGDDT9oRrteY8yek0GppMvfBiMiRNZEAZfJ4JvcpavTY_i69XA#mail.gmail.com>
Subject: testing BCC headers for hubspot
To: First_name Second_name <recipientaddress#domain.com>
Content-Type: multipart/alternative; boundary="0000000000004b1468059fbe6b8a"
Bcc: UniqueHubspotID#bcc.hubspot.com
Example BCC-ed Zapier/Mandrill address block (JSON, retrieved via Mandrill API)
{"from_name":"Vram Name","from_email":"email#domain.com","subject":"Subject line goes here","headers":{"Reply-To":"sendingaddress#domain.com","To":"recipientaddress#domain.com"},"to":{"email":"UniqueHubspotID#bcc.hubspot.com","name":""}
And here's an extract from an API log from Mandril relating to one of these emails
{
"key": "Mandrill_key_goes_here",
"template_name": "Mandrill_email_template_name",
"template_content": [
{
"content": "<h1>html content</h1>",
"name": "$main_title"
}
],
"message": {
"from_email": "sendingaddress#sendingdomain.com",
"from_name": "Sender Name",
"subject": "Subject line",
"headers": {
"Reply-To": "sendingaddress#sendingdomain.com"
},
"to": [
{
"email": "primaryrecipient#recievingdomain.com"
},
{
"email": "UniqueID#bcc.hubspot.com",
"type": "bcc"
}
I'm assuming the problem with Hubspot logging these mails is the absence of a BCC field in the email address headers.
Looking for guidance from anyone who understands these systems in better detail:
Is this actually what's causing the problem?
Any recommendations how to resolve the problem?
Thanks

I found a solution - posting it hee in case it helps others in future...
On Mandrill side its possible to set an option "Expose The List Of Recipients When Sending To Multiple Addresses" which preserves the list of recipients when there are multiple CCs or BCCs or whatever.
It turns out that by turning this on, Mandrill passes the right message header so Hubspot can recognise and log the BCCs.

Related

How to change recipient of a VACATION autoresponder mail to one in sender's mail header section [Reply-to] purely in Sieve Language?

I need to set an autoresponder that will send a message like "We got You mail! We will get back to you ASAP". The problem is that the sender of customer email is not customer itself (i.e. customer#privatemail.com), but some global mail (i.e. customerservice#marketplace.com) that contains customer private mail in the header section [Reply-to].
This is a hosted server with installed RoundCube. I can only use Sieve filters to create an autoresponder.
rule:[Autoresponder]
if allof (
header :contains "from" "#marketplace.pl",
{
vacation text:
We got You mail! We will get back to you ASAP!
.
;
}
I need to read the value of the header [Reply-To] section, set the recipient of autoresponder mail to that value and send a VACATION message. Only in Sieve language.

Test "Received" email header in sieve

Here is an example of how I have configured sieve to forward any mail sent to [nameA|nameB|nameC]#example.org to my private email address.
if address :localpart :is ["To","Cc","Bcc"]
["nameA", "nameB", "nameC"] {
redirect "<my private email address>";
stop;
}
Sometimes though, email is not forwarded because the address that it was sent to is tucked away somewhere in a "Received" header.
Received: from ###server### ([###ip_address###])
by ###server### with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
(Exim 4.84)
(envelope-from <###email_address###>)
id 1alDM0-0000yT-60
for nameA#example.org; Wed, 30 Mar 2016 12:28:00 +0200
Is there an effective way to catch these emails in the sieve rule, too?
You have an XY Problem here. What you actually want to do here is filter based on the address being delivered to, not the address in the headers. (As unintuitive as it may be, the address in the headers may have nothing to do with the address it's being delivered to, which is how Bcc can work at all.)
The command to test against the actual SMTP envelope is envelope.
require "envelope";
if envelope :localpart :is "to" ["nameA", "nameB", "nameC"] {
redirect "<my private email address>";
stop;
}
This will handle all mail being delivered to those names, regardless of whether they show up in the mail headers or not.
With the help of the sieves' index feature you can parse the recipient address out of the Received headers.
For BCC sorting I typically do something like this:
require ["fileinto", "envelope", "variables", "mailbox", "index", "subaddress"];
...
if header :index 3 :matches "Received" "*<*#example.com>*" {
set :lower "foldername" "${2}";
fileinto :create "inbox.${foldername}";
} elsif header :index 2 :matches "Received" "*<*#example.com>*" {
set :lower "foldername" "${2}";
fileinto :create "inbox.${foldername}";
}
...
In the Received headers of the mails I receive the adress is set in angle brackets and that's why I've chosen the pattern in the example above.
Additionally, sometimes the number of Received headers varies thus I test at least for two different ones.

How to add addresses to the BCC field using Rebol's SEND function?

I'm trying to send an email using SEND in Rebol 2:
send foo#bar.com "A Message"
How do I BCC a second address? I've tried the following without success:
send/header foo#bar.com "A Message" make system/standard/email [
BCC: baz#bar.com
]
This still goes to the first recipient, but not the BCC address. Is this a misunderstanding of how BCC works?
Also, using a custom header no longer copies part of the message for the subject line, but not so worried about that...
The correct way for BCC is to put the same address to TO as well:
send/header [
test1#example.com test2#example.com
] "A Message" make system/standard/email [
bcc: test2#example.com
]
You TRACE/NET ON to see the difference with and without adding TO.
And here you can find a similar question:
Sending BCC emails using a SMTP server?

Send email to address alternate from "To:"

I am implementing a sort of dynamic mailing-list system in Rails. I am looking to basically send an email and have the recipient receive it in this form:
From: person#whosentthis.com
To: mailing-list#mysite.com
<body>
Basically, the challenge is how do I send an email to an address while defining a different To: header so that they can easily reply to the mailing list or just the original sender?
Mail vs. Envelope
In emails as in physical mails (paper sheet in paper envelope), the recipient on the envelope may differ from the recipient on the letter sheet itself.
As the mailman would only consider the envelope's recipient, so do mail servers.
That means, one actually can tell the smtp service to send and email to a recipient different than the one listed in the To: field of the emails header.
Trying This Out Manually
You can try this out, manually, for example, by using the sendmail command of postfix.
# bash
sendmail really_send_to_this_address#example.com < mail.txt
where
# mail.txt
From: foo#example.com
To: this_will_be_seen_in_the_to_field_in_email_clients#example.com
Subject: Testmail
This is a test mail.
This will deliver the email to really_send_to_this_address#example.com, not to this_will_be_seen_in_the_to_field_in_email_clients#example.com, but the latter will be shown in the recipient field of the mail client.
Specifying the Envelope_to Field in Rails
The ActionMailer::Base internally uses the mail gem. Currently, Apr 2013, there is a pull request, allowing to specify the envelope_to field on a message before delivery.
Until this is pulled, you can specify the fork in the Gemfile.
# Gemfile
# ...
gem 'mail', git: 'git://github.com/jeremy/mail.git'
You need to run bundle update mail after that, and, depending on your current rails version, maybe also bundle update rails in order to resolve some dependency issues.
After that, you can set the envelope recipient of a mail message like this:
# rails
message # => <Mail::Message ...>
message.to = [ "this_will_be_seen_in_the_to_field_in_email_clients#example.com" ]
message.smtp_envelope_to = [ "really_send_to_this_address#example.com" ]
message.from = ...
message.subject = ...
message.body = ...
message.deliver
Documentation
https://github.com/mikel/mail/pull/477
http://rubydoc.info/github/jeremy/mail/master/Mail/Message#smtp_envelope_to%3D-instance_method
https://github.com/mikel/mail
Why not use the BCC header for this? Put person#whoshouldreceivethis.com into BCC and mailing-list#mysite.com into TO.
Clearification:
There is no technical solution for this. The email headers do what they do, you can't influence them in that once the email is on the way.
I am sure, though, you can find a combined use of TO, CC, BCC and REPLY-TO that gives you what you want.

In SMTP, must the RCPT TO: and TO: match?

When sending an email, the recipient list is given during the SMTP dialogue through RCTP TO: command. Later, in DATA command, header fields like 'To', 'Cc','bcc' are indicated. Does this RCPT TO list of recipients have to match with the headers indicated in DATA command?
Also, if the recipient is not indicated in RCPT TO, but in the To field of email header, is it going to be delivered to the recipient not in RCPT TO?
No, they don't have to match. When the message is sent, the SMTP Server (aka Message Transfer Agent or MTA) is creating a so called SMTP envelope which contains the recipients and the sender of the message (see RFC5321):
SMTP transports a mail object. A mail object contains an envelope and content. The SMTP envelope is sent as a series of SMTP protocol
units (described in Section 3). It consists of an originator
address (to which error reports should be directed), one or more
recipient addresses, and optional protocol extension material.
It is, actually, quite often that the RCPT TO: Command has more recipients that the header of the message - one common case is the usage of "blind copies" bcc: (see RFC5321):
Addresses that do not appear in the message header section may appear
in the RCPT commands to an SMTP server for a number of reasons. The
two most common involve the use of a mailing address as a "list
exploder" (a single address that resolves into multiple addresses) and
the appearance of "blind copies".
Does this RCPT TO list of recipients have to match with the headers
indicated in DATA command?
Nope.
if the recipient is not indicated in RCPT TO, but in the To field of
email header, is it going to be delivered to the recipient not in RCPT
TO ?
The RCPT. Here's a (modified) transcript from my own SMTP client where I do just what you ask:
CLIENT: MAIL FROM:<myaccount#gmail.com>
SERVER: 250 2.1.0 OK
CLIENT: RCPT TO:<myaccount#gmail.com>
SERVER: 250 2.1.5 OK
CLIENT: DATA
SERVER: 354 Go ahead
CLIENT: Subject: Test email
CLIENT: From:'John Doe'<fakeaccount#gmail.com>
CLIENT: To:'John Doe'<fakeaccount#gmail.com>
CLIENT: This is a test...
CLIENT: .
The message was successfully sent to "myaccount#gmail.com".
SMTP protocol (RFC 2821) states the following:
When RFC 822 format [7, 32] is being used, the mail data include the
memo header items such as Date, Subject, To, Cc, From. Server SMTP
systems SHOULD NOT reject messages based on perceived defects in the
RFC 822 or MIME [12] message header or message body.
And this:
The DATA command can fail at only two points in the protocol
exchange:
If there was no MAIL, or no RCPT, command, or all such commands
were rejected, the server MAY return a "command out of sequence"
(503) or "no valid recipients" (554) reply in response to the DATA
command. If one of those replies (or any other 5yz reply) is
received, the client MUST NOT send the message data; more
generally, message data MUST NOT be sent unless a 354 reply is
received.
From these statements, the headers and RCPT TO: command content does not have to match (altough they should match), and not using RCPT TO: MAY result in an error to prevent proceeding with DATA command.