I'm trying to figure out how to send mails using the MailGun Golang API without having it sent 'on behalf of'.
This is how the From address currently looks (where foo.com is the sender's email domain and bar.com is my domain):
john=foo.com#mail.bar.com on behalf of John Smith <john#foo.com>
What do I need to do so that it looks like this instead:
John Smith <john#foo.com>
I've set up SPF and DKIM according to the MailGun instructions and everything passes as being correct. I've also used SetDKIM(true) when I'm sending out the mail. Is there some setting I'm missing or additional validation I need to do?
You need to set the sender property in the email header to the from address as well most likely.
I had this same problem using NodeMailer for a node.js project. Gmail and Thunderbird would show the from address fine but Outlook would show the from address as
emailname=example.com#mail.example.com on behalf of emailname#example.com
When I looked into the full email message header I saw that the sender: in the header was emailname=example.com#mail.example.com and the from: was emailname#example.com
we looked into the spf and dkim records at first thinking it was an issue there but they were fine and in the email header it even said spf and dkim both were passing so then i noticed the sender header was different than the from and Outlook pays attention to that where gmail and thunderbird don't care as much.
Try setting the sender header to the from value.
Here is a sample of part of one of the wrong email headers edited to match example above
Received-SPF: pass (google.com....
Authentication-Results: mx.google.com;
dkim=pass header.i=#mail.example.com;
spf=pass (google.com.....
Sender: emailname=example.com#mail.example.com
From: Persons Name <emailname#example.com>
make Sender equal to Sender: Persons Name <emailname#example.com>
To add to Dhodgin's answer:
The on behalf of message comes up if you're using a subdomain in MailGun such as mail.bar.com and the from email address is using a different domain such as john#foo.com
To fix this issue add a custom MIME header "sender" and set it to be the same as the from email address.
To add a custom header using the MailGun api make sure to add a h: prefix such as:
request.AddParameter("h:sender", "John Smith <john#foo.com> ");
Have you added an mg sub domain?
If you have added a sub-domain such as #mg.domain.com then make sure you send your emails from name#mg.domain.com
I had the same problem, as I didn't realize that I wanted to have the sender address name#domain.com but I had added - as recommended - a subdomain to mailgun: mg.domain.com.
So when I tried to send an email from name#domain.com I got "on behalf of" / "sent by" but as soon as I've used the subdomain name#mg.domain.com - the "on behalf" message is gone... stupid me...
Are you trying to send from a different domain than the one you setup SPF/DKIM on?
You can only send white-labelled emails from the domain you're authorized with Mailgun.
For those using SMTP in mailgun subdomain. Set the "From" and "Sender" parameter. eg
message["From"] = 'John Smith <john#foo.com>'
message["Sender"] = 'john#foo.com'
Related
In my Mailchimp account I successfully verified my domain and I also authenticated it with valid DKIM and SPF records (the domain is only an example):
When sending campaings I set the From address to be info#mywebsite.com.
But headers of received email (Gmail) show:
from: info#mywebsite.com
reply-to: info#mywebsite.com
mailed-by: mail70.atl91.mcsv.net
signed by: mywebsite.com
Is it possible to show mywebsite.com also for the mailed by header?
mail70.atl91.mcsv.net is maybe the hostname of mailchimp this is why it goes in the header of the email and gmail automatically identifies that this email is coming form this from domain and there is no way to chnage that.
In simpler words this is not possible to remove mail70.atl91.mcsv.net.
If you wish to remove it you will have to steup your own mail server which is normally not very difficult
We have an app that sends emails on behalf of our clients. All emails are sent via Sendgrid. As part of this we have verified our email sending domains via DKIM and SPF.
When our clients send email, it is constructed as follows:
from: Tom Smith <email-service#ourserver.com>
reply-to: tom.smith#email.com
This works in the vast majority of cases, but there are situations where the "reply-to" is not being respected - recipients are clicking "Reply" in their email clients and the reply is coming back to us.
Is there something that we are missing here. Do we need to explicitly set a FROM or SENDER header? Or something else?
I have multiple domains which I receive e-mail for and have set up my mailserver to deliver it all to a single mailbox for convenience, example below:
comment#myblog.com
contact#mybusiness.com
admin#mywebsite.com
They all come to me at my single mailbox:
ian#me.com
When I reply to these e-mails the reply-to address will be:
ian#me.com
I would like to automatically have postfix change that reply-to address, based on the address that the e-mail was originally sent to, so for example:
Email is sent to me at: comment#myblog.com
I reply from: ian#me.com
I want the reply-to to be: comment#myblog.com
Is there a way to automate this with postfix?
Thanks in advance.
It is doable in postfix anyway. But it requires some programming to parse the mail to determine the recipient email address and add Reply-To header from that value. You need to use an external content filter or a Milter application. But I dont think it is a cleaner way.
I would rather say that setting Reply-To header should be done by the MUA eg. (Thunderbird, Outlook etc ) instead of Postfix MTA. For eg. in Thunderbird, If you receive all your emails for
comment#myblog.com
contact#mybusiness.com
admin#mywebsite.com
at ian#me.com, then you can add identities for all the email addresses above( You can set your Name, Email address, Reply-To address etc). So when you reply to an email sent to comment#myblog.com, then the Reply-To address will be set to comment#myblog.com. For Thunderbird, you have to add identities by clicking Edit -> Account Settings -> Manage Identities. More info here. All MUAs should have this option of managing identities.
Hope that helps.
On our mailing application we are sending emails with the following header:
FROM: marketing#customer.com
TO: subscriber1#domain1.example
Return-PATH: bouncemgmt#ourcompany.example
The problem that we are facing is that some email servers will bounce back a message immediately and use the from or reverse path (marketing#customer.example) instead to our bounce mgmt server. We want to know if we modify in the header the reply-to to be the same as the return-path if we will be able to catch all bounces.
Any other ideas are welcome?
We are using the following documents as references:
VERP
RFC
Bounce Messages
SMTP Log Parsing to get Bounces
EDIT 1: A few more bits of information to see if we can get this resolve.
We want to know at what point the email server relaying the message will choose to use the reply-to versus the return-path. We have notice that when the first SMTP server relaying the message gets rejected it sends it to the reply-to, but when it happens after one hop it sends it to the return-path.
Let's start with a simple example. Let's say you have an email list, that is going to send out the following RFC2822 content.
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's say you are going to send it from a mailing list, that implements VERP (or some other bounce tracking mechanism that uses a different return-path). Lets say it will have a return-path of coolstuff-you=yourcompany.com#mymailinglist.example. The SMTP session might look like:
{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com#mymailinglist.example>
{S}250 2.1.0 me#mycompany.com....Sender OK
{C}RCPT TO:<you#example.com>
{S}250 2.1.5 you#example.com
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
.
{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel
Where {C} and {S} represent Client and Server commands, respectively.
The recipient's mail would look like:
Return-Path: coolstuff-you=yourcompany.com#mymailinglist.example
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's describe the different "FROM"s.
The return path (sometimes called the reverse path, envelope sender, or envelope from — all of these terms can be used interchangeably) is the value used in the SMTP session in the MAIL FROM command. As you can see, this does not need to be the same value that is found in the message headers. Only the recipient's mail server is supposed to add a Return-Path header to the top of the email. This records the actual Return-Path sender during the SMTP session. If a Return-Path header already exists in the message, then that header is removed and replaced by the recipient's mail server.
All bounces that occur during the SMTP session should go back to the Return-Path address. Some servers may accept all email, and then queue it locally, until it has a free thread to deliver it to the recipient's mailbox. If the recipient doesn't exist, it should bounce it back to the recorded Return-Path value.
Note, not all mail servers obey this rule; Some mail servers will bounce it back to the FROM address.
The FROM address is the value found in the FROM header. This is supposed to be who the message is FROM. This is what you see as the "FROM" in most mail clients. If an email does not have a Reply-To header, then all human (mail client) replies should go back to the FROM address.
The Reply-To header is added by the sender (or the sender's software). It is where all human replies should be addressed too. Basically, when the user clicks "reply", the Reply-To value should be the value used as the recipient of the newly composed email. The Reply-To value should not be used by any server. It is meant for client-side (MUA) use only.
However, as you can tell, not all mail servers obey the RFC standards or recommendations.
Hopefully this should help clear things up. However, if I missed anything, let me know, and I'll try to answer.
Another way to think about Return-Path vs Reply-To is to compare it to snail mail.
When you send an envelope in the mail, you specify a return address. If the recipient does not exist or refuses your mail, the postmaster returns the envelope back to the return address. For email, the return address is the Return-Path.
Inside of the envelope might be a letter and inside of the letter it may direct the recipient to "Send correspondence to example address". For email, the example address is the Reply-To.
In essence, a Postage Return Address is comparable to SMTP's Return-Path header and SMTP's Reply-To header is similar to the replying instructions contained in a letter.
for those who got here because the title of the question:
I use Reply-To: address with webforms. when someone fills out the form, the webpage sends an automatic email to the page's owner. the From: is the automatic mail sender's address, so the owner knows it is from the webform. but the Reply-To: address is the one filled in in the form by the user, so the owner can just hit reply to contact them.
I had to add a Return-Path header in emails send by a Redmine instance.
I agree with greatwolf only the sender can determine a correct (non default) Return-Path.
The case is the following:
E-mails are send with the default email address: admin#example.com
But we want that the real user initiating the action receives the bounce emails, because he will be the one knowing how to fix wrong recipients emails (and not the application adminstrators that have other cats to whip :-) ).
We use this and it works perfectly well with exim on the application server and zimbra as the final company mail server.
I'm working on a web application. A user will create an email message that will be sent to another person.
I would like the e-mail that gets sent to appear from the user's name and e-mail address of the user on my system. And if they reply to the e-mail then it should go directly to the sender's email address.
However I am worried about the email message looking like spam to email filters along the way.
Is there a proper way to do this?
I noticed on a "contact" page on a WordPress blog that something very similar is done. The e-mail headers look like:
To: email#domain.com
Subject: [Test Blog] =?UTF-8?B?aGVsbA==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From:=?UTF-8?B?aGVsbA==?=<sender#senderdomain.com>
Message-Id: <20090207234737.39C9522802F3#web7.sat.wordpress.com>
Date: Sat, 7 Feb 2009 23:47:37 +0000 (UTC)
Return-Path: donotreply#wordpress.com
What is interesting is that the display name in the "from" tag and the name that shows up in the subject line is encoded. I do not know if this helps with the spam filters or not, but thought it was at least worth mentioning.
Also, who would receive an undeliverable notification in this example? Would it go to sender#senderdomain.com or would it go to donotreply#wordpress.com?
Basically all you need to do is set the From header to the email address of the user sending the email. The value of From is what is displayed in a recipient's email client. Most spam detection systems in place today look only at the message content, not the email headers, so you currently wouldn't have that much of a problem based on what you set the From header to.
However, there are some systems which are gaining popularity which could prevent you from sending email with somebody else's email address - most notably SPF, the Sender Policy Framework Basically, a mail server that implements SPF will check the domain of the From address of each email it receives and check with that domain directly to see if it authorizes the email. For example, if your server is mydomain.com, the email address of the user is abcdef#gmail.com, and the recipient is blah#example.com,
mydomain.com contacts example.com via SMTP to try to send the email
example.com looks up the SPF records for gmail.com
example.com checks whether mydomain.com is on the list of domains allowed to send email with the domain gmail.com
If it's not, the email is blocked
Also, I found a forum post suggesting that Return-Path is the intended destination for undeliverable notifications. Apparently that header is set based on the value of the SMTP MAIL FROM command.
Setting email fields is generally trivial, but the exact method of doing so depends on the language and framework you are using, which you don't mention. Usually it is a matter of creating a new email object, and just doing something along the lines of:
email.from = "From Name <fromemailaddress#example.com>";
You can set the specific from address to your user's, if you like, it is not at all uncommon though I personally am not a fan. You could also set the from field to something like: "Sender Name (via Your Site Name) <yourresponseaddress#example.com>".
Don't do this.
It really depends on how your mail relay is set up, but actually just don't do it. From header should contain the email address that sent the email, in your case webmaster#whatever.com. If you want people to reply to a different address, you can always use the Reply-To header. Here are some notes.
If I understand the standard (RFC 822) correctly, this is exactly what the Sender header is for (see §4.4.2. SENDER / RESENT-SENDER). Still, I'd go with a different approach and use your sites official contact address in the From header and put the user's address in the Reply-To header. Maybe add some boilerplate text that clearly states where the mail is coming from.
One further advice besides the technical stuff: don't let anonymous users use this facility, you'd become a perfect platform for spamming. Also, out of kindness, you probably want to make sure that your (registered) users know that their email addresses are exposed to the recipients.
Be aware that doing this will make spam filters more suspicious of your email. Combined with suspicious looking content your email may get filtered.
Whoever is in the "From" header will receive the undeliverable notification.
For the filtering - it really depends more on the subject and body of your message than the From address. So with that said, a couple ideas....
Use HTML encoding rather than Plain Text with simple formatting (I know there's probably an argument going the other way but in my personal experience HTML gets through more often)
Always include a footer with ("This e-mail was sent to you from ... blah blah") to identify it; if you don't want people to know it's coming from your system (i.e. really impersonated from the "From" user) then you need to find a more legit way to take care of the requirement.
If at all possible, use a real address from your system as the "From" address with the address of the user as the "Reply-To".