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
