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

[Dave Crocker <[e-mail]>]

Scott,


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


d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net