Hi, I consider this a step backwards. The MUST requirement on the author domain finally made it clear, after a lost decade, *who* is responsible for solving the breakage of indirect mailflows. Problem solving starts with acknowledging one's responsibilities.
This proposal goes back to a muddy shared responsibility between the author domain and the mail receiver. This is the best way to make sure nothing changes, as each waits for the other to act. Mailing lists can expect to suffer for more long years. No wonder the From-munging proponents are rejoicing! If this goes in, at least something has to be done to reduce bounces, such as: — Section 8.3 — ADD The Mail Receiver MUST reject with "silent discard" when rejecting messages with a List-Id header. END That way, each party's choices will mostly impact their own messages. Mailing list operators can then take a step back, undo any ugly workarounds, and let DMARC participants decide between themselves, on a case by case basis, how they solve *their* deliverability problems. Cheers, Baptiste Le 06/07/2023 à 16:55, Barry Leiba a écrit : > I had some off-list discussions with Seth, who was very much against > my original proposed text, and he suggested an alternative > organization that would be more palatable to him. I've attempted to > set that out below. The idea is to remove the normative requirements > about using p=reject from Sections 5.5.6 and 5.8, and instead put a > broader discussion of the issues, along with the normative > requirements, into a new "Interoperability Considerations" section. > This makes it explicitly clear that any MUST/SHOULD stuff with regard > to using and honoring p=reject is an issue of interoperating with > existing Internet email features. I can accept that mechanism also, > and so, below is my attempt at writing that proposal up. > > Barry _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
