The errata should be against that final paragraph of section 3.6 in RFC 5321, as the MUST NOT prohibition is simply wrong in theory and is ignored in practice. RFC 7489 is fine as written.
Many MTAs have the dual role of deciding whether a message should be relayed, as well as deciding where it should be relayed. When deciding whether a message should be relayed, all available information is within scope. RFC 5321 overreaches by asserting without justification that the MTA "has no need" to examine header information. If that were true, the prohibition would be redundant. The most that can be said is that the MTA "has no requirement" to examine header information. We also know that some relays, including mailing lists like this one, add content to the subject or body, so even the prohibition of modifications is problematic. A prohibition against modifying earlier headers is reasonable, but needs to be worded to acknowledge those modifications that have become standard practice. The entire paragraph is a problem. Doug Foster On Sun, Aug 21, 2022 at 4:42 AM Independent Submissions Editor (Eliot Lear) <[email protected]> wrote: > Dear Authors and DMARC group, > > In my continuing review of errata posted against RFC 7489, my view is that > the following erratum should be rejected, and I intend to do so in the next > month unless given good cause not to do so. My reading is that the > reporter has quoted from the wrong section of RFC 5321, and that we are not > discussion Message Submission Servers. > > Eliot (ISE) > > > > *Status: Reported Type: Technical Publication Format(s) : TEXT* > Reported By: Borislav Petrov > Date Reported: 2018-11-09 > > Section 10.3. says: > > Everything about it.. > > Notes: > > DMARC relies on inspecting header information. This section suggestion is > not allowed by rfc5321 and contradicts it: > > ...a relay SMTP has no need to inspect or > act upon the header section or body of the message data and MUST NOT > do so except to add its own "Received:" header field.. > > So the correct behaviour shoud be only the second option - 2xy and decide > what to do after that being silent or not. > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
