Set email headers so bounced emails go to a specific address

Question

From our rails app we send out some system-generated emails with the 'from' address set to [email protected]. If these bounce they get sent back to this address by our mail server. However, what i'd like to do is to not have bounced emails get sent back to [email protected] but to a different address, such as [email protected].

Is there a header or something i can set in the email that will achieve this, without me having to go and investigate the vagaries of our email server? We send the mails out using exim in case that's relevant.

cheers, max

Solution 1

I just figured this out myself in exim4 after a lot of reading about exim configuration.

First, you want your app to add the following header:

Return-Path: <[email protected]>

Works with or without brackets. Exim will add brackets in the end either way.

Second, this was the hard part. Exim always wanted to override my Return-Path: address with the unix user who sent it. You can use /etc/email-addresses in Ubuntu to set a static email for the user of your web app, but this still ignores the Return-Path header. Here is how I modified my exim config to respect the Return-Path from the web app:

In the main config area add:

return_path_remove = false

In the appropriate router config (e.g. dnslookup):

dnslookup:
  # ...
  errors_to = ${if def:h_return-path: {${address:$h_return-path:}} fail}
  headers_remove = return-path
  no_more

Now exim should copy the Return-Path header address at the envelope-level and delete the original Return-Path header.

I tried lots of other configuration directives and this is the only way that actually worked for me.

Solution 2

3 years too late, but just in case anyone else comes this way. Return-Path is the right header but, as James Garriss pointed out above, it has to be placed there by the site performing final delivery. You can't just stick it in yourself.

If you're writing emails by connecting directly to an SMTP server then this is easy - the MAIL command contains the return path. If you send

MAIL FROM:<[email protected]>

to the SMTP server then bounces will be returned to [email protected].

If you're not constructing SMTP, and you're running an MTA (ie. exim/etc), then you have to find a command-line switch for your MTA. For sendmail, -f [email protected] "sets the sender's address", and this ends up as the Return-Path in the final delivered mail, and [email protected] will get the bounces (I do exactly this for auto-generated emails). I haven't tried this on exim, but it has exactly the same option, and it should work.

Solution 3

Return-Path header is written by the receiving server, not by the sending server. And as per the RFC 5321, it is the same as the address supplied in MAIL FROM command.

Even if you set the Return-Path header yourself, the receiving server will overwrite that.

Now, here's the thing, the address in the MAIL FROM command and the address in the From header can be different. The receiving user does not see the MAIL FROM address. They only see the From header address.

So, if you want to ignore the bounces or want them to go to a specific address, you should use that address in the MAIL FROM command.

But in the From header, you can just use [email protected] - the user will see this address.

---

To simplify a bit more, you send the email from [email protected] address. The receiving server will send the bounces to this address.

To show your user the [email protected] address instead of handle_bounce... address, set the From header in the raw email MIME message to the noreply... address.

---

I recently got a no-reply email from Bitbucket. Here's the raw message:

Return-Path: <[e-mail]>
From: "Atlassian Bitbucket" <[email protected]>
To: <[email protected]>
Subject: Continuous delivery, without the headache.
Date: Wed, 28 Feb 2018 12:40:53 -0600
MIME-Version: 1.0
Reply-To: "Atlassian Bitbucket" <[e-mail]>

... message body ...

As you can see, the Return-Path is an address dedicated to handle bounces. But the From address is a noreply@... mail. What that means is this email was actually sent by this bounce handling address, not by the noreply address.

You can also see the Reply-To header, which is dedicated to handle replies, if a user replies to no-reply emails. Those replies are probably discarded right away.

Solution 4

Errors-To is deprecated, so mail servers will typically ignore this header - most servers will bounce will to the 'envelope sender'.

This is the email address that your mail client sends as part of the connection to the SMTP server (not necessarily the From address - though it typically is the same).

I don't know Rails all that well, but I found this - although, as far as I can tell Return-Path is reset by MTAs to match the MAIL FROM information from the client, so it seems you can't actually set it.

I think the only thing you can do is set the bounce address in your server.

Solution 5

Here is the solution:

In the email header you can set:

From: "From Name" <[email protected]>
Reply-To: [email protected]

Errors-To: <[email protected]>
Return-Path: <[email protected]>

View more solutions

Comments

[Max Williams]

