On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster < 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. 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. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
