Greetings. The theoretical goal of any domain owner that publishes a DMARC record is to transition from an initial policy of p=none to a final one of p=reject, because it is only at p=reject that DMARC's intended purpose of preventing same-domain spoofing can be fully realized.
Many domain owners see the transition from p=none to p=reject as a black box, in that they believe they have no way of knowing what the full impact of such a change might have on their mail, and they fear irreparable harm to their mail if they make a mistake. The designers of DMARC anticipated this fear, and built several different transitional states, or ratchets, into the protocol, including: - The "pct" tag (https://trac.ietf.org/trac/dmarc/ticket/47) - The "sp" tag (https://trac.ietf.org/trac/dmarc/ticket/48) - "quarantine" as a value for "p=" ( https://trac.ietf.org/trac/dmarc/ticket/39) All of these are designed to allow the domain owner to request that some, but not all, of its mail be held to stricter authentication standards so that the domain owner can dip a toe in the water before jumping in. The ratchets have introduced some problems, though: - The 'pct' tag doesn't exactly work like it's intended to, and really can't because of the nature of mail flow, unless there is a high volume of failed authentication for the domain in question. (There is a much longer discussion of this in section 6.7.4, Message Sampling, of draft-ietf-dmarc-dmarcbis-02.) - Some domain owners have taken a "more is more" approach to ratchets, figuring if one is good, all are better, resulting in needlessly complicated policy records The purpose of this email is to get folks thinking about possibly simplifying the ratchet mechanisms, perhaps boiling them down into one. This thinking and on-list discussion on this topic would serve as a precursor to further face-to-face discussion at the next interim working group meeting. I'll start the discussion by taking an extreme position... Ratchet mechanisms don't help in any way that a short TTL on your DMARC record won't help, and in fact you need the short TTL on your record anyway, because if you're trying a ratchet mechanism and find it's too much, you still gotta update DNS to roll it back. Getting to p=reject isn't a difficult undertaking, at least from a technical standpoint. Enumerate all your mail streams, ensure that they're authenticating properly, and boom, you're done. The proper tools for doing that are p=none, a rua tag pointed at a mailbox that is parsed by automated means, active daily monitoring of the data consumed in those aggregate reports (so that mail streams can be enumerated and authentication problems addressed), and time. Time is the big one here, because sufficient time must elapse to ensure that all of your legitimate mail streams are exercised and reported upon, and that can take many months in large organizations or at companies that are in the business of seasonal email sending. The big challenge to fixing authentication issues, especially in large organizations, is usually in just finding who owns the host/process that's generating that unauthenticated mail. That can add time to the process, but once you've enumerated them all, updated your SPF record and/or made sure they're all properly DKIM signing, you can skip right from p=none to p=reject. I look forward to lively conversation... -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* [email protected] *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
