- Last 7 days
- Nov 2022
You can definitely set the Return-Path header as a sender. But yes, some receivers might rewrite it (But not always ), or depending on who you're sending through, it might be re-written by them. For instance when using MailGun to send bulk email you have to do things just right in order to set a Return-Path that will be preserved. I know this contradicts the RFC you cite, but it's in practice true.
Return-Path header is written by the receiving server, not by the sending server. And as per the RFC 5321, it is the same as the address supplied in MAIL FROM command.
- Dec 2020
Several commands (RSET, DATA, QUIT) are specified as not permitting parameters.
That is, they don't accept options, only data arguments. E.g.,
DATA's argument is the RFC 822 message format with headers and message body.
The model for this is that distinct buffers are provided to hold the types of data objects; that is, there is a reverse-path buffer, a forward-path buffer, and a mail data buffer.
2.3.1. Mail Objects SMTP transports a mail object. A mail object contains an envelope and content. The SMTP envelope is sent as a series of SMTP protocol units (described in Section 3). It consists of an originator address (to Klensin Standards Track [Page 11] RFC 5321 SMTP October 2008 which error reports should be directed), one or more recipient addresses, and optional protocol extension material
The SMTP envelope is sent as a series of SMTP protocol units (described in Section 3). It consists of
- an originator address (to which error reports should be directed),
MAIL FROMthat refers to the originator (a.k.a., reverse path, backward-pointing address) of the request
- one or more recipient addresses,
RCPT TOfor each "to:" rfc822 message header in the mail data (see annotation)
- and optional protocol extension material.
The third step in the procedure is the DATA command (or some alternative specified in a service extension). DATA <CRLF>
Third part of the envelope:
When the RFC 822 format (, ) is being used, the mail data include the header fields such as those named Date, Subject, To, Cc, and From.
This just answered my question regarding the quote from "Postfix: The Definitive Guide":
ENVELOPE ADDRESSES AND MESSAGE HEADERS A common source of confusion for email users is the fact that the To: address in email message headers has nothing to do with where a message is actually delivered. The envelope address controls message delivery. In practice, when you compose a message and provide your MUA with a To: address, your MUA uses that same address as the envelope destination address, but this is not required nor is it always the case. From the MTA’s point of view, message headers are part of the content of an email message. The delivery of a message is determined by the addresses specified during the SMTP conversation. These addresses are the envelope addresses , and they are the only thing that determine where messages go. See Section 2.2.8 later in the chapter for an explanation of the SMTP protocol.
Mailing lists and spam are common examples of when the envelope destination address differs from the To: address of the message headers.
Also an answer to this question.
An SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery. When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list. However, in this case, the message header section (RFC 5322 ) MUST be left unchanged; in particular, the "From" field of the header section is unaffected.
Another section that serves well to understand the difference between email data and SMTP envelope.
To expand an alias, the recipient mailer simply replaces the pseudo- mailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address.
This annotation explains what this paragraph means and dispels my confusion regarding how 3mails with multiple recipients will get processed (also, SMTP envelope vs mail data).
MS Outlook's "distribution list" is the same as an rfc5321 alias.
The return (backward-pointing) address in the envelope is changed so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages annoying.
- This the only difference between an SMTP alias and list; expanding recipients to RCPT commands is the same.
- Another great example to highlight the difference between SMTP envelope and mail data: the envelope's
MAIL FROM(see annotation) is different from to the mail data's rfc822
If the Klensin Standards Track [Page 19] RFC 5321 SMTP October 2008 recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible).
Will the entire transaction be canceled? "Transaction" in the name of this a section implies yes, but what if all the recipients are valid?
See replies below but the answer is no; an
RCPTcommand is specified for each recipient in the mail data, these
RCPTcommands will be evaluated in sequence,, and any SMTP (error) notifications will be sent to the address in the
MAIL FROMcommand (which is not necessarily the same as the mail data's
There exist mailing lists that perform additional, sometimes extensive, modifications to a message and its envelope. Such mailing lists need to be viewed as full MUAs, which accept a delivery and post a new message.
I guess Mailman would qualify (e.g.,
the reverse-path (originator) address specification command (MAIL)
Sometimes "reverse path" or "originator" address is also referred to "backward-pointing" address (and those instances also refer to the
The second step in the procedure is the RCPT command. This step of the procedure can be repeated any number of times.
This step of the procedure can be repeated any number of times. !
So the section
To expand an alias, the recipient mailer simply replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address.
means that for each "to:" rfc822 message header in the mail data (i.e., SMTP envelope's DATA) a RCPT TO command will be added.
An important mail facility is a mechanism for multi-destination delivery of a single message, by transforming (or "expanding" or "exploding") a pseudo-mailbox address into a list of destination mailbox addresses.
So this section describes how distribution list addresses or mailing list addresses are expanded into individual email addresses of the members of those lists, and not how emails are delivered to multiple addresses when more than one recipient is specified in a MUA.
If the verb is initially accepted and the 354 reply issued, the DATA command should fail only if the mail transaction was incomplete (for example, no recipients),
How could this specific scenario be even possible? It just said in the previous paragraph that
If there was no MAIL, or no RCPT, command, or all such commands were rejected, the server MAY return a "command out of sequence" (503) or "no valid recipients" (554) reply in response to the DATA command.
This was unexpected; why wasn't the canonical format (i.e., 5xx) used instead?
Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above.
Similarly, servers MAY decline to accept mail that is destined for other hosts or systems.
For a personal mail server, this sounds like a reasonable advice to follow.
An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message.
Is SMTP stateless or stateful? See thread above.
However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
What does this mean? Then what is the point of preserving the case if one can't act on it?
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive.
The local-part of a mailbox MUST BE treated as case sensitive.
Meaning that email addresses are case sensitive (the part before @, that is).
The terms "message content" and "mail data" are used interchangeably in this document to describe the material transmitted after the DATA command is accepted and before the end of data indication is transmitted.
The terms "message content" and "mail are used interchangeably
RFC 3463 , specifies further structuring of the reply strings, including the use of supplemental and more specific completion codes (see also RFC 5248 ).
To-do: look at the mentioned RFCs.
SMTP sessions are stateful
SMTP is stateless but SMTP sessions (just as HTTP/HTTPS sessions) are stateful.
The means by which an SMTP client, once it has determined a target domain, determines the identity of an SMTP server to which a copy of a message is to be transferred, and then performs that transfer, is covered by this document. To effect a mail transfer to an SMTP server, an SMTP client establishes a two-way transmission channel to that SMTP server. An SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate Mail eXchanger host or a final target host.
What does "SMTP client" refer to in this context? A MUA?
However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
- Aug 2015