On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
