D. J. Bernstein
Internet mail
Internet mail message header format

Envelope information: Return-Path, Received

Return-Path

The value of a Return-Path field is tokenizable. It shows the return path of the message, i.e., the address that bounces will be sent to. It is either (1) a < token followed by a > token, indicating an empty return path, or (2) a bracketed address. Two examples: 
     Return-Path: <>
     Return-Path: <God@heaven.af.mil>

Messages transmitted through SMTP generally do not have Return-Path fields; the return path is transmitted out-of-band in the SMTP MAIL request. When a message is stored in a mailbox, the return path is stored in a Return-Path field. If the message is then retrieved (e.g., through POP) and sent through another SMTP hop, the Return-Path is removed and the return path is again sent out-of-band.

Some mailers, in violation of RFC 1123, fail to record the return path of a message. Subsequent bounces are sent to an invented return path, typically the header From address. This behavior is a disaster for mailing-list messages, where the correct return path is the mailing list manager, and the From address is an innocent subscriber who has no way to remove bad addresses from the mailing list. Every mailer is responsible for using the correct return path.

Received

In theory, the value of a Received field is tokenizable. It contains
  1. optionally, a "from" atom followed by an encoded domain name;
  2. optionally, a "by" atom followed by an encoded domain name;
  3. optionally, a "via" atom followed by another atom;
  4. zero or more of the following: a "with" atom followed by another atom;
  5. optionally, an "id" atom followed by either (1) an atom or (2) a < token, an encoded address, and a > token;
  6. optionally, a "for" atom followed by an encoded address;
  7. a semicolon; and
  8. a timestamp.
Each SMTP server adds a Received field to the top of each incoming message, giving details of how it received the message, most importantly the client's IP address: 
     Received: from mail-relay.af.mil (127.193.178.241)
       by silverton.berkeley.edu with SMTP; 4 May 1998 14:57:55 -0000
     Received: (qmail 2227 invoked from network); 4 May 1998 14:57:37 -0000
     Received: from heaven.af.mil (127.193.178.247)
       by mail-relay.af.mil with SMTP; 4 May 1998 14:57:37 -0000
In practice, SMTP servers put all sorts of badly formatted information into Received lines. It is probably best for readers to treat everything before the final semicolon as unstructured text, purely for human consumption.

A few SMTP servers don't even format the date correctly. For example: 

     Received: by MicroMailer 3.50a on Wednesday, 24 January 1996, 17:15:16 EST
       (WRONG)
Invalid Received fields are also produced by the cucipop POP server.

Hop counting

Most SMTP servers refuse messages with ``too many'' Received fields. For example, sendmail is typically configured to refuse messages with more than 25 Received fields. qmail refuses messages with more than 100 Received or Delivered-To fields. Some messages legitimately have 20 or more Received fields.

Hop counting is a last-resort method of preventing loops: a message will bounce if it passes through too many SMTP servers.