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

[Matt Simerson <[e-mail]>]

On May 23, 2013, at 11:15 AM, "John Levine" <[e-mail]> wrote:

> I agree with pretty much everything Eliot said.

+1

> 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.

I have written two implementations of DMARC (one merely validates, the other (Mail::DMARC) is mostly complete and does validation as well as send/receive aggregate reports. As an implementer, my "indulgence" is heartily extended. I would much prefer a more straight forward and concise specification. 

> 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 wonder whether DMARC shouldn't be two specifications? It seems that the validation portions of DMARC are well defined, straight forward to implement, and could easily be implemented by most modern MTAs (whether by milter, Amavis, or SpamAssassin). 

The reporting aspects OTOH, are complex and encumbered with technical issues, security issues and sticky legal questions about information disclosure. While the reporting is valuable, its value will certainly be diminished by the number of organizations that implement it.

> The reporting stuff is useful to see what sort of mail purporting to
> be from you is arriving at the sites that send reports.

+1

> For some domains, it may be useful to see how much you're being phished.

It is also useful to see how many DMARC deploying sites fail to validate the DKIM signatures. For the DMARC receiver, reporting is a burden.  But as a domain author, DMARC reporting is very useful. 

> 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.

I implemented with rand:

$result->reason( type => 'sampled_out' ) if rand(100) >= $policy->pct;

Matt