MUST NOT or SHOULD NOT make little difference. Both are the Crocker Proposal revived and simplified: "The solution to authentication problems MUST be LESS AUTHENTICATION!" If you can convince nearly all senders to use p=NONE, and if you can convince nearly all evaluators to enforce only when p=REJECT, then you will have created the pretense of an authentication regime without much actual authentication. Spammers are very good at mass production, so we can expect 100 malicious impersonations to be allowed for every 1 legitimate mailing list message allowed.
One problem is that the strategy is unlikely to work. I don't expect our document to convince large numbers of p=reject organizations to suddenly embrace p=reject. I also expect savvy organizations to start enforcing authentication even when p=none, if they are not doing so already. I don't need Gmail to publish p=reject to identify and block the attacks which falsely pretend to be from Gmail. Given the suggested 1:100 problem, the proposed solution to the mailing list problem is an unstable equilibrium. We should also be worried that we are losing our audience. The big evaluation platforms get bigger every day, and they have problems that cannot wait years while we try to churn out documents. I have been disappointed by their absence or silence, but I should not have been. How have we given them reason to believe that we know something that they have not already figured out? Our real audience is the shrinking market of organizations and product developers that are trying to solve the email filtering problem without surrendering completely to big tech. That audience needs guidance on how to evaluate correctly, and our document has systematically avoided doing so. Our document should read like an FDA-approved commercial for prescription medicine: :"This is a great product, but you should also be aware that these are four ways it could maim or kill you." Sender Authentication, used properly, is a powerful defense against malicious actors. But any implementation needs to be prepared to handle (a) strict authentication policies when relaxed authentication is needed. (b) ESP messages that lack a client domain signature (c) Mailing list messages that lack a verifiable author domain signature (d) Duplicate and incorrect SPF policies (e) Incorrectly determined organizational boundaries and some others. To this point, RFC 7489 and DMARCbis are content to let evaluators figure all of this out on their own. The price for their learning curve is that acceptable messages are blocked and unacceptable messages are allowed. If you want your acceptable messages to be accepted, you have a vested interest in minimizing that learning curve rather than prologing it. MUST NOT is not the solution. Intelligent advice for intelligent evaluators could be. Doug Foster On Wed, Nov 15, 2023 at 7:51 PM Jim Fenton <fen...@bluepopcorn.net> wrote: > I’m a little slow responding to this; my apologies for that. > > On 23 Oct 2023, at 1:03, Francesca Palombini wrote: > > > I believe there is a rough consensus that a change needs to be made in > the text to include stronger requirements admonishing operators against > deploying DMARC in a way that causes disruption. The mails go in many > directions, but the most contentious point I could identify is if there > ought to be some normative MUST NOT or SHOULD NOT text. Many people have > suggested text (thank you!). I believe the ones with more tractions are > Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. > > Count me in the MUST NOT column, using either Scott’s text or the original > text from Barry [1]. The document needs to make a clear statement here, and > the text in [3] is far too verbose for most readers to follow, especially > when the reasons for not following the SHOULD NOT are added. In addition, > [3] seems to presume that the sending domain has some way of knowing what > email addresses are mailing lists, and presumes that it knows something > about the disposition decision that will be made by the receiving domain > (that it does not, in general, even know). Sure, it might determine mailing > lists heuristically (looking for mailing list headers on incoming messages, > for example), but that won’t work in all cases (alumni addresses being an > example). > > I’m also concerned about p=quarantine: I’m under the impression that > address rewriting is done by some mailing lists to avoid the quarantining > of mailing list messages. If that is the case, whatever is said about > p=reject should also apply to p=quarantine. > > -Jim > > _______________________________________________ > 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
