> On 8 Aug 2022, at 05:10, Murray S. Kucherawy <superu...@gmail.com> wrote: > > On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster > <dougfoster.emailstanda...@gmail.com > <mailto:dougfoster.emailstanda...@gmail.com>> wrote: > Evaluators need to use much more sophistication, when applying DMARC, than > simply applying the formula and doing whatever the policy suggests. > > I think that's common practice. The people on this list who are still M3AAWG > regulars can tell me if I'm wrong, but my impression is that it is common > industry practice to factor the output of DMARC, just as DKIM and SPF, into > to whatever local secret sauce an operator chooses to employ when making > handling decisions. DMARC is rarely dispositive on its own. There are > plenty of other practices that usually go into a final handling decision; RFC > 6647 comes to mind as one example, RFC 5782 as another.
DMARC is never dispositive on its own. Neither is SPF. Neither is DKIM. We have on record ISPs saying they look alignment regardless of a DMARC record. The various forms of authentication form an identity to hang reputation off. No matter the alignment there is still an identity between the 3 different domains. This SPF + This DKIM + This 5322.from domain = This Mailstream This Mailstream has This Reputation. This Reputation means we’ll deliver the mail [Inbox | Spam folder] for users we don’t have specific data for. For users we do have specific data (or filters) related to This Mailstream we will deliver the mail depending on their specific preferences. DMARC is not a filtering mechanism, and it does not say anything about whether a mail is spam or not. It merely says: This company authenticates its mail in a very specific way and requests the receiver do something if the message they see is not authenticated in that very specific way. It does not say This mail is good mail or this mail should go to the inbox or this mail is wanted mail. All it says is if you see mail that is not authenticated in this way, these are the actions we’d like you to take for that mail. > Developers need to provide exception mechanisms which permit that complexity > to be implemented as local policy. This means we need language to deprecate > implementation designs that assume Fail=Malicious. > > We can't require such mechanisms as they are outside of the scope of the > protocol, but we could say it's common to do so. For that matter, Section 1 > of RFC 6647 already says this: > Absent a perfect abuse-detection mechanism that incurs no cost, the > current requirement is for an array of techniques to be used by each > filtering system. They range in cost, effectiveness, and types of > abuse techniques they target. Given the number of actual DMARC implementers, and by that I mean the folks who are writing the libraries and the underlying code to manage DMARC authentication, I don’t think we really need to go into it. This isn’t being implemented by every organization hosting their own mail, it’s being implemented by a few thousand people across dozens of independent projects. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
