Re: DMARC: perspectives from a listadmin of large open-source lists

Dave Crocker <> Tue, 15 April 2014 16:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F24F21A049C for <>; Tue, 15 Apr 2014 09:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MsN-ac6wk4jl for <>; Tue, 15 Apr 2014 09:27:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C1241A048A for <>; Tue, 15 Apr 2014 09:27:47 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s3FGRew6015649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 09:27:44 -0700
Message-ID: <>
Date: Tue, 15 Apr 2014 09:25:40 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Scott Kitterman <>,
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
References: <20140414024956.26078.qmail@joyce.lan> <> <> <1485381.SfhK6qmW0I@scott-latitude-e6320>
In-Reply-To: <1485381.SfhK6qmW0I@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Tue, 15 Apr 2014 09:27:44 -0700 (PDT)
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:27:52 -0000

On 4/14/2014 8:35 PM, Scott Kitterman wrote:
> On Monday, April 14, 2014 10:26:44 Murray S. Kucherawy wrote:
>> I mentioned in another thread that the DMARC people did come to the IETF to
>> ask for a working group to complete development of the work on the
>> standards track.  This request was denied on the grounds that DMARC was
>> essentially already done, and thus the IETF had nothing engineering-wise to
>> contribute.  There were also too few people that were not already DMARC
>> proponents that would commit to working on it.
>> (And as I said on that other thread, I'm happy to stand corrected if I've
>> mischaracterized any of that.)
> My perception (and it may also be wrong) is that anyone who claimed there was
> work yet to be done was shouted down.

Given that the exchanges were on an open mailing list, I'm not quite 
sure what that means.

What I am sure of is that I've pressed quite vigorously and repeatedly, 
first on the open mailing list and then on the IETF DMARC 
mailing list, for folk to cite work that needed to be done and to 
develop group support for that work.

What I saw was some individuals suggesting some bits of work, but no 
support developed around it.  (By 'support' I mean more than a few folk.)

Perhaps you can point to specific examples of this 'shouting down' 

What I also saw was some folk insisting that the charter be vague and 
unconstrained, with no concern for the installed base.

> As I said in the other thread, I think the only reason it was perceived as
> done is that the private group that developed the spec declared it done and
> fought against any WG charter language that would have permitted changes to
> the core protocol.    Based on that approach, no wonder it was declined.

Changes to the core of a protocol is the essence of de-stabilizing its 
installed base.

Writing a charter that permits de-stabilizing a substantial installed 
base only makes sense when there is a clear and compelling basis already 
known for needing to make such changes.

With respect to DMARC, none has been offered or has developed community 

Writing a charter that permits de-stablilizing an installed base 
covering 60% of the world's email traffic, in the absence of a clear and 
compelling understanding of the need would be irresponsible.

Arguably, the mere existence of such a charter would be de-stabilizing, 
since it means that anyone considering adoption has an excuse to defer 
it to the indefinite future, when the IETF might get around to releasing 
a revision.


Dave Crocker
Brandenburg InternetWorking