6 Matching Annotations
  1. Dec 2020
    1. 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 FROM that refers to the originator (a.k.a., reverse path, backward-pointing address) of the request

      • one or more recipient addresses,

      Multiple RCPT TO for each "to:" rfc822 message header in the mail data (see annotation)

      • and optional protocol extension material.

      DATA (see below)


      (See also envelope-vs-mail tags.)

    2. When the RFC 822 format ([28], [4]) 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.

    3. 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 [4]) 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.

    4. 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.

    5. 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.
      1. This the only difference between an SMTP alias and list; expanding recipients to RCPT commands is the same.
      1. 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 From:.
    6. 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 RCPT command is specified for each recipient in the mail data, these RCPT commands will be evaluated in sequence,, and any SMTP (error) notifications will be sent to the address in the MAIL FROM command (which is not necessarily the same as the mail data's From: header).