What is the behavior difference between return-path, reply-to and from?

Question

On our mailing application we are sending emails with the following header:

FROM: [email protected]
TO: [email protected]
Return-PATH: [email protected]

The problem that we are facing is that some email servers will bounce back a message immediately and use the from or reverse path ([email protected]) 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.

Solution 1

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: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

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 [email protected]. 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:<[email protected]>
{S}250 2.1.0 [email protected] OK
{C}RCPT TO:<[email protected]>
{S}250 2.1.5 [email protected]
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

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: [email protected]
From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.

Now, let's describe the different "FROM"s.

1. 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.

2. 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.

3. 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.

Solution 2

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.

Solution 3

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.

Solution 4

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: [email protected] 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.

View more solutions

Comments

[PapaFreud]

What about specifying Sender: and Precedence: fields? I'd like to know more about how they affect different mail servers when it comes to bounces and out of office-type autoreplies. Anybody?

[Accountant م]

postmastery.com/blog/about-the-return-path-header

[dave wanta]

Hi Geo, Yes. It is entirely possible. There are plenty of broken SMTP servers out there, or that at least interpret the rules differently. Cheers! Dave

[sl3dg3]

Thx for the great explanation. One question about the return-path: Do I understand it right that when the mail leaves my SMTP (as a sender of the mail), there is actually not yet any return-path defined? Does only the recipient's mail server add the return-path to the mail?

[dave wanta]

well, technically you can (but aren't supposed to) add a return-path header, however, if a return-path header exists, it is to be overwritten by the recieving smtp server. If none exists, it is to be added at the top of the headers.

[greatwolf]

I'm a bit unclear about how return-path is used. If return-path is meant to be a return address, why would the recipient's mail server fill this field in instead of the sender? How would the recipent's server even know what to put in there? Doesn't this seem backwards?

[John Hascall]

The recipient's mail server inserts the Return-Path header into the message by copying the value supplied by the sender's mail server in the SMTP "MAIL FROM" command. Imagine a clerk in the mail room opening mail -- they look at the return address on the envelope and write that across the top of the letter (and throw the envelope away).

[Abhishek]

@Jesse Hobart +1 for nice explanation , I was more confused thank you for making it easier to understand me .

[Simon East]

And how does the Sender: header fit into all this?

[MrCalvin]

The "Return-Path" seem to be officially called "MAIL FROM" identity!!! E.g. in RFC 4408.

[cdhowie]

I would point out that the primary concept not captured in this analogy is that the Return-Path header is added by the receiving mail server and not by the sender. So it's more like this: you can write whatever address you want inside of the envelope, but to deliver it you have to take it to the post office and show them your drivers license (or other ID) and they put that address on the envelope before sending it. In other words, the Return-Path header is as trustworthy as the checks performed by the receiving SMTP server, where the others can be easily spoofed.

[adrianTNT]

To sum up the above answer: bounces should be returned to return-path header value, but some servers (that do not comply with standards) send to the From address.

[x-yuri]

Can an email go through a number of servers? If yes, than Return-Path added by the recipient's server (the last one in the chain) will allow it to send a bounce. What about the rest of the servers? How will it propagate to the sender's server?