RFC Errata
RFC 5321, "Simple Mail Transfer Protocol", October 2008
Note: This RFC has been updated by RFC 7504
Source of RFC: IETF - NON WORKING GROUPArea Assignment: art
Errata ID: 4265
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vance Kochenderfer
Date Reported: 2015-02-07
Rejected by: Barry Leiba
Date Rejected: 2015-03-01
Section F.2 says:
SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address.
It should say:
SMTP servers MUST continue to accept source route syntax within RFC 5322 headers as specified in the main body of this document and in RFC 1123. They SHOULD ignore source routes specified in envelope addresses and utilize only the target domain, or MAY decline to accept envelope addresses that specify source routes.
Notes:
The current wording of Section F.2 appears to contradict Sections 3.3 and 3.6.1.
Section 3.3 states: "Servers MUST be prepared to encounter a list of source routes in the forward-path, but they SHOULD ignore the routes or MAY decline to support the relaying they imply."
Section 3.6.1 states: "SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes."
RFC 1123 contains *two* separate relevant requirements: Section 5.2.6 states "A receiver-SMTP MUST accept the explicit source route syntax in the envelope..." and Section 5.2.19 states "Internet host software SHOULD NOT create an RFC-822 header containing an address with an explicit source route, but MUST accept such headers for compatibility with earlier systems."
It appears that Sections 3.3 and 3.6.1 are intended to remove the requirement to accept source route syntax within envelope addresses, but the current wording of Section F.2 contradicts this. If the intent of Section F.2 is only to continue the requirement to accept source route syntax within message headers, this should be made clear. The proposed text is written with this assumption in mind. If the intent of RFC 5321 is to remove both requirements, the proposed wording for Section F.2 requires further revision.
Also, if the intent of Sections 3.3 and 3.6.1 is to treat source routing differently for a <forward-path> and <reverse-path>, this should be clarified in all three sections. The proposed text assumes the requirements for both are the same.
--VERIFIER NOTES--
The text as it is, is what was intended. Moreover, this is another step along the way toward the deprecation of source routes, a path we started on a good many years ago. John Klensin is taking input for his working copy of a 5321bis, if specific text changes are suggested.