On Monday, July 14, 2014 10:31:23 Dave Crocker wrote:
> 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
If we're adding references, I think RFC 7001, Message Header Field for
Indicating Message Authentication Status, should be included as well. It's, I
think a matter for the WG to decide if RFC 7001 provides enough or if an
extension like OAR is needed.
Scott K