I missed a couple of important e-mails while I was in Norway this past week. Although I was checking my metalab.unc.edu e-mail at least once a day, several important responses somehow went to my GMail address instead, which I was not checking. I found them when I got home and opened my Gmail account yesterday.
At first I was perplexed, because I do not usually set my return address to GMail. Then I remembered that on the road I was using the GMail SMTP server to send, because the Speakeasy server I normally use only works from my local area network behind my router. Could GMail be rewriting my headers? So I did some experiments.
I sent e-mail to my UNC address from my laptop using the GMail SMTP server. I verified that the return address I was sending out was firstname.lastname@example.org. The message came through quickly and I received it on my desktop. It indeed seemed to come from email@example.com as it should. Then I hit “Reply”. The reply that opened was addressed to “firstname.lastname@example.org”. Weird. Had Google inserted a Reply-to header before forwarding my mail?
In fact, it had added a Return-Path header:
The From header appeared untouched, and there was no Reply-to header. Checking RFC 2821, I see that:
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
from the MAIL command. Here, final delivery means the message has left the SMTP environment. Normally, this would mean it had been delivered to the destination user or an associated mail drop, but in some cases it may be further processed and transmitted by another mail system.
So it seems like Google is indeed following the spec by setting the Return-Path header. However, reading further on in the RFC we find:
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent.
RFC 2822 also clearly states:
In the absence of the “Reply-To:” field, replies SHOULD by default be sent to the mailbox(es) specified in the “From:” field unless otherwise specified by the person composing the reply.
In other words, the return path is only for automatic responses, such as “No such recipient”. It is not for deliberate replies composed by a human being. It is, in other words, not the reply-to address. If the Reply-to header is not set, the response should be sent to the From address, not to the Return-path. There is a bug here but it is in Thunderbird, and presumably other e-mail clients my correspondents were using. I have reported it to the Thunderbird Project as Bug #396273.
The workaround is to explicitly set the Reply-to address as well as the From address. For example, in Thunderbird go to Tools/Account Settings/user@host/:
The Reply-to header does override the Return-path header, at least in Thunderbird.