The solution then should be to fix the charter. Everything depends on your definition of DMARC. Here is mine:
"DMARC is the use of proxy authentication to provide verification of the FROM address and mitigate malicious impersonation of that address, combined with supporting mechanisms to maximize the accuracy of that evaluation." I reject this definition: "DMARC is the use of proxy authentication to provide verification of some FROM addresses to mitigate malicious impersonation on a subset of those addresses." or this one: "DMARC is the use of proxy authentication to protect brand identity of the FROM address domain owner." But to the mailing list problem, try this: Messages fall naturally into three groups: 1) Messages which demonstrate domain owner authorization using SPF PASS or DKIM PASS. 2) Messages which cannot demonstrate domain owner authorization but are based on an established relationship with an individual domain member and sent for benevolent purposes. 3) Messages which are not based on any relationship with the domain and are consequently malicious in purpose. The distinction between the second and third group is a matter of intent, and intent can only be determined by the evaluator when messages are presented for evaluation. Domain owner use of "p=reject" is a request to usurp the evaluator role by asserting that there is no possibility that any message from any source could be received for any benevolent reason without presenting evidence of domain owner authorization. In limited cases, domain owners are in a position to make this assertion correctly, but operating experience has shown that this is rare. Evaluators SHOULD treat "p=reject" as equivalent to "p=quarantine", and make their own determination of intent, blocking messages with malicious intent and allowing acceptable messages. Doug Foster On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> In short, I am not part of the presumed consensus on this document. I >> will vigorously oppose any document which does not discuss malicious >> impersonation defenses for every domain. >> > > Doug, > > A working group charter is a sort of contract with the IESG that > stipulates what the working group will produce and how it will operate. > This is meant to keep the working group on track and eschew distractions > and scope creep. The charter for this particular working group is visible > in the IETF datatracker. > > If you read it, you'll see that this working group is not chartered to do > anything as broad as what I believe you are demanding here. Put another > way: Were it to produce the document that you appear to expect, it likely > would be sent back as exceeding the working group's charter. A full > treatment of sender authentication and malicious impersonation far exceeds > what DMARC by itself is capable of addressing, and we here are only dealing > with DMARC. We are chartered here to revise RFC 7489 based on operational > experience acquired since DMARC was first deployed, and in this and other > ways prepare it for publication on the Standards Track, and possibly > produce ancillary documents. We are not chartered to produce an broad > treatment of the sort you seek. > > The sentiment of your first sentence is noted. The sentiment of your > second, however, seems like a threat that you intend to make yourself > vexatious to the progress of the document, and I truly hope you don't mean > that. > > -MSK, ART AD >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
