Re: [dmarc-ietf] Draft DMARC working group charter

[Pete Resnick <[e-mail]>]

On 7/1/14 11:00 AM, Dave Crocker wrote:
> I've looked over the small amount of mail posted about the draft charter
> and do not see any changes mandated.
>    

Nothing mandated, but here are some changes that I think clarify and/or 
simplify. You can find a diff here:

<https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00.txt&difftype=--html&submit=Go%21&url2=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00a.txt>

Details below (including a question). Let me know if you've got any 
concerns.

I think we can get this to the IESG for review before Toronto.

> Domain-based Message Authentication, Reporting&  Conformance (DMARC)
> extends stable, domain-level validation to the RFC5322.From field. DMARC
> builds upon existing mail authentication technologies (SPF and DKIM),
> using DNS records to add policy-related requests for receivers and
> defining a feedback mechanism from receivers back to domain owners. This
> can allow a domain owner to advertise that mail, which does not
> authenticate use of the domain name in the From field, can safely
> receive differential handling, such as rejection. Existing deployment of
> DMARC has demonstrated utility at internet scale, in dealing with
> significant email abuse, and has permitted simplifying some mail
> handling processes.

Simplifying:

"Domain-based Message Authentication, Reporting & Conformance (DMARC) 
uses existing mail authentication technologies (SPF and DKIM) to extend 
validation to the RFC5322.From field. DMARC uses DNS records to add 
policy-related requests for receivers and defines a feedback mechanism 
from receivers back to domain owners. This allows a domain owner to 
advertise that mail can safely receive differential handling, such as 
rejection, when the use of the domain name in the From field is not 
authenticated. Existing deployment of DMARC has demonstrated utility at 
internet scale, in dealing with significant email abuse, and has 
permitted simplifying some mail handling processes."

Then move this bit up:
> The existing base specification is being submitted as an Independent
> Submission to become an Informational RFC.

and put a paragraph break.

> The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and will provide careful justification
> for any non-interoperability.

I think we can strike the word "careful". It doesn't add anything.

> The working group will seek to maintain
> the viability of stable domain-level identifiers in mail, and will
> document existing mail streams that do not conform to the DMARC model.
>    

I'm not sure what this means. Can someone explain?

> Working group activities will pursue three tracks:
>
>       1. Inter-Specification -- Organize and document "DMARC
>          interoperability issues", developing suggestions for
>          improvements
>    

"     1.  Addressing the issues with indirect mail flows"

It wasn't clear precisely what was being talked about.

> The working group will document the effects of DMARC on indirect mail
> flows, including deployed behaviors of many different intermediaries,
> such as mailing list managers, automated mailbox forwarding services,
> and MTAs that perform enhanced message handling that results in message
> modification.
>
> The working group will consider mechanisms for reducing or eliminating
> the DMARC's effects on indirect mail flows.  Among the choices are:
>    

We can make this smaller:

"The working group will specify mechanisms for reducing or eliminating 
the DMARC's effects on indirect mail flows, including deployed behaviors 
of many different intermediaries, such as mailing list managers, 
automated mailbox forwarding services, and MTAs that perform enhanced 
message handling that results in message modification. Among the choices 
for addressing these issues are:"

The specific work items appear below, so I think we can keep it simple here.

>       2. Intra-Specification -- Audit each part of the DMARC
>          specification (reporting, policy, auth), making improvements as
>          appropriate.
>    

"     2. Reviewing and improving the base DMARC specification"

> The base specification relies on the ability of an email receiver to
> determine the organizational domain responsible for sending mail. An
> organizational domain is the basic domain name obtained through a public
> registry, such as example.com or example.co.uk. While the common
> practice is to use a "public suffix" list to determine organizational
> domain, it is widely recognized that this solution will not scale, and
> that the current list often is inaccurate. The task of defining a
> standard mechanism for identifying organizational domain is out of scope
> for this working group. However the working group can consider extending
> the base DMARC specification to accommodate such a standard, should it
> be developed during the life of this working group.
>    

I think we can strike the second sentence. Other than reducing this 
being marked as spam ;-), I don't think it adds anything. I have no 
better understanding of what an organizational domain is from those two 
examples. (So is my organizational domain "qti.qualcomm.com" or 
"qualcomm.com"? Is it more like example.com or example.co.uk, or is it 
something different?) I think the most we're going to be able to say is 
that an organizational domain is the domain that represents the top 
level of the organization, which doesn't help much.

>       3.  DMARC Usage
>
> The working group will deliver an implementation and deployment guide.
> The guide will catalog best current operational practices in terms of
> configuration, installation, monitoring, diagnosis and reporting. It
> will also develop advice on practices that are not yet well-established
> but which are believed to be appropriate.
>    

Simplifying again:

"     3.  DMARC Usage

The working group will document operational practices in terms of 
configuration, installation, monitoring, diagnosis and reporting. It 
will catalog currently prevailing guidelines as well as developing 
advice on practices that are not yet well-established but which are 
believed to be appropriate."


>     Goals and milestones
>     --------------------
>
> Phase I:
>
>     Draft description of interoperability issues and plausible methods
> for eliminating or reducing them.  This will not include final choices.
>
>     Draft Guide on DMARC Usage
>
>
> Phase II:
>
>     Specification of DMARC improvements to support better
>     interoperability
>
>     Review and refinement of the DMARC specification
>
> Phase III:
>
>     Completion of Guide on DMARC Usage
>    

First, I think the title should be "Work items". We already have a 
separate milestones list for documents. Also, I think we should make 
Phase I just figuring out the indirect mail flow thing and get some 
proposals sorted for that and then bump stuff forward:

"Work items
----------

Phase I:

    Draft description of interoperability issues for indirect mail flows 
and plausible methods for reducing them.

Phase II:

    Specification of DMARC improvements to address indirect mail flows

    Draft Guide on DMARC Usage

Phase III:

    Review and refinement of the DMARC specification

    Completion of Guide on DMARC Usage"

>     References
>     ----------
>
> DMARC - http://dmarc.org
> SPF - RFC7208
> DKIM - RFC6376
> Internet Message Format - RFC5322
> OAR / Original Authentication Results - draft-kucherawy-original-authres
> Using DMARC -  draft-crocker-dmarc-bcp-03
>    

There was some mention of adding existing proposals to this list. Seems 
like a good idea to me.

That's all I have. Hope you find it helpful.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]