search

ietf-wg-emailcore / emailcore

3 stars 0 forks source link

G.7.10. Further clarifications needed to deprecated source routes? #17

Closed ietf-svn-bot closed 2 years ago

ietf-svn-bot commented 3 years ago

keyword_SMTP owner:alexey.melnikov@isode.com resolution_fixed type_defect | by alexey.melnikov@isode.com

See 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

ietf-svn-bot commented 3 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?

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com set component to smtp

ietf-svn-bot commented 3 years ago

@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 and , this should be clarified in all three sections.

ietf-svn-bot commented 2 years ago

@alexey.melnikov@isode.com commented

Proposed text sent to the mailing list:

https://mailarchive.ietf.org/arch/msg/emailcore/75Aq_VmfLVTKoaUjzjqmFfauesU

ietf-svn-bot commented 2 years ago

@alexey.melnikov@isode.com changed status from new to assigned

ietf-svn-bot commented 2 years ago

@alexey.melnikov@isode.com set owner to alexey.melnikov@isode.com

ietf-svn-bot commented 2 years ago

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

ietf-svn-bot commented 2 years ago

@alexey.melnikov@isode.com changed status from assigned to closed

ietf-svn-bot commented 2 years ago

@alexey.melnikov@isode.com set resolution to fixed