* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dmarc Status Pages

Domain-based Message Authentication, Reporting & Conformance (Concluded WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2014-Aug-11 —  

2021-04-15 charter

Domain-based Message Authentication, Reporting & Conformance (dmarc)


 Current Status: Active

     Barry Leiba <barryleiba@computer.org>
     Seth Blank <seth@valimail.com>

 Applications and Real-Time Area Directors:
     Murray Kucherawy <superuser@gmail.com>
     Francesca Palombini <francesca.palombini@ericsson.com>

 Applications and Real-Time Area Advisor:
     Murray Kucherawy <superuser@gmail.com>

 Mailing Lists:
     General Discussion: dmarc@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/dmarc
     Archive:            https://mailarchive.ietf.org/arch/browse/dmarc/

Description of Working Group:

     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. 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 (for example, mailing
     lists, publish-to-friend functionality, mailbox forwarding via
     ".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 DMARC compatibility.

     The existing DMARC base specification is published as Informational
     RFC 7489 in the Independent Stream.

     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

     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

     Working group activities will pursue four 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 desirable uses of existing authentication

     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

        4. Related work

     Extensions to SPF/DKIM/DMARC that do not already fit under
     the charter of any existing working group can be considered for adoption
     by DMARC Working Group after consultation with the responsible AD.
     A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related
     updates to DMARC and the protocols upon which it depends.
     Any such work needs to carefully consider interoperability implications.

     Work Items

     Phase I:

        Draft description of interoperability issues for indirect mail
        flows and plausible methods for reducing them.  This is now
        complete and published as RFC 7960.

     Phase II:

        Specification of DMARC improvements to support indirect mail flows;
        this is now complete as draft-ietf-dmarc-arc-protocol (ARC).

        Draft Guide on DMARC Usage.

     Phase III:

        Review and refinement of the DMARC specification.

        Completion of Guide on DMARC and ARC Usage.


     DMARC - http://dmarc.org
     SPF - RFC7208
     Authentication-Results Header Field - RFC7001
     DKIM - RFC6376
     Internet Message Format - RFC5322
     OAR / Original Authentication Results -
     Using DMARC -  draft-crocker-dmarc-bcp-03
     Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
     DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

Goals and Milestones:
  Done     - Complete Authenticated Received Chain (ARC) protocol spec

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/dmarc/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -