The gap between what is being attempted and what is needed is a huge personal disappointment.
The DMARC goal should be to block malicious impersonation without blocking wanted messages, where "wanted" is in the eyes of the evaluator and his end user. That puts the onus on the evaluator. RFC 7960 said that evaluators need to be aware of problems, but gave no solutions. DMARCbis replaces the evaluator with a mindless automaton, repeating all the worst mistakes of RFC 7489. This is from a real-world conversation with a product support tech: Me: I cannot use your DMARC implementation because it does not have an exception mechanism. Him: Why would you need exceptions? I blame his ignorance, and his product's inadequacies, on RFC 7489, which defined no exceptions. RFC 7489 falsely divides the mail stream into four groups: - Authenticated / Pass, - Unauthenticated without Prejudice (None), - Unauthenticated with Prejudice (Quarantine/Reject), and - No Result. In reality, there are only two possible states: Authenticated and Not Authenticated. - The Mailing List problem proves that the distinction between None and Reject is a fiction. At best, Fail with Reject justifies a slightly higher risk weight for environments that depend on weighting. - "No Result" is an error in RFC 7489. The PSL and default alignment rules allowed a result to be calculated on any domain. An evaluator cannot excuse a decision to allow malware infestation by saying, "the domain owner did not give me permission to check for malicious impersonation." "No Result" is another way of saying, "I did not do my job." - Any unauthenticated message is a potential impersonation. It is the evaluator's job to figure out whether malicious impersonation actually occurred or not. Authentication failure provides a starting point, not an end point. The risk of malicious impersonation applies to every unauthenticated message. Correct evaluation fixes the mailing list problem and fixes a lot of other false blocks, while blocking the malicious traffic that RFC 7489 leaves unmolested. We need a document that is targeted at evaluators, to help them make correct disposition decisions for their organizations. The current document blames the charter as the reason that it does not even try. Doug Foster On Wed, Nov 22, 2023 at 5:58 PM Seth Blank <s...@sethblank.com> wrote: > Is there a point to this thread, that affects the text in the DMARCbis > document under charter criteria? > > Seth, as Chair > > -mobile > > > On Wed, Nov 22, 2023 at 07:13 Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> RFC 7489 and DMARCbis are written as algorithms without exception >> conditions. That silence leads product developers and mail administrators >> to conclude that the algorithm can be implemented without allowing for >> exceptions. Why would we expect a different result? >> >> Withheld information can deceive. >> >> >> >> >> On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely <ves...@tana.it> wrote: >> >>> On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: >>> > I see that the DMARC marketing machine is hard at work. There was an >>> item on NPR (National Public Radio) “All Things Considered” this afternoon >>> heavily promoting DMARC: >>> > >>> > >>> https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season >>> > >>> > I have strong feelings about this article that are off-topic for this >>> mailing list. >>> >>> >>> What is not off-topic is the consideration that such sentiment implies >>> that a >>> prohibitive statement would turn out to mean /MUST NOT use mailing >>> lists/. >>> >>> >>> Best >>> Ale >>> -- >>> >>> >>> >>> >>> _______________________________________________ >>> 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