RFC 5321, "Simple Mail Transfer Protocol", October 2008Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app
Errata ID: 3447
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2013-01-07
Held for Document Update by: Barry Leiba
Date Held: 2013-01-09
Section 4.4 says:
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. ... SMTP servers performing a relay function MUST NOT inspect the message data ... For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
It should say:
When the delivery SMTP server makes the "final delivery" of a message, it MUST insert a return-path line at the beginning of the mail data. For this to be unambiguous, exactly one return path MUST be present when the message is delivered.
There are contradictory and ambiguous statements in this section. Return-path is classified in 5322 as optional. It's not 100% clear in the original text whether the server MUST prepend the return-path header or not.
Do we really want to prohibit inspection by relays in this section? I would imagine this MUST level requirement is routinely ignored anyway.
Alternatively, we decide that Return-path is truly optional and change the first sentence to make that clear instead of the strongly implied MUST.
--- VERIFIER NOTES ---
This erratum would normally meet the criteria for "Rejected", but
it points out that as it currently stands, RFC 5321 is in need of
some work, perhaps in the process of advancing it on the Standards
Track to Internet Standard. The erratum raises some issues, which
I'll note here:
1. RFC 5321 uses the capitalized key words from RFC 2119 only sparingly,
and much of the normative language in the document is written in plain
English ("the server does this", rather than "the server MUST do this").
This is by intent, and is certainly not an error in the document, but
some people find it less clear.
2. While RFC 5321 and RFC 5322 go hand in hand for most of us most of
the time, they are quite separable. RFC 5321 can be used to transfer
data that does not conform to the format in RFC 5322, and message stores
can contain messages in RFC 5322 format that were not put there via
SMTP (RFC 5321). As a result, there are sometimes things that seem
contradictory between the two documents, if one is not aware of this
3. RFC 5321 specifies a protocol that we know is not fully followed
everywhere. That there are known variants does not mean that we should
define the protocol any less rigorously, and the claim that a requirement
of the protocol is "routinely ignored" may well be true, but is not
relevant to how the protocol is defined.
All that said, the points need to be considered when a revision of
RFC 5321 is taken on, and I'm marking this as "Held for Document Update"
so that it will be staring us in the face is and when that happens.