Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

[Dave Crocker <[e-mail]>]

(re-posted under my ietf-dmarc subscription address, rather than ietf
one.  content otherwise the same.  /d)


On 7/14/2014 9:42 AM, The IESG wrote:
> A new IETF working group has been proposed in the Applications Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-24.

The first paragraph of a charter is circulated independently of the
rest, such as when announcing the working group.

As such, it needs to serve as a kind of abstract.  This is why there is
a requirement, specified in RFC 2418 (WG Guidelines & Procedures),
"Description of working group:

     "The first
      paragraph must give a brief summary of the problem area, basis,
      goal(s) and approach(es) planned for the working group..

>  Charter:
> 
>    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.
> 
>    The existing base specification is being submitted as an Independent
>    Submission to become an Informational RFC.
> 
>    However, DMARC is problematic for mail that does not flow from
>    operators having a relationship with the domain owner, directly to
>    receivers operating the destination mailbox. Examples of such
>    "indirect" flows are mailing lists, publish-to-friend functionality,
>    mailbox forwarding (".forward"), and third-party services that send
>    on behalf of clients. The working group will explore possible updates
>    and extensions to the specifications in order to address limitations
>    and/or add capabilities. It will also provide technical
>    implementation guidance and review possible enhancements elsewhere in
>    the mail handling sequence that could improve could DMARC
>    compatibility.

The DMARC draft charter's first paragraph does not state any goals.
This can be fixed by moving the last two sentences of the third
paragraph, to the end of the first.

That is, end the first descriptive paragraph with:

  "The working group will explore possible updates
  and extensions to the specifications in order to address limitations
  and/or add capabilities. It will also provide technical
  implementation guidance and review possible enhancements elsewhere in
  the mail handling sequence that could improve could DMARC
  compatibility.

and delete it from it's current position.




>    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


This is missing two citations that I thought were supposed to be
included, since they touch on indirect email flows:

   Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net