Re: [apps-discuss] Revised DMARC working group charter proposal

Dave Crocker <> Sat, 13 April 2013 11:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0333521F8496 for <>; Sat, 13 Apr 2013 04:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id byDqwZjt0xnb for <>; Sat, 13 Apr 2013 04:38:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6240121F848D for <>; Sat, 13 Apr 2013 04:37:58 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r3DBbvsN021837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Apr 2013 04:37:58 -0700
Message-ID: <>
Date: Sat, 13 Apr 2013 04:37:47 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <>
References: <> <6600677.x1Szm294G3@scott-latitude-e6320> <> <>
In-Reply-To: <>
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 ( []); Sat, 13 Apr 2013 04:37:58 -0700 (PDT)
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Apr 2013 11:38:04 -0000


On 4/12/2013 11:00 PM, Scott Kitterman wrote:
>> So Scott, what changes to the DMARC base spec are you seeking and
>> why and who wants them and how do we know this?
> In part, I don't. DMARC has been developed in private by a relatively
> small group of people. I think it's not unreasonable to consider the
> spec might be improved by broader review.

    It's entirely reasonable.  That's why the draft charter provides for 
such future effort: "However, if resolving any of the issues listed in 
the areas of focus below does require changes to the base specification, 
or if the specification needs to be revised to correct technical errors 
deemed essential for proper use, the group will recharter accordingly."

    The specification has been public for considerably more than a year, 
including a press release and a public discussion list, with adoption 
covering roughly 60% of the world's mailboxes.  That's not a small base 
of experience.  So there's been plenty of opportunity for community 
review and input, including requests for changes.  And yet, there is so 
far no such list of requests.

 >  Things that were written
> by people who already "know" what the spec is supposed to mean are
> often less clear to those outside the group. Until a broader group
> actually reviews it, there's no way to know.

   You are correct, of course.  However the range of implementers now 
goes considerably beyond the original group, and yet there is so far no 
concrete list of interesting changes being requested.

> That's not a matter of changing the protocol, but improving the text.

    Well, that's what we originally submitted for chartering, but at 
least one AD didn't like it.

> The one thing I think does need to be changed is the policy override
> approach.  Changing SPF policy based on DMARC is a layering violation
> at the very least.

    Sorry, but I'm missing the reference.  Please point to the section 
of text you don't like and describe the kind of change you are seeking.

(FWIW, on reflection, I'm not a fan of the term policy override, since 
it implies that the recipient has somehow been bound to conformance to 
the sender's policies...)

> While reading the envelope (HELO/5321.Mail From) I
> have to change processing based information in the body (5322.From).
> Many SPF implementations don't have access to the body making it
> difficult to implement correctly.

    If they are doing DMARC, they do have access.

> Not only is the current design wrong, it's nor needed to solve the
> problem DMARC was meant to solve.

    Sounds like a protocol change.  That's rather more than merely 
improving the text.

> Similarly, due to this override, a DMARC policy of none can't be used
> just to collect data as it will change mail processing as well.

    I don't understand.

> The current design is wrong. The specific issues I'm concerned with
> now can be resolved without forcing existing implementers to change
> anything, so no investment is at risk.

    The idea that one can change a design, without having to change 
code, is new to me.  Please explain.

> Fundamentally, rubber stamping the work of a private design team is
> not the IETF way.

    What part of the work in the latest draft charter would produce 
rubber stamping?

    But since you are being pedagogical about how the IETF does things, 
please note that working group charters are supposed to specify the 
nature of the work to be done.  Working groups that start without a 
sense of what problem they are trying to solve to tend to have poor 
outcomes.  If you can specify the nature of the technical, work to be 
done, sufficiently to garner support for it, then it's certainly worth 

  Dave Crocker
  Brandenburg InternetWorking