RFC822 on Return-Path::

This field is added by the final transport system that delivers the message to its recipient. The field is intended to contain definitive information about the address and route back to the message's originator.

So how come some e-mails have two of them? (In my sample, usually one at the end and one at the start, from which I assume that client added it there.) Isn't there only one originator?

Is that a bad habit of some clients?

  • in case those emails are spam, it is just the same reason as why some spammers fake Received: headers - to make life harder for those who try to file abuse complaints. (The one at the top is the correct one, at least for all email software I know of.) Some mail servers will not write a Return-Path header though, but if that happens to you, just switch email provider :)
    – mihi
    Jan 20 '12 at 17:46
  • @mihi Fortunately, these samples are just for testing, but not all of them are spam. (Though all contain same two fields the same way, which does not confuse me so much as they may all have passed same path to some extent, back in their old days.) Thanks, though :) Jan 20 '12 at 18:01

You are 30 years behind. RFC 822 has been superseded twice over.

… and the supserseding documents, whilst still somewhat flawed, do attempt to explain what RFC 822 either allowed for that the world decided not to do or outright got wrong.

Isn't there only one originator?

The Return-Path: and Delivered-To: headers do not denote originator and recipient. They contain the message envelope after a message has left the SMTP environment and is thus no longer broken down into envelope and content — as it does when a local delivery agent writes message envelope and message content into a mailbox file at point of local delivery.

Is that a bad habit of some clients?

It's a bad habit of the MUA or MTA that sent the message, or of some intermediate gateway out of the SMTP environment. The topmost trace fields will almost certainly have been added by your local delivery agent. Those further down were added by something else. Your LDA is free to remove existing envelope headers when prepending its own. But it is not required to and clearly it does not.

Further reading

  • Great, thanks! (And: Good guess, it's been a while since I read up on SMTP. I think I was...2? :D) Jan 22 '12 at 17:20

The Return-Path would normally be added at the top at the time the email is received. Specifically it would happen during the SMTP transmission of the "MAIL FROM" command. It may not be the same as the email address in the From:, Reply-To:, or Sender: headers. If there is a second Return-Path at the bottom, it would most likely be suspect, probably added after delivery is already complete.


It's either bad client habits, or spam.

You can determine if it is the latter by examining the contents and the rest of the headers.

Return-Path is one of the few headers the MTA will check for, and that the delivering MTA SHOULD remove and replace with its own.


Some emailing accounts can have the option to send email 'On-behalf-of...' which would use a different server to route the emails through. This would then involve multiple emails in reply. Otherwise a different example could be if a php application sends emails through a server - you can specify a return address or addresses (sometimes you can even spoof a reply address).

Obviously the best habit would be to have your clientele to post only one reply address for locating emailing transactions and other debugging tasks (if required).

" Once the transmission channel is established and initial handshaking
   completed, the SMTP client normally initiates a mail transaction.
   Such a transaction consists of a series of commands to specify the
   originator and destination of the mail and transmission of the
   message content (including any headers or other structure) itself.
   When the same message is sent to multiple recipients, this protocol
   encourages the transmission of only one copy of the data for all
   recipients at the same destination (or intermediate relay) host." 

Source: http://www.ietf.org/rfc/rfc2821.txt

Also: Standard for ARPA Internet Text Messages

 C.3.2.  FROM

    The "From" field must contain machine-usable addresses  (addr-
    spec).   Multiple  addresses may be specified, but named-lists
    (groups) may not.

Source: http://ietfreport.isoc.org/idref/rfc822/

  • Your "From:" header quote from RFC822 is unrelated to this discussion.
    – adaptr
    Apr 6 '12 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.