Closed ietf-svn-bot closed 2 years ago
@alexey.melnikov@isode.com changed title from Further clarifications needed to deprecated source routes?
to G.7.10. Further clarifications needed to deprecated source routes?
@alexey.melnikov@isode.com set component to smtp
@alexey.melnikov@isode.com commented
There was also a rejected Erratum 4265 related to this:
Vance Kochenderfer wrote:
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
@alexey.melnikov@isode.com commented
Proposed text sent to the mailing list:
https://mailarchive.ietf.org/arch/msg/emailcore/75Aq_VmfLVTKoaUjzjqmFfauesU
@alexey.melnikov@isode.com changed status from new
to assigned
@alexey.melnikov@isode.com set owner to alexey.melnikov@isode.com
@alexey.melnikov@isode.com commented
Based on the January 2022 Interim, Appendix F.2 is nearly ready. 2 changes suggested:
SMTP servers SHOULD continue to accept source route syntax as specified in this appendix.
s/SHOULD/MAY
SMTP clients SHOULD NOT attempt to utilize explicit source routing.
s/SHOULD NOT/MUST NOT
These changes should be completed in -09.
@alexey.melnikov@isode.com changed status from assigned
to closed
@alexey.melnikov@isode.com set resolution to fixed
keyword_SMTP
owner:alexey.melnikov@isode.com
resolution_fixed
type_defect
| by alexey.melnikov@isode.comSee text in Appendix C. There are RFC 2119 language there and it might be confusing.
Issue migrated from trac:17 at 2022-01-31 12:34:38 +0000