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

Matt Simerson <> Thu, 23 May 2013 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A62321F974C for <>; Thu, 23 May 2013 15:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id orPT2jFvv3HL for <>; Thu, 23 May 2013 15:09:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9EC2521F8491 for <>; Thu, 23 May 2013 14:24:37 -0700 (PDT)
Received: (qmail 62378 invoked by uid 1026); 23 May 2013 21:24:36 -0000
Received: from (HELO []) ( by (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Thu, 23 May 2013 17:24:36 -0400
Authentication-Results:; auth=pass (plain); iprev=pass
X-Virus-Checked: by ClamAV 0.97.7 on
X-Virus-Found: No
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed;; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=mar2013; bh=A9n7A6Car3Jn4UFqZh1hwASqqYtvXLlERQqgE2BvHKc=; b=L3Sc35R4U97VcV7vo6e5wJDXFQhH6/Tmw1T2DEjQAXLkvE1KNQvZhYIKBjZDLWSdKZTbdkV/EA1K60gYpcoi1t3zzldWXZ8xEi+mXOHDinFvA/hhFrwkhS6Tba2+Yw/SZXqI7gYYgPevaZqUg8v1qnXJVQ8ptlzYkqM0wvMNprLdlsF4xbqrQsDmAGpG3BVl29o6xt0TBe5n4JnrVcitFKQMKyf/pSKzjbviaHmQldda7gIJKTQ8WlCcqQV1dAK6EpLNk/qJz9ZrK25X5e4yAqRyKCzIItwVxO4fX2CLOXA0gP0zthJuGSu+lnqLcdNgpitufBGE25vRXRNjmpnUKA==
X-HELO: []
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Matt Simerson <>
In-Reply-To: <20130523181505.26913.qmail@joyce.lan>
Date: Thu, 23 May 2013 14:24:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20130523181505.26913.qmail@joyce.lan>
To: John Levine <>
X-Mailer: Apple Mail (2.1503)
Cc:, Eliot Lear <>
Subject: Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC spec
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 22:09:27 -0000

On May 23, 2013, at 11:15 AM, "John Levine" <> wrote:

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

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.


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