Terminology Around From and Return-Path

Unambiguous terms

The words “from,” “sender,” and “bounce address” are often used colloquially to refer to different things, and this leads to confusion.

Instead we prefer to use unambiguous terms which originate from and refer to these RFCs:

RFC5321 – SMTP protocol
RFC5322 – Internet message format (email headers & body)

Here are the terms we use:

RFC5322.From

A header in the Internet Message Format

For example:

From: David Harris

Defined in RFC5322 section 3.6.2, “Originator Fields,” as:

The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message.

RFC5322.Sender

We don’t recommend using this if you can avoid it.

For example:

Sender: David Harris

Defined in RFC5322 section 3.6.2, “Originator Fields,” as:

The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message.  For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field.  If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
appear.

RFC5321.MailFrom

Example:

220 mail.domain.com ESMTP
HELO example.com
250 mail.domain.com
MAIL FROM: [email protected]
250 ok
RCPT TO: [email protected]

Sometimes called “the envelope sender address”
What you put in a SMTP conversation MAIL FROM command
What you use for -f in qmail-inject
What gets set by X-GreenArrow-Return-Path
Not part of the message headers, but exists outside of the headers.
On final delivery to a mailbox, this should be written to a RFC5322.Return-Path in the message headers (the “Return-Path:” header).
We get into problems when we call this the “return path” (because that confuses it with RFC5322.Return-Path

Defined in RFC5321 section 4.1.1.2, “MAIL”.

RFC5322.Return-Path

Example:

Return-Path:

This is a trace-field header in the internet message format used to memorialize the current value of the RFC5321.MailFrom on final mailbox delivery – because the message is leaving SMTP context and the RFC5321.MailFrom value/field is going away.

On final delivery to a mailbox, the RFC5321.MailFrom is written to the RFC5322.Return-Path header.

Sometimes email injecting applications add a “return-path:” header as a trace header before handing email off to an MTA for delivery, but since this is a trace header MTAs are not supposed to read that trace header or use it as the RFC5321.MailFrom.

Defined in RFC5322 section 3.6.7, “Trace Fields”:

The trace fields are a group of header fields consisting of an
optional "Return-Path:" field, and one or more "Received:" fields.
The "Return-Path:" header field contains a pair of angle brackets
that enclose an optional addr-spec. 

...

A full discussion of the Internet mail use of trace fields is
contained in [RFC5321].

Which refers to RFC5321 section 4.4, “Trace Information,” which says (footnote added for clarification):

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 [see footnote 1]. 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.: Footnotes:; [1] this document calls this the RFC5321.MailFrom value