Re: WG Review: Domain-based Message Authentication, Reporting & Conforma

I will not comment on the 85 messages in the thread.  However, I would like to 
point out that STIR is working on a similar problem with similar goals but in a 
more constrained environment.  I would offer coordination between WG’s, should 
DMARC be chartered, would be “a good thing.”

On Jul 14, 2014, at 12:42 PM, The IESG <iesg-secretary(_at_)ietf(_dot_)org> 
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.
>
> Domain-based Message Authentication, Reporting & Conformance (dmarc)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Assigned Area Director:
>  Pete Resnick <presnick(_at_)qti(_dot_)qualcomm(_dot_)com>
>
> Mailing list
>  Address: dmarc(_at_)ietf(_dot_)org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc
>  Archive: http://www.ietf.org/mail-archive/web/dmarc/
>
> 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.
>
>   Specifications produced by the working group will ensure preservation
>   of DMARC utility for detecting unauthorized use of domain names,
>   while improving the identification of legitimate sources that do not
>   currently conform to DMARC requirements. Issues based on operational
>   experience and/or data aggregated from multiple sources will be given
>   priority.
>
>   The working group will seek to preserve interoperability with the
>   installed base of DMARC systems, and provide detailed justification
>   for any non-interoperability. As the working group develops solutions
>   to deal with indirect mail flows, it will seek to maintain the
>   end-to-end nature of existing identifier fields in mail, in
>   particular avoiding solutions that require rewriting of originator
>   fields.
>
>
>   Working group activities will pursue three tracks:
>
>      1. Addressing the issues with indirect mail flows
>
>   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:
>
>      - A form of DKIM signature that is better able to survive transit
>        through intermediaries.
>
>      - Collaborative or passive transitive mechanisms that enable an
>        intermediary to participate in the trust sequence, propagating
>        authentication directly or reporting its results.
>
>      - Message modification by an intermediary, to avoid authentication
>        failures, such as by using specified conventions for changing
>        the aligned identity.
>
>   Consideration also will be given to survivable authentication through
>   sequences of multiple intermediaries.
>
>
>      2. Reviewing and improving the base DMARC specification
>
>   The working group will not develop additional mail authentication
>   technologies, but may document authentication requirements that are
>   desirable.
>
>   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 'base' name that is allocated from a
>   public registry; examples of registries include ".com" or ".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.
>
>   Improvements in DMARC features (identifier alignment, reporting,
>   policy preferences) will be considered, such as:
>
>      - Enumeration of data elements required in "Failure" reports
>        (specifically to address privacy issues)
>      - Handling potential reporting abuse
>      - Aggregate reporting to support additional reporting scenarios
>      - Alternate reporting channels
>      - Utility of arbitrary identifier alignment
>      - Utility of a formalized policy exception mechanism
>
>
>      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.
>
>   The group will consider separating configuration and other deployment
>   information that needs to be in the base spec, from information that
>   should be in a separate guide.
>
>   Among the topics anticipated to be included in the document are:
>
>      - Identifier alignment configuration options
>      - Implementation decisions regarding "pct"
>      - Determining effective RUA sending frequency
>      - Leveraging policy caching
>      - Various options for integrating within an existing flow
>      - Defining a useful, common set of options for the addresses to
>        which feedback reports are to be sent
>      - When and how to use local policy override options
>
>
>   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 support 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
>
>
> Milestones:
>
> TBD

signature.asc
Description: Message signed with OpenPGP using GPGMail