The real evidence of failure is the assumption, built into this document, that allowing mailing list paticipation is as easy as changing your policy to None.
We expect evaluators to treat Fail with None the same as Pass. This says that a lot of malice is also being treated the same as Pass. If our assignment is to inhibit malice, then we have built a solution on the assumption of widespread failure to accomplish that purpose. We should not be so negligent. If AOL and related brands were the only ones rejecting list messages, we would have an AOL grievance, although they would be in their rights to do as they pleased. But we have a mailing list (and ESP) problem because other organizations honor the AOL reject policy unconditionally, against the wishes of their users when list messages are affected. This is defective evaluators behavior. Doug On Fri, Nov 24, 2023, 9:35 AM Douglas Foster < [email protected]> wrote: > If this implied solution was working, we would not have a mailing list > problem 10 years running. > > > > On Thu, Nov 23, 2023, 10:41 AM Dotzero <[email protected]> wrote: > >> >> >> On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < >> [email protected]> wrote: >> >>> 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 >>> >> >> You are absolutely incorrect when you state that there are no exceptions >> provided. "Local policy" enables an evaluator to implement any >> exception(s) they wish. >> >> Michael Hammer >> >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
