ietf
[Top] [All Lists]

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

2014-07-16 10:04:29
(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

<Prev in Thread] Current Thread [Next in Thread>