Ah, i've not seen the Errors-To header before. I've already tried Reply-To and Return-Path to no avail. I'll give it a go...

[Max Williams]

That didn't work either Dmitriy (sorry for the slow response) - i can see the Errors-To header in the original mail but it still bounces back to the from address.

[Scherbius.com]

that means you are doing something wrong. Please check headers of the outgoing emails. Return-Path, Errors-To: and also "envelope-from" and "X-Env-Sender:" should have the same email address (where you would like bounced emails to be routed.) Last 2 items are added automatically by server. Case sensitivity matters (strings in header need to be exactly like in my code example). Best regards.

[Max Williams]

Thanks Horuskol - would mail providers actually honor that bounce address though? I thought that they tended to ignore everything and always send bounces to the from address.

[HorusKol]

@MaxWilliams - yeah, you're probably right now I think about it more

[JdeBP]

What xe is doing wrong is following your erroneous advice to set the Errors-To: header. This is a non-standard header, used for UUCP mail, that is deprecated and that has no functionality outwith UUCP. Only three Internet MTS softwares out of the many in use in the world have ever even recognized it. In the first, its functionality has been disabled as standard since V8.8, released in the mid-1990s. In the second, the functionality was outright removed seven years ago. In the third, it has never been used in the part of the MTS that bounces messages.

[Scherbius.com]

to JdeBP: I'm not sure that you even know what are you talking about. Just copypasting some article. My Answer is based on practical experience. My employer uses that way of routing bounces for last 2 years. Undeserved negative vote.

[james.garriss]

This should not work. Not because you haven't figured out how to set the Return-Path in Exim, but because it will be overridden by the delivery SMTP server. From RFC 5321 Section 4.4: "When the delivery SMTP server makes the final delivery' of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in the <reverse-path> from the MAIL command."

[james.garriss]

Errors-To is non-standard and systems are discouraged from using it. That said, there are some who still do. But because so few systems support it, it should not be considered reliable outside your own organization. It's not a good choice.

[Max Williams]

thanks for this EML. Can i set the failed return address to be different to the from address using this method?

[EML]

@MW: yes, no problem - they're different things. Just set From: in your headers as you want the recipient to see it, and set the -f address (ie. the 'envelope'/etc address) as required for bounces. One caveat: the MTA might suspect a security violation, and insert an extra header in the received email (X-Authentication-Warning) to warn the recipient. This depends on your exact MTA setup. The sendmail book has a whole page on avoiding this. If your recipients see this header, and you want to get rid of it, you should probably ask another question.

[Jasen]

Return path is informational only. when it message is received it tells the recipient where a bounce would have gone. it doesn't actually do anything. as yut say -f after /usr/lib/sendmail to sent the sender is the correct answer. some implementations of /usr/lib/sendmail may interpret a 'return-path' header as equivalent.

[Coisox]

In org.apache.commons.mail.Email package, it got setBounceAddress() function. I've tested that function and it doesn't works; proofing that ur claim is right. So what is that function suppose to do if we can't set at sending server?

[xyres]

@Coisox Sorry, I have no experience in using Apache Commons Mail.

[steev]

You can definitely set the Return-Path header as a sender. But yes, some receivers might rewrite it (But not always ), or depending on who you're sending through, it might be re-written by them. For instance when using MailGun to send bulk email you have to do things just right in order to set a Return-Path that will be preserved. I know this contradicts the RFC you cite, but it's in practice true.

[xyres]

@steev Recieving server will overwrite the return path (those which don't are a result of incomplete implementation of the RFC and I wouldn't be surprised if that should change in future without notice). If it works with mailgun, my guess is they, in background, use the return-path's value for the mail-from command which is what I mentioned in the answer. Sorry, it's not in practice true. What it is, is unreliable.

[steev]

@xyres it is both in practice true, and, yes, unreliable. YMMV. :) At the end of the day, the best practice would be to set Mail-from and Return-path and Reply-to and hope that one of them will work. That's just the way things go, there are non-compliant ESPs out there. You can complain and be a purist about RFCs or you can adapt to reality.

[xyres]

@steev Setting Return-Path may or may not work, but MAIL FROM always works. And that's the point I've made in the answer. You're arguing just for the sake of arguing. BTW, Mailgun is a sending service. You can't possibly "do things just right" to preserve Return-Path header because, as you've admitted, the receiving MTAs may or may not overwrite it.