G.24. Describing the "Operational Requirements" Loopholes

[aamelnikov]

John Klensin wrote:

The discussion in Section 7.8 and Section 7.9, and the pointers to them from Section 6.2 and elsewhere essentially provide the basis for implementations to deviate, in multiple ways, from the intent of RFC   5321 and 5321bis while claiming conformance. Is the present text what we want? Should it be made more explicit about what is allowed and what isn't (whether either is possible is obviously part of the question)? If we intend to address those issues in the A/S (not just the limits question which is already there), do we want explicit forward pointers to it in the existing sections? (This topic mentioned on the mailing list for the first time in https://mailarchive.ietf.org/arch/msg/emailcore/Zv7XtCUPavpacrLslgDiK7M-FJ8)

[aamelnikov]

John Levine and Ken Murchison volunteered to review the text.

Proposal to close this ticket with "no change" in 2 weeks (on March 21st 2023), unless some objections received.

[aamelnikov]

John R Levine suggested:

The second paragraph of 7.9, about open relays, is rather quaint. How about this: Relay function through arbitrary sites, as part of hostile efforts to hide the actual origins of mail, has become so common that most sites limit the use of the relay function to known or identifiable sources. Implementations SHOULD provide and use the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.

[aamelnikov]

The suggested text was incorporated in draft-ietf-emailcore-rfc5321bis-22