As a concept, DMARC is a powerful tool for detecting and blocking malicious senders.
As a document it does much less. DMARCbis perpetuates the known problems in RFC 7489, thereby ensuring a continuation of negative outcomes. Both documents define an imaginary evaluator who follows the senders advice in defiance of his own best interest, and even in defiance of consistency: - If the domain owner policy is p=none (or no policy), the imaginary evaluator accepts malicious impersonation, because this is a small price to pay for ensuring that no wanted message is blocked incorrectly. No attempt is made to distinguish between wanted and unwanted messages. - If the domain owner policy is p=reject, the imaginary evaluator blocks all unverified messages, because his priority is to prevent malicious impersonations from being accepted. Blockage of some wanted messages, including mailing lists and other beneficial impersonations, is a small price to pay for protecting the network. No attempt is made to distinguish between wanted and unwanted messages. - If the DMARC evaluation demonstrates that the purported author is not the author of the message, the evaluator makes no attempt to determine the identifiers that are responsible for the message. Updating the sender reputation database is not important. - If the domain owner changes from p=reject to p=none to protect mailing list traffic, the imaginary evaluator immediately weakens his defenses as well, because the domain owner's interest outrank the evaluator's own interest. This specification strategy has been justified on the assertion that real-world evaluators will not actually behave like the imaginary evaluator. They will, instead, deviate from the DMARC specification and pursue their own interests to optimally protect their network and serve their users. Evaluators know their own interests so well that we need not, and indeed should not, give them any advice. I am the first to wish that this assertion were actually true, but it is clearly not. If evaluators consistently used DMARC results in a manner different than the imaginary evaluator, we would not have the mailing list problem. Many aspects of the mailing list problem demonstrate that a non-trivial subset of evaluators are mimicking the imaginary evaluator very closely, with all the warts that I described, and people are being harmed as a result. Standards track? Not until we fix the failure inherited from RFC 7489: the untutored evaluator who does not know how to use DMARC results wisely. Doug Foster On Mon, Apr 1, 2024 at 5:43 PM John R. Levine <jo...@iecc.com> wrote: > On Sun, 31 Mar 2024, Jim Fenton wrote: > > Based on the above problems, I do not think DMARC-bis should be > published as > > a standards track document by IETF. > > This reminds me of the NAT wars in the 1990s. We all understand that > DMARC has a lot of problems, but it's far more widely used than many of > the IETF's published standards. It just makes us look insular and out of > touch to pretend that it doesn't exist, or if we shut our eyes it will go > away. > > R's, > John > > _______________________________________________ > 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
