I am not claiming any particular knowledge of the universe of all implementations. All I know is that if my user's want a mailing list exempted from DMARC enforcement, all they have to do is ask, and that is the way it should be most everywhere. If the mailing list problem was unique to AOL alone, then lists could do special processing specific for AOL recipients. But the problem is discussed in this forum as if it is pervasive. At least one previous post chastised me that any DMARC specification MUST be fully automatic. I couple those clues with my own difficulty finding a product that anticipates and implements my need for exceptions. Finally, I note that RFC 7489 and DMARCbis are both silent about what an exception mechanism would involve, so I cannot be surprised that developers who follow the specification do not implement adequate exception mechanisms, if at all. So forgive me for feeling like I am the only one on the planet who thinks a proper implementation needs specific exception management features, especially since I believe the requirements for those features can be easily discerned with a little effort.
When I configure my defenses, I care very little about the opinions of a domain owner, because I don't work for them. I am very interested in knowing whether a message is authenticated or not, because an authenticated message is judged to be free of identifier impersonation risk. If the message is authenticated, why do I need the domain owner's opinion about whether the message MUST be authenticated? If the message is not authenticated, I still don't care very much about the domain owner's opinion, I care about whether the message should be delivered to the user or not. Since I expect authentication failure to include false positives, the only way to settle the matter is to get more information, by investigating why it failed authentication and whether that particular message is acceptable to my organization or not. This works because I don't think that every message is unique. I think attackers are identifiable but their attack methods will vary, so the faster that I get them block-listed, the easier my life will be. And it works. If you follow the spec, you get DMARC results on maybe 40% of your messages, and you only consider a failure result as definitive on the 10% or less that request enforcement. Then a subset of that 10% is bad advice. If you instead look at the messages which produce DMARC PASS, you have results on at least 80% of all messages. Then you can start asking the right question: How can I do better triage on the 20%? The answers are pretty straightforward once you start seeing the data. It does not require the magic of content filtering, it just requires the right framework and human judgement. The framework is easily defined. But since I am the only one who thinks the RFC 7489 and DMARCbis scope is wrong, we should move this off-line. I had already promised to go away, but then I felt Barry misrepresented my perspective, and then you responded to the group twice. Doug Foster On Sun, Sep 17, 2023 at 6:20 PM Murray S. Kucherawy <[email protected]> wrote: > On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster < > [email protected]> wrote: > >> We have established that the normative implementation of DMARC is >> (unfortunately) a fully-automated solution which implements RFC 7489 >> exactly and nothing more. >> > > Sure, but why would you do that, especially in the presence of all of the > context that's come to light since March 2015? > > Given the language in Section 6.7 of RFC 7489, I find your statement > confusing. That section goes to some lengths to lead the reader to the > conclusion that there are going to be false positives and false negatives, > and that DMARC should be one input to a larger policy decision. How, then, > could an operator that implements DMARC and nothing else claim to be fully > compliant? > > DMARC's brilliance was the use of an authenticated identifier to provide >> proxy verification of another identifier. It is the identifiers that >> provide the authentication, not the policy. The policy influences only >> the strictness of the alignment rule. This means that any message with >> strict alignment on SPF PASS or DKIM PASS is DMARC authenticated, with or >> without a policy. "No result" in this situation is the result of a >> choice, but not a necessary one, and not one that is easily justified. >> > > I'm not following here either. The fourth sentence contradicts RFC 7489. > The absence of a policy is all the justification you need to say it's "no > result" rather than "authenticated"; you're otherwise willingly discarding > the fact that the RFC5322.From domain's owner has either neglected or > deliberately omitted to publish a policy, which may itself be a useful > signal (and Section 6 talks about this). > > For those who have implemented to the specification, "No Result" means >> "Content Filtering must carry the whole load," which it cannot do. So I >> reject the notion that "No Result" is harmless. >> > > This appears to be an assertion that everyone should be advertising a > policy. That's different from asserting that all receivers should infer a > policy where none is advertised. The outcomes are very different. > > -MSK, p11g >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
