[dmarc-ietf] Priming the Pump for Discussion - Ratchets

[Todd Herr <[e-mail]>]

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:* [e-mail]
*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.