Re: [dmarc-ietf] Best of all possible documents?
DMARC is a protocol that uses a published DNS record to advertise a sending domain's policy. It's described in RFC 7489 and the DMARCbis draft. What anyone does in the absence of a published DMARC record is *not* part of DMARC, in the same way that use of FTP to deliver email is not part of SMTP. The DMARCbis document is *only* describing the use of DMARC. Describing [not DMARC] in the DMARCbis document is out of scope. Please stop insisting that it be in scope. Barry, as chair On Wed, Oct 25, 2023 at 12:32 PM Douglas Foster wrote: > > More specifically to the asserted charter problem: > > RFC 7489 provided a universally applicable rule for determining > organizational boundaries: the PSL. > Then it provided a universally applicable rule for determining > authentication: relaxed alignment, same organization for the verified > identifier and the FROM domain. > > Despite starting from that point, RFC 7489 arbitrarily limited applicability > to messages with DMARC policies, which is its core design failure. > Reversing that mistake is part of what DMARCbis needs to do. > > Doug > > On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy > wrote: >> >> On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster >> 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
Re: [dmarc-ietf] Best of all possible documents?
More specifically to the asserted charter problem: RFC 7489 provided a universally applicable rule for determining organizational boundaries: the PSL. Then it provided a universally applicable rule for determining authentication: relaxed alignment, same organization for the verified identifier and the FROM domain. Despite starting from that point, RFC 7489 arbitrarily limited applicability to messages with DMARC policies, which is its core design failure. Reversing that mistake is part of what DMARCbis needs to do. Doug On Tue, Oct 24, 2023 at 11:30 PM Murray S. Kucherawy 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
Re: [dmarc-ietf] Best of all possible documents?
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 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
Re: [dmarc-ietf] Best of all possible documents?
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
Re: [dmarc-ietf] Best of all possible documents?
My working assumption is that this document, if approved, will be the last statement, for a long time to come, on matters of sender authentication and malicious impersonation defenses. That assumption raises the question, "Is this the best possible statement of how to defend against malicious impersonation using sender authentication?" The answer has to be, "No."The document provides no strategy for defending against malicious impersonation when a DMARC policy is lacking, and we can expect that non-DMARC domains will persist for a long time to come. Does the group really believe that no such defense is possible? Has any effort been made to develop answers to that question? To make things worse, the document provides no guidance about how to use results other than "Fail with Reject". I suggest that domain owners pursue "reject" status because "none" appears to mean, "I am willing to tolerate malicious impersonation of my domain." If we want domain owners to stop at "None" or "Quarantine", we should be prepared to articulate how those configurations are different from "Defenseless". We have not done so yet. When we demonstrate an interest in the evaluator's problems and self-interest, we will find that he will provide the fix for our much discussed mailing list problem. 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 Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
