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

[Scott Kitterman <[e-mail]>]

Dave Crocker <[e-mail]> wrote:

>Scott,
>
>Would that these processes were more smooth. However...
>
>
>On 4/12/2013 2:56 PM, Scott Kitterman wrote:
>> "The initial charter for this working group does not include revising
>the base
>> specification"
>>
>> I don't think removing the work on the base specification from the
>charter
>> really addresses the concern that the previous draft charter over
>constrained
>> work on the base charter.  "You have to recharter" to make a change
>seems very
>> constraining.
>
>To charter a working group that will make changes to a specification, 
>there first must be a sense of the kinds of changes that are needed and
>desired by the folks who will develop and deploy the changes.
>
>Before bringing the spec to the IETF venue, we looked quite hard
>amongst 
>the current DMARC community for a meaningful, near-term work-list to 
>attempt on the base spec, and failed to develop one.
>
>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.  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. 

That's not a matter of changing the protocol, but improving the text.  I don't see any reason for existing implementers to fear improved text.

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

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

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.

>
>> There were a number of suggestions based on DKIM and other WG
>charters that
>> seemed to me like a good basis for balancing the concerns of existing
>> implementers with the idea of allowing an IETF working group to
>actually do
>> work.
>
>The issue is not whether random, thoughtful folk can imagine a range of
>changes to make.  The question is what is actually needed and by whom 
>and what the basis for believing this is.
>
>Start by considering that there is a recent installed base, which means
>
>that the folks currently deploying DMARC, to cover roughly 60% of the 
>world's mailboxes, would like to recover their initial investment
>before 
>making more changes.  Then consider that they haven't yet registered 
>requests for changes or enhancements.  Then please explain the basis
>for 
>changing to make more changes now?

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.  Improving and clarifying the text of the spec is similarly not a risk.

Fundamentally, rubber stamping the work of a private design team is not the IETF way.  Your arguments can be applied to almost any technology brought to the IETF with an existing constituency. 

Given the current draft charter, I think a working group is pointless. 

Scott K