Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

Hector Santos <> Tue, 15 April 2014 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20D5C1A04B7 for <>; Tue, 15 Apr 2014 09:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -97.501
X-Spam-Status: No, score=-97.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6nK8Bo_lr0bS for <>; Tue, 15 Apr 2014 09:03:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 708031A04A9 for <>; Tue, 15 Apr 2014 09:03:01 -0700 (PDT)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5298; t=1397577770; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MpQYlFwbB8kLyeyboUJkOFKVVxg=; b=CnAbDTekLpaymCqwjxbY nXvtaMceOKbF+W+cqbdp2FLN8bEH8xEQJSi9mm4a67F+O6IFZYtKUVy+Ot4es3+i 7iROVIT+7jRsht8CiBQwiv5cem7e42lmLiwFlVzEkPLhDb/ynta4XsBtnoZc8sh3 arVqSDPEHuX0I5AjqlNusO4=
Received: by (Wildcat! SMTP Router v7.0.454.4) for; Tue, 15 Apr 2014 12:02:50 -0400
Authentication-Results:; dkim=pass header.s=tms1; adsp=pass policy=all;
Received: from ( []) by (Wildcat! SMTP v7.0.454.4) with ESMTP id 686346756.3.3464; Tue, 15 Apr 2014 12:02:49 -0400
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5298; t=1397577704; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Iky5OgR x2jaureC6Y3jQ4kKEbZohBl5JN/wyIVgyfJs=; b=qhAoSCkGSXgd+Pn3Eh9eDCO FOSJ68IjLcC154NuikbO3vRRIzwzYo6P8qHrC1TLADK13pVO0GauUhdhfZopdmQi U9tNFP4vWFGnkHQWmjvDZcGGoO5tKlPsy/qH1mM/lQHe99xjsJTqH8R+ait1sku5 8hoXVOC15smYJMt3DRtA=
Received: by (Wildcat! SMTP Router v7.0.454.4) for; Tue, 15 Apr 2014 12:01:44 -0400
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.4) with ESMTP id 705880390.9.9008; Tue, 15 Apr 2014 12:01:43 -0400
Message-ID: <>
Date: Tue, 15 Apr 2014 12:02:49 -0400
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Sabahattin Gucukoglu <>, " list" <>
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
References: <> <> <> <5593510.KZqL8eSkZ2@scott-latitude-e6320> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Apr 2014 16:03:06 -0000

On 4/15/2014 12:32 AM, Sabahattin Gucukoglu wrote:
> Basically DMARC was always an outsider effort.  The effect of a bunch of very important ESPs (and a bunch of security types) crying "Look!  We've solved the email forgery problem!" was to inspire me to look at the spec, shrug it off as yet another FUSSP *, and move on.  Does this mean that I have materially failed to contribute?  Well maybe, but it means a lot for the spec to be in the IETF where I can point out how broken it is. :)

I feel the same way.

But after the whole stressful, wasteful dollars, time and energy 
situation over 9 years starting with DKIM+SSP, reduced to DKIM+ADSP or 
DKIM+POLICY in general,  it is not healthy to repeat this with DMARC.

It was clear DMARC couldn't address the key central total mail 
integration support requirements if it lacked two things:

   - 3rd party policies,
   - MLM/MLS support for restrictive policies.

> And, to be clear: I respect the goals of the proposal, and will be reasonable in accommodating it.  But to suggest that the contortions of the proponents in keeping it from the watchful eye of the IETF weren't in some small way intended to advance DMARC by force in numbers rather than consensus strains credulity, just a tad.

Yes, that was an obvious problem, marketing hype we tend to ignore, 
but it was a concern that they were just repeating the same issues. 
Lets remember that DMARC was more about reporting than actually 
honoring and literally "rejecting" transactions.  Reporting was since 
as a potential mail-based DoS attack vector. So my input was to limit 
it to TESTING periods and under abuse controls when it was suggested 
to DKIM+POLICY reporting.

We saw this again repeated with SPF when in the SPFBIS, the same 
people mind you, began to add DOUBT on the whether anyone actually did 
reject mail and just simply quarantine the mail.  So it became a battle of


When I saw that mentality grow, I raised an SPFBIS issue to make sure 
we describe in the spec as two alternative implementation and 
deployment option:


Without separation, we have a security loophole if the deployment did 
not operate by rejecting SPF Failure but instead accepted, marked it 
with an Auth-Res header but still delivered the failed message to the 

And guess what?

Its happening now again with the new Yahoo/Facebook RRVS proposal. 
Again, they are raising the question if whether a reject should be 
taken literally or not.

IMO, what has occurred now is a realization that there are actual 
systems that are beginning to actually reject the mail based on 
restrictive policies.  When it happen to a big long time publicly used 
domain like, now it became a major problem.

Anyway, it is really too tiresome and stressful to repeat all this.

I thought it was a major mistake and IETF error to make ADSP historic, 
done to help make way for DMARC.  Who are we kidding?  But if thats 
the case, once again, the solution is simple:

  - Add 3rd party policy support,

  - In DMARC deployment guide, provide strong semantics for MiddleWare
    to support policies.  It can not be ignored.

With the latter, it was a mistake in the DKIM deployment guide to not 
raise an  Middle Ware resigning implementation note about not honoring 
ADSP checking.  This issue was raised when the document was written 
but largely ignored.

Again, we been through all this. It is all covered with the DKIM 
threat analysis and one of the main conclusions is that self-signing 
1st party policies are a powerful method to protect against fraud. 
ADSP was a proposed standard track work item along with DKIM-base. 
DKIM-WG ended on a sour note never resolving this basic issue.

The only reason common agreement and question was whether we can scale 
the 3rd party domain authorizations.

So what did we do?

Eventually, Murray saw the issue wouldn't go away. I talked about ASL 
(Authorized Signer List) which piggy backed off the ADSP record. It 
was meant for the smaller systems. Doug Otis talked about TPA (Third 
Party Authorization) but it was too complex.  So Murray did ATPS as an 
ADSP extension to help with the complexity and scalability questions.

See the wizard at

which allows you to create zone records for ADSP+ATPS+ACL domains.  We 
implemented this into our software and mail system product, including 
the MLS that will deny restrictive ADSP domains.

The work was done.  The solutions and conflicts are known. The 
question is more a matter of getting people to accept policy more or 
as some will like, get rid of it or just don't really honor any kind 
of mail rejection -- always accept, mark and hopefully separate.

And lets not forget, the DKIM+TRUST model which is what Crocker and 
Levine want to see happen.  This market has not materialized 
unfortunately, which would be different than the DKIM+POLICY 
framework, in that TRUST requires all nodes in the system to query the 
same trust databases, otherwise we lack consistency and persistency in 
mail distributions.  Some nodes will become targets if they lack 
subscription to a 3rd party TRUST query system.