Skip to main content

Domain-based Message Authentication, Reporting & Conformance
charter-ietf-dmarc-02

WG review announcement

WG Review Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: dmarc@ietf.org 
Subject: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

The Domain-based Message Authentication, Reporting & Conformance (dmarc) WG
in the Applications and Real-Time Area of the IETF is undergoing
rechartering. 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@ietf.org) by
2018-12-03.

Domain-based Message Authentication, Reporting & Conformance (dmarc)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Barry Leiba <barryleiba@computer.org>
  Ned Freed <ned+dmarc@mrochek.com>
  Tim Draegen <tim@eudaemon.net>

Assigned Area Director:
  Alexey Melnikov <aamelnikov@fastmail.fm>

Applications and Real-Time Area Directors:
  Adam Roach <adam@nostrum.com>
  Ben Campbell <ben@nostrum.com>
  Alexey Melnikov <aamelnikov@fastmail.fm>

Mailing list:
  Address: dmarc@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/dmarc
  Archive: https://mailarchive.ietf.org/arch/browse/dmarc/

Group page: https://datatracker.ietf.org/group/dmarc/

Charter: https://datatracker.ietf.org/doc/charter-ietf-dmarc/

   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
   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

      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.

   References
   ----------

   DMARC - http://dmarc.org
   SPF - RFC7208
   Authentication-Results Header Field - RFC7001
   DKIM - RFC6376
   Internet Message Format - RFC5322
   OAR / Original Authentication Results -
      draft-kucherawy-original-authres
   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

Milestones:

  Done     - Complete Authenticated Received Chain (ARC) protocol spec

  Jan 2019 - Complete EAI update to SPF/DKIM/DMARC

  Feb 2019 - Complete Authenticated Received Chain (ARC) usage recommendations


WG action announcement

WG Action Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
    dmarc@ietf.org,
    dmarc-chairs@ietf.org 
Subject: WG Action: Rechartered Domain-based Message Authentication, Reporting & Conformance (dmarc)

The Domain-based Message Authentication, Reporting & Conformance (dmarc) WG
in the Applications and Real-Time Area of the IETF has been rechartered. For
additional information, please contact the Area Directors or the WG Chairs.

Domain-based Message Authentication, Reporting & Conformance (dmarc)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Barry Leiba <barryleiba@computer.org>
  Ned Freed <ned+dmarc@mrochek.com>
  Tim Draegen <tim@eudaemon.net>

Assigned Area Director:
  Alexey Melnikov <aamelnikov@fastmail.fm>

Applications and Real-Time Area Directors:
  Adam Roach <adam@nostrum.com>
  Ben Campbell <ben@nostrum.com>
  Alexey Melnikov <aamelnikov@fastmail.fm>

Mailing list:
  Address: dmarc@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/dmarc
  Archive: https://mailarchive.ietf.org/arch/browse/dmarc/

Group page: https://datatracker.ietf.org/group/dmarc/

Charter: https://datatracker.ietf.org/doc/charter-ietf-dmarc/

   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
   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 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
   technologies.

   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.

   References
   ----------

   DMARC - http://dmarc.org
   SPF - RFC7208
   Authentication-Results Header Field - RFC7001
   DKIM - RFC6376
   Internet Message Format - RFC5322
   OAR / Original Authentication Results -
      draft-kucherawy-original-authres
   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

Milestones:

  Done     - Complete Authenticated Received Chain (ARC) protocol spec

  Jan 2019 - Complete EAI update to SPF/DKIM/DMARC

  Feb 2019 - Complete Authenticated Received Chain (ARC) usage recommendations


Ballot announcement

Ballot Announcement

Technical Summary

   Relevant content can frequently be found in the abstract
   and/or introduction of the document.  If not, this may be 
   an indication that there are deficiencies in the abstract
   or introduction.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

Personnel

   Who is the Document Shepherd for this document?  Who is the 
   Responsible Area Director?  If the document requires IANA
   experts(s), insert 'The IANA Expert(s) for the registries
   in this document are <TO BE ADDED BY THE AD>.'

RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IRTF Note

  (Insert IRTF Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)