Barry, I did a quick review and comparison for changes.
Overall, it appears this document is more clear in key specific areas but also more complex. At this point, DMARCbis is about Local Policy, System Administrative choices and suggested guidelines, codified and/or new. As such, I don’t think this document is a "Standard Track" material with its many ambiguous considerations and changes. Consider the following: Is this document backward compatible with existing DMARC1 behavior? If not, what are the key protocol changes implementers need to consider for updating DMARC1 to DMARCbis? Can this be summarized? Thanks — HLS > On Jul 7, 2023, at 9:17 AM, Barry Leiba <barryle...@computer.org> wrote: > > 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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
