Please move on from this thread, it’s done now. Seth, as Chair
-mobile On Fri, Nov 24, 2023 at 09:53 Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 < > dougfoster.emailstanda...@gmail.com> 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 <dotz...@gmail.com> wrote: >> >>> >>> >>> 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
