Baptiste, Your comments assume uniform agreement that mailing lists have no role in the problem or it's solution. I do not agree.
Malicious impersonation creates a need for authentication. If the list makes changes that disable the originator's authentication, then it is the list's problem to find a way to convince the recipient that the message is not a malicious impersonation. ARC and Munging together are the best available way to do so, because no other options are on the table. If you want to blame someone for the list problem, blame the criminals. Silent discard is only part of the solution. Any server that consistently sends rejected messages should expect to be blacklisted, first by the recipient organization and then by the RBLs. To prevent block escalation, the list must find a way to authenticate. DF On Fri, Jul 7, 2023, 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
