Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC spec

["John Levine" <[e-mail]>]

I agree with pretty much everything Eliot said.  Fortunately, having
written a DMARC implementation that handles everything other than
sending reports (the stuff is in a database, I could do it if I wanted
to) I believe the problems can be fixed with little or no change to the
bits on the wire.

DMARC does two separate things.  One is the policy stuff, what a
domain would like you to do if you see mail with their domain on the
From: line and no corresponding DKIM or SPF authentication.  The other
is the report stuff, requesting per-message and daily aggregate
reports from the world about the authentication results of mail with
your domain on the From: line.

The two parts have practically nothing to do with each other other
than sharing the _dmarc DNS record and it's quite possible to use
one without the other.  I've collected lots of interesting stats
for domains that will never publish a DMARC policy.

As far as what it does, or what it's good for, the policy stuff does
one very specific thing, denouncing unauthenticated mail with your
domain on the From: line.  For some senders, that category of mail
matches up well with a narrow but significant category of phishing.
For others it may match up with phish-like behaviors in which company
employees send mail from outside to avoid routing mail through the
corporate servers (a big issue for stockbrokers and the like where the
servers log everything.)  For a lot of senders, e.g., ISPs, the policy
isn't useful at all since the authentication model doesn't match what
their users do.  I would strenuously resist any attempts to claim that
it does more, particularly attempts to make it the FUSSP of the month,
often from people who should know better.

The reporting stuff is useful to see what sort of mail purporting to
be from you is arriving at the sites that send reports.  For some
domains, it may be useful to see how much you're being phished.  If
you're a stockbroker, it could be useful to find people evading the
server logging by sending from gmail.  Again, I would resist attempts
to claim that it does more than what it does, send reports which may
tell you interesting things about your mail (and in the security
section, note that it can also tell you interesting things about other
people's mail, e.g., the mailing lists that your users subscribe to.)

All but one of the technical comments seem on target.  I think the
protocol is OK, but the description needs to be edited down be a
description of what it does, leaving out all the reasons it's
wonderful.

Nit about the pct phrase:

>8.  This requires that state be maintained on a receiver, and could be an
>attack vector.

I implement it as perform policy if (time mod 100) < pct, which I
think is what everyone else does, no DMARC state needed.  It's worth
mentioning this as an adequate implementation.

R's,
John