I, too, prefer MUST to SHOULD there, but it was clear to me that we will not reach rough consensus on MUST, but that we can reach rough consensus on SHOULD.
I do like your suggestion of silent discard rather than bounce, and I would want to see that change made -- perhaps with a note that aggregate reports will still include information about those discards. Barry On Fri, Jul 7, 2023 at 9:03 AM Baptiste Carvello <devel2...@baptiste-carvello.net> wrote: > > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc