DMARC & Indirect Mail: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

Internet Engineering Task Force (IETF)                    F. Martin, Ed.
Request for Comments: 7960                                      LinkedIn
Category: Informational                                     E. Lear, Ed.
ISSN: 2070-1721                                       Cisco Systems GmbH
                                                         T. Draegen, Ed.
                                                          dmarcian, inc.
                                                          E. Zwicky, Ed.
                                                                   Yahoo
                                                        K. Andersen, Ed.
                                                                LinkedIn
                                                          September 2016


  Interoperability Issues between Domain-based Message Authentication,
      Reporting, and Conformance (DMARC) and Indirect Email Flows

Abstract

   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) introduces a mechanism for expressing domain-level policies
   and preferences for email message validation, disposition, and
   reporting.  However, the DMARC mechanism enables potentially
   disruptive interoperability issues when messages do not flow directly
   from the author's administrative domain to the final Recipients.
   Collectively, these email flows are referred to as "indirect email
   flows".  This document describes these interoperability issues and
   presents possible methods for addressing them.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7960.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
      1.1. Document Conventions .......................................4
   2. Causes of Interoperability Issues ...............................4
      2.1. Identifier Alignment .......................................4
           2.1.1. DKIM Identifier(s) ..................................5
           2.1.2. SPF Identifier(s) ...................................6
           2.1.3. Multiple RFC5322.From Addresses .....................6
      2.2. Message Forwarding .........................................6
      2.3. Message Modification .......................................7
   3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
      3.1. Message Handling System ....................................8
           3.1.1. Message Submission Agents ...........................8
           3.1.2. Message Transfer Agents .............................9
                  3.1.2.1. Message Encoding ...........................9
                  3.1.2.2. Header Standardization ....................10
                  3.1.2.3. Content Validation ........................10
           3.1.3. Message Delivery Agents ............................10
      3.2. Mediators .................................................11
           3.2.1. Alias ..............................................11
           3.2.2. ReSenders ..........................................12
           3.2.3. Mailing Lists ......................................12
                  3.2.3.1. Mailing List Operational Effects ..........13
           3.2.4. Gateways ...........................................13
           3.2.5. Boundary Filters ...................................14
      3.3. Combinations ..............................................15
   4. Possible Mitigations of Interoperability Issues ................15
      4.1. Mitigations in Current Use ................................16
           4.1.1. Mitigations for Senders ............................16
                  4.1.1.1. Identifier Alignment ......................16
                  4.1.1.2. Message Modification ......................17
           4.1.2. Mitigations for Receivers ..........................17

                  4.1.2.1. Identifier Alignment ......................17
                  4.1.2.2. Policy Override ...........................17
           4.1.3. Mitigations for ReSenders ..........................18
                  4.1.3.1. Changes to the RFC5322.From ...............18
                  4.1.3.2. Avoiding Message Modification .............18
                  4.1.3.3. Mailing Lists .............................18
      4.2. Proposed and In-Progress Mitigations ......................20
           4.2.1. Getting More Radical: Requiring New
                  Communication Paths between MUAs ...................21
   5. Security Considerations ........................................21
   6. References .....................................................22
      6.1. Normative References ......................................22
      6.2. Informative References ....................................23
   Appendix A.  Example SPF Bounce ...................................24
     A.1.  Initial Message ...........................................24
     A.2.  Notification Message ......................................25
   Acknowledgments ...................................................26
   Authors' Addresses ................................................27

1.  Introduction

   DMARC [RFC7489] introduces a mechanism for expressing domain-level
   policies and preferences for message validation, disposition, and
   reporting.  The DMARC mechanism, especially when employed with
   restrictive policies, encounters several different types of
   interoperability issues due to third-party message sourcing, message
   transformation, or rerouting.  In particular, DMARC with restrictive
   policies causes problems for many Mailing Lists.

   At the time of writing this document, the DMARC base specification
   has been published as Informational RFC 7489 [RFC7489] and has seen
   significant deployment within the email community.

   Cases in which email does not flow directly from the author's
   administrative domain to the recipient's domain(s) are collectively
   referred to in this document as "indirect email flows".  Due to
   existing and increasing adoption of DMARC, the impact of DMARC-based
   email rejection policies on indirect email flows can be significant
   for a select subset of general email traffic.

   Several known causes of interoperability issues are presented,
   followed by a description of components within the Internet Mail
   Architecture [RFC5598] where interoperability issues can arise.

   Finally, known and possible methods for addressing interoperability
   issues are presented.  There are often multiple ways to address any
   given interoperability issue.  While this document strives to be
   comprehensive in its review, it should not be treated as complete.

   Note that some practices that are in use at the time of this document
   may or may not be "best practices", especially as future standards
   evolve.

1.1.  Document Conventions

   The notation used in this document for structured fields is taken
   from [RFC5598], Section 1.3.

   The term "notification message" ([RFC5321], Section 4.5.5) is used to
   refer to a message with a null RFC5321.MailFrom.

   The terms "Organizational Domain" and "Authenticated Identifiers" are
   specified in DMARC ([RFC7489], Section 3).

   All words that begin with capital letters take their formal meanings
   from these references.

2.  Causes of Interoperability Issues

   Interoperability issues between DMARC and indirect email flows arise
   when conformance to the DMARC specification leads a receiving
   implementation to apply DMARC-based policy restrictions to messages
   that are both compliant with the architecture as specified in
   [RFC5598] and viewed as legitimate by the intended Recipient.

   Note that domains that assert a "p=none" policy and email messages
   that pass standard DMARC validation do not have any interoperability
   issues.

   Email messages that do not conform to IETF email specifications but
   are considered legitimate by the intended Recipients are not
   discussed in this document.

   The rest of this section describes several conceptual causes of
   interoperability issues.

2.1.  Identifier Alignment

   Note to operators and administrators: The identifiers that are used
   by the Sender Policy Framework (SPF) are technical components of the
   transport process for SMTP.  They may or may not, as described below,
   bear a meaningful relationship to the content or source of the
   message itself.  This "relationship by proximity" can be a point of
   confusion for non-technical end users, either recipients or senders.

   DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF
   [RFC7208] to perform message source validation.  The DMARC [RFC7489]
   specification refers to source domains that are validated by DKIM or
   SPF as "Authenticated Identifiers".  To be used by DMARC, an
   "Authenticated Identifier" must also be related to the domain found
   in the message's RFC5322.From header field [RFC5322].  This
   relationship between an Authenticated Identifier's domain and the
   domain of the RFC5322.From is referred to as "Identifier Alignment".

   DMARC allows for Identifier Alignment to be determined in two
   different modes: strict and relaxed.  Strict mode requires an exact
   match between the domain of any of the Authenticated Identifiers and
   the message's RFC5322.From header field [RFC5322].  Relaxed mode
   allows for Identifier Alignment if Authenticated Identifiers and the
   message's RFC5322.From header field [RFC5322] share the same
   Organizational Domain.  In general, DMARC interoperability issues are
   the same for both strict and relaxed alignment, but strict alignment
   constrains the possible solutions because of the more rigorous
   matching requirement.  Some of the mitigations described in this
   document only work with the relaxed mode of Identifier Alignment.

2.1.1.  DKIM Identifier(s)

   DKIM provides a cryptographic means for one or more domain
   identifiers to be associated with a particular message.  As a
   standalone technology, DKIM identifiers are not required to be
   related to the source of the message's content.  However, for a DKIM
   identifier to align in DMARC, the signing domain of a valid signature
   must be part of the same Organizational Domain as the domain in the
   RFC5322.From header field [RFC5322].

   In addition, DKIM allows for the possibility of multiple valid
   signatures.  These multiple signatures may be from the same or
   different domains; there are no restrictions within the DKIM
   specification.  The DMARC mechanism will process Authenticated
   Identifiers that are based on DKIM signatures until an aligned
   Authenticated Identifier is found (if any).  However, operational
   experience has shown that some implementations have difficulty
   processing multiple signatures.  Implementations that cannot process
   multiple DKIM signatures may incorrectly flag messages as "not
   passing" (DMARC alignment) and erroneously apply DMARC-based policy
   to otherwise conforming messages.

2.1.2.  SPF Identifier(s)

   The SPF specification [RFC7208] defines two Authenticated Identifiers
   for each message.  These identifiers derive from:

   a.  the RFC5321.MailFrom [RFC5321] domain, and

   b.  the RFC5321.HELO/.EHLO SMTP domain.

   In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
   defined to be based on RFC5321.MailFrom unless that value is absent
   (as in the case of notification messages), in which case, the second
   (RFC5321.HELO/.EHLO) identifier value is used.  This "fallback"
   definition has occasionally been misunderstood by operators of MTA
   systems since notification messages are often an "automatic" feature
   of MTA software.  Some MTA software does not provide the ability to
   apply a DKIM signature to such notification messages.

   See Appendix A for an example treatment of this scenario.

   For the purposes of DMARC validation/alignment, the hybrid
   RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if
   it is aligned with the RFC5322.From [RFC5322] domain.  The alignment
   of the validated domain is determined based on the DMARC record's
   "strict" or "relaxed" designation as described above for the DKIM
   identifiers and in [RFC7489].

2.1.3.  Multiple RFC5322.From Addresses

   [RFC5322] permits only one From header field, but it may contain
   multiple mailboxes.  Since this is an extremely rare usage, DMARC
   specifies that the handling of this situation is implementation
   dependent.

   Because the presence of multiple domains can be used by an attacker
   (an attacker could add their domain to the RFC5322.From field,
   provide arbitrary new content, and sign the message), the DMARC
   specification recommends that the strictest policy be applied to such
   messages (Section 6.6.1 of [RFC7489]).

2.2.  Message Forwarding

   Section 3 describes forwarding behavior as it relates to the
   components of the Internet Mail Architecture.

   All forwarding operations involve the retransmission of email.  As
   discussed above, in order for SPF to yield an Authenticated
   Identifier that is pertinent to DMARC, the domain of the
   RFC7208.MAILFROM must be in alignment with the RFC5322.From header
   field.  Forwarding introduces specific issues to the availability of
   SPF-based Authenticated Identifiers:

   o  If the RFC5321.MailFrom is present and the forwarder maintains the
      original RFC5321.MailFrom, SPF validation will fail unless the
      forwarder is an authorized part of the originator's email sending
      infrastructure.  If the forwarder replaces the RFC5321.MailFrom
      with its own domain, SPF might pass, but Identifier Alignment with
      the RFC5322.From header field will fail.

   o  If the RFC5321.MailFrom is empty (as in the case of Delivery
      Status Notifications), the RFC5321.HELO/.EHLO domain of the
      forwarder will likely be in a different Organizational Domain than
      the original RFC5322.From header field's domain.  SPF may pass,
      but Identifier Alignment with the RFC5322.From header field will
      fail.

   In both cases, SPF cannot yield relevant Authenticated Identifiers,
   and DKIM must be relied upon to produce results that are relevant to
   DMARC.

2.3.  Message Modification

   Modification of email content invalidates most DKIM signatures, and
   many message-forwarding systems modify email content.  Mailing List
   processors are a common example of such systems, but other forwarding
   systems also make modifications.

   Although DKIM provides a length flag so that content can be appended
   without invalidating the signature, in practice, particularly with
   MIME-encoded [RFC2045] messages, a Mailing List processor will do
   more than simply append content (see Section 5.3 of [RFC5598] for
   details).  Furthermore, the length flag is seldom used due to
   security issues (see Section 8.2 of [RFC6376] for additional security
   considerations).  Therefore, this method is only mentioned here for
   completeness.

   DKIM describes two canonicalizations for use when preparing the
   header and body for DKIM processing: simple and relaxed.  The latter
   is designed to accommodate trivial modifications to whitespace and
   folding that, at least in the header case, generally have no semantic
   significance.  However, the relaxed canonicalization is more
   computationally intensive and may not have been preferred in the
   early deployment of DKIM, leaving some deployments using the less
   forgiving "simple" canonicalization.  While the prevalence is
   unknown, there are some DKIM verifiers that have problems evaluating
   relaxed canonicalization correctly.

3.  Internet Mail Architecture, DMARC, and Indirect Email Flows

   This section describes components within the Internet Mail
   Architecture [RFC5598] where interoperability issues between DMARC
   and indirect email flows can be found.

3.1.  Message Handling System

   Section 4 of [RFC5598] describes six basic components that make up
   the Message Handling System (MHS):

   o  Message

   o  Message User Agent (MUA)

   o  Message Submission Agent (MSA)

   o  Message Transfer Agent (MTA)

   o  Message Delivery Agent (MDA)

   o  Message Store (MS)

   Of these components, MSA, MTA, and MDA are discussed in relation to
   interoperability with DMARC.

   Section 5 of [RFC5598] also defines a Mediator as a hybrid of several
   component types.  A Mediator is given special consideration in this
   section due to the unique issues they face when attempting to
   interoperate with DMARC.

3.1.1.  Message Submission Agents

   An MSA accepts messages submitted by a Message User Agent (MUA) and
   enforces the policies of the hosting ADministrative Management Domain
   (ADMD) and the requirements of Internet standards.

   MSAs are split into two sub-components:

   o  Author-focused MSA functions (aMSA)

   o  MHS-focused MSA functions (hMSA)

   MSA interoperability issues with DMARC begin when an aMSA accepts a
   message where the RFC5322.From header field contains a domain that is
   outside of the ADMD of the MSA.  This situation manifests in one of
   several ways, such as when someone uses a mail service with their own
   domain but has failed to properly configure an SPF record or when an
   MUA attempts to transmit mail as someone else.  Examples of the
   latter situation include "forward-to-friend" functionality commonly
   found on news/article websites or "send-as" functionality present on
   some MUAs.

   When an hMSA takes responsibility for transit of a message containing
   a domain in the RFC5322.From header field that is outside of the
   hMSA's ADMD, the hMSA faces DMARC interoperability issues if the
   domain publishes a DMARC policy of "quarantine" or "reject".  These
   issues are marked by the inherent difficulty of establishing
   alignment with the domain present in a message's RFC5322.From header
   field.  Examples of this issue include:

   o  Partially open relays - a residential ISP that allows its
      customers to relay non-local domains through its infrastructure.

   o  Embedded devices - cable/DSL modems, firewalls, wireless access
      points, and printers that send email using hardcoded domains.

   o  Devices that send mail on behalf of a user - scanners, security
      cameras, and alarms that send mail as their owner or a device
      user.

   o  Email service providers - ESPs that service customers who are
      using domains that publish a DMARC "reject" policy.

   o  Calendaring software - an invited member of an event modifies the
      event, causing the calendaring software to emit an update that
      claims to come from the creator of the event.

3.1.2.  Message Transfer Agents

   MTAs relay a message until the message reaches a destination MDA.
   Some common message-handling strategies break the integrity of DKIM
   signatures.  A restrictive DMARC policy along with a broken DKIM
   signature causes latent interoperability problems to become overt
   problems.

3.1.2.1.  Message Encoding

   An MTA may modify the message encoding, for instance, by converting
   8-bit MIME sections to quoted-printable 7-bit sections.  This
   modification is outside the scope of DKIM canonicalization and will
   invalidate DKIM signatures that include message content.

   An MTA could also re-encode the message without changing the encoding
   type: receiving a MIME-encoded message and producing a semantically
   and semiotically equivalent MIME body that is not identical to the
   original.  This is characteristic of systems that use some other
   message representation internally.

3.1.2.2.  Header Standardization

   An MTA may rewrite headers to bring them into compliance with
   existing RFCs.  For example, some common MTAs will correct
   comprehensible but non-compliant date formats to compliant ones.

   Header rewriting is outside the scope of DKIM canonicalization and
   will invalidate DKIM signatures.  All downstream DMARC processing
   with be unable to utilize DKIM to yield Authenticated Identifiers due
   to header rewriting.

   Providing solutions for issues relating to non-RFC-compliant emails
   is outside the scope of this document.

3.1.2.3.  Content Validation

   An MTA may also implement security-motivated changes to the content
   of email messages, dropping or altering sections of messages, causing
   breakage of DKIM signatures.

3.1.3.  Message Delivery Agents

   The MDA transfers a message from the MHS to a mailbox.  Like the MSA,
   the MDA consists of two sub-components:

   o  MHS-focused MDA functions (hMDA)

   o  Recipient-focused MDA functions (rMDA)

   Both the hMDA and the rMDA can redirect a message to an alternative
   address.  DMARC interoperability issues related to redirecting of
   messages are described in Section 3.2.

   Sieve [RFC5228] functionality often lives in the rMDA sub-component
   and can cause DMARC interoperability issues.  The Sieve 'addheader'
   and 'deleteheader' filtering actions can modify messages and
   invalidate DKIM signatures, removing DKIM-supplied Authenticated
   Identifiers as inputs to the DMARC mechanism.  There are also Sieve
   extensions [RFC5703] that modify the body.  Sieve alterations may
   only become an issue when the email is reintroduced into the
   transport infrastructure.

3.2.  Mediators

   Mediators [RFC5598] forward messages through a re-posting process.
   Mediators share some functionality with basic MTA relaying but have
   greater flexibility in both addressing and content modifications.

   DMARC interoperability issues are common within the context of
   Mediators, which are often used precisely for their ability to modify
   messages.

   The DMARC design does not cope with some Mediator functionality such
   as content modifications that invalidate DKIM signatures and
   RFC5321.MailFrom rewriting to support SPF authentication of re-sent
   mail when the new Recipient receives the message from the Mediator
   rather than the initial organization.

3.2.1.  Alias

   An Alias is a simple re-addressing facility that provides one or more
   new Internet Mail addresses, rather than a single, internal one.  A
   message continues through the transfer service for delivery to one or
   more alternative addresses.

   Aliases can be implemented by mailbox-level forwarding (e.g., through
   "dot-forwarding"), Sieve-level forwarding (through the Sieve
   "redirect" action), or other methods.  When an Alias preserves
   message content and does not make significant header changes, DKIM
   signatures may remain valid.  However, Aliases often extend the
   delivery path outside of the scope covered by the originating ADMD's
   SPF record(s).

   Examples of Aliasing include:

   o  Forwarding email between free email (freemail) providers to try
      different interfaces while maintaining an original email address;

   o  Consolidating many email addresses into a single account to
      centralize processing; and

   o  Services that provide "activity-based", "role-based", "vanity", or
      "temporary" email addresses such as universities and professional
      associations.  For instance, professional or alumni institutions
      may offer their members an Alias for the duration of their
      membership but may not want to deal with the long-term storage of
      emails.

   In most cases, the aMSA providing Alias services has no
   administrative relationship to the ADMD of the originator or the
   Final Recipient, so solutions to Alias-related DMARC failure should
   not assume such a relationship.

3.2.2.  ReSenders

   ReSenders "splice" a message's addressing information to connect the
   Author of the original message with the Recipient(s) of the new
   message.  The new Recipient sees the message as being from the
   original Author, even if the Mediator adds commentary.

   Without Authenticated Identifiers aligned with the Author's
   RFC5322.From header field domain, the new Recipient has no way to
   achieve a passing DMARC evaluation.

   Examples of ReSenders include MUA-level forwarding by resending a
   message to a new Recipient or by forwarding a message "inline" to a
   new Recipient (this does not include forwarding a message "as an
   attachment").  An additional example comes in the form of calendaring
   software that allows a meeting attendee (not the meeting organizer)
   to modify the content of an invite generating new invitations that
   claim to be reissued from the meeting organizer.

3.2.3.  Mailing Lists

   A Mailing List receives messages as an explicit addressee and then
   reposts them to a list of subscribed members.  The Mailing List
   performs a task that can be viewed as an elaboration of the ReSender
   actions.

   Mailing Lists share the same DMARC interoperability issues as
   ReSenders (Section 3.2.2) and very commonly modify headers or message
   content in ways that will cause DKIM to fail, including:

   o  prepending the RFC5322.Subject header field with a tag, to allow
      the Recipient to easily identify the Mailing List within a subject
      line listing;

   o  adding a footer to the email body to contain administrative
      instructions;

   o  removing some MIME-parts from the email or converting the message
      to text only;

   o  encrypting the body with the Recipient's key using PGP (Pretty
      Good Privacy) or S/MIME;

   o  enforcing community standards by rewriting banned words; and

   o  allowing moderators to add arbitrary commentary to messages
      (discussed in [RFC6377]).

   Any such modifications would invalidate a DKIM signature.

   Header and content modifications are common for many Mailing Lists
   and are often central to present Mailing List functionality and
   usage.  Furthermore, MUAs have come to rely on Mailing List message
   modifications to present messages to end users in expected ways.

3.2.3.1.  Mailing List Operational Effects

   Mailing Lists may also have the following DMARC interoperability
   issues:

   o  Subscribed members may not receive email from members that post
      using domains that publish a DMARC "p=reject" policy.

   o  Mailing Lists may interpret DMARC-related email rejections as an
      inability to deliver email to the Recipients that are checking and
      enforcing DMARC policy.  This processing may cause subscribers
      that are checking and enforcing DMARC policy to be inadvertently
      suspended or removed from the Mailing List.

3.2.4.  Gateways

   A Gateway performs the basic routing and transfer work of message
   relaying, but it is also permitted to modify content, structure,
   addressing, and/or other attributes as needed to send the message
   into a messaging environment that operates under different standards
   or potentially incompatible policies.

   Gateways share the same DMARC interoperability issues as ReSenders
   (Section 3.2.2).

   Gateways may also share the same DMARC interoperability issues as
   MTAs (Section 3.1.2).

   Receiver systems on the non-SMTP side of a protocol Gateway may be
   unable to evaluate DKIM and SPF.  If a message passes through a
   second protocol Gateway back into the SMTP domain, the
   transformations commonly break the original DKIM signature(s).

   Gateway-level forwarding can introduce DMARC interoperability issues
   if the Gateway is configured to rewrite the message into alternate
   receiving domains.  For example, an acquisition may lead an acquiring
   company to decide to decommission the acquired company's domains by
   rewriting messages to use the domain of the acquiring company.  Since
   the RFC5322.To header field is usually DKIM-signed, this kind of
   rewriting will invalidate such DKIM signatures.

3.2.5.  Boundary Filters

   To enforce security boundaries, organizations can subject messages to
   analysis for conformance with their safety policies.  A filter might
   alter the content to render it safe, such as by removing or otherwise
   altering content deemed unacceptable.

   Boundary Filters share the same DMARC interoperability issues as
   ReSenders.

   Issues may arise with SPF and DKIM evaluation if performed after
   filter modifications.

   Examples of Boundary Filters include:

   o  Malware scanning: To protect readers and its reputation, an MTA
      that transfers a message may remove content believed to be harmful
      from messages, reformulate content to canonical formats in order
      to make them more trustworthy or easier to scan, and/or add text
      in the body to indicate the message has been scanned.  Any such
      modifications would invalidate a DKIM signature.

   o  Spam filtering: To protect its reputation and assist other MTAs,
      an MTA may modify a message to indicate its decision that the
      message is likely to be unwanted and/or add text in the body to
      indicate that such filtering has been done.

   o  Other text additions: An MTA may add an organizational disclaimer
      or advertisement, for instance.

   o  URL alteration: Some systems will rewrite or alter embedded URLs
      as a way to control the potential threat from malware.

   o  Secondary MX services: The secondary MX for an organization may be
      external to the normal mail processing for the organization, and
      it may queue and forward to the primary when it becomes available.
      This will not invalidate DKIM but will prevent the primary from
      validating SPF normally.  In this case, however, it is
      inappropriate for a primary MX server to perform an SPF check
      against its own secondaries.  Rather, the secondary MX should
      perform this function and employ some trusted mechanism to
      communicate the results of the SPF, DKIM, and DMARC evaluation(s)
      to the primary MX server.

3.3.  Combinations

   Indirect email flows can be combined.  For example, a university
   student may subscribe to a Mailing List (using his university email
   address) while this university email address is configured to forward
   all emails to a freemail or a post-education corporate account
   provider where a more permanent email address for this student
   exists.

   Within an organization, the message may pass through various MTAs
   (Section 3.1.2), each of which performs a different function
   (authentication, filtering, distribution, etc.).

4.  Possible Mitigations of Interoperability Issues

   Solutions to interoperability issues between DMARC and indirect email
   flows vary widely in their scope and implications.  They range from
   improvements to underlying processing, such as proper handling of
   multiple DKIM signatures, to more radical changes to the messaging
   architecture.  This section describes possible ways to address
   interoperability issues.  Note that these particular mechanisms may
   not be considered "best practices" and may, in some cases, violate
   various conventions or expectations.

   Receivers sometimes need to deliver email messages that do not
   conform to any standard or protocol, but are otherwise desired by end
   users.  Mitigating the impact of DMARC on indirect email flows is
   especially important to receivers that operate services where ease of
   use and compatibility with existing email flows is a priority.

   DMARC provides a mechanism (local policy) for receivers to make
   decisions about identity alignment acceptability based on information
   outside DMARC and communicate those decisions as "overrides" to the
   sender.  This facility can be used to ease some interoperability
   issues, although care is needed to ensure that this does not create
   loopholes for abuse.

   To further complicate the usage of mitigations, mitigation may not be
   desired if the email in question is of a certain category of high
   value or high risk (security-related) transactional messages (dealing
   with financial transactions or medical records, for example).  In
   these cases, mitigating the impact of DMARC due to indirect email
   flows may not be desirable (counterproductive or allowing for abuse).

   As a final note, mail systems are diverse and widely deployed.
   Systems of various ages and capabilities are expected to preserve
   interoperability with the rest of the SMTP ecosystem.  For instance,
   Qmail is still used, although the base code has not been updated
   since 1998. ezmlm, a once popular MLM, is still deployed but has not
   been updated since 1997, although a new version (ezmlm-idx) exists.
   Old versions of other open- and closed-source MTAs are still commonly
   in operation.  When dealing with aging or unsupported systems, some
   solutions may be time-consuming and/or disruptive to implement.

4.1.  Mitigations in Current Use

   Because DMARC is already widely deployed, many operators already have
   mitigations in use.  These mitigations vary in their effectiveness
   and side effects but have the advantage that they are currently
   available.

4.1.1.  Mitigations for Senders

4.1.1.1.  Identifier Alignment

   o  MTAs handling multiple domains may choose to change
      RFC5321.MailFrom to align with RFC5322.From to improve SPF
      usability for DMARC.

   o  MTAs handling multiple domains may also choose to align
      RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending
      notification messages.  Dynamically adjusting the
      RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible
      for some MTA software.

   o  MTAs may choose to DKIM-sign notification messages with an aligned
      domain to allow a DKIM-based DMARC pass.

   o  MTAs sending email on behalf of multiple domains may require
      Domain Owners to provide DKIM keys to use DKIM to avoid SPF
      validation issues, given the requirement for DMARC alignment with
      the RFC5322.From header field.  Managing DKIM keys with a third
      party has security risks that should be carefully managed (see
      also [RFC6376], Section 8).  Methods involving CNAMEs and/or
      subdomains may alleviate some risks.

   o  Senders who are sending on behalf of users in other administrative
      domains may choose to use an RFC5322.From under the sender's
      control.  The new From can be either a forwarding address in a
      domain controlled by the Sender or a placeholder address, with the
      original user's address in an RFC5322.Reply-to header field.
      However, performing this modification may cause the Recipient's
      MUA to deviate from customary behavior.

   o  When implementing "forward-to-friend" functionality, one approach
      to avoid DMARC failures is to pass a well-formed message to the
      user's MUA so that it may fill in an appropriate identity and
      submit through its own MSA.

   o  Senders can use domains with distinct DMARC policies for email
      sent directly and email known to use indirect mail flows.
      However, for most well-known brands, all active domains are likely
      to be targeted equally by abusers.

4.1.1.2.  Message Modification

   o  Senders can maximize survivability of DKIM signatures by limiting
      the header fields they sign and using relaxed canonicalization.
      Using the DKIM length tag to allow appended signatures is
      discouraged due to the security risk created by allowing arbitrary
      content to be appended to legitimate email.

   o  Senders can also maximize survivability by starting with RFC-
      compliant headers and common body formats.

   o  In order to minimize transport-based conversions, Senders can
      convert messages to a lowest denominator MIME content-transfer
      encoding such as quoted-printable or base64 before signing
      ([RFC6376], Section 5.3).

4.1.2.  Mitigations for Receivers

4.1.2.1.  Identifier Alignment

   o  Receivers should update DKIM handling libraries to ensure that
      they process all valid DKIM signatures and check each signature
      for alignment.

4.1.2.2.  Policy Override

   o  Receivers can amalgamate data from their user base to create lists
      of forwarders and use such lists to inform DMARC local policy
      overrides.  This process may be easier for large receivers where
      data and resources to create such lists are more readily available
      than at smaller sites, where there are fewer accounts that receive
      forwarded mail and other resources may be scarce.

4.1.3.  Mitigations for ReSenders

4.1.3.1.  Changes to the RFC5322.From

   Many ReSender issues can be avoided by using an RFC5322.From header
   field under the ReSender's control, instead of the initial
   RFC5322.From.  This will correct Identifier Alignment issues and
   allow arbitrary message modification as long as the ReSender signs
   the message with an aligned domain signature.  When ReSenders change
   the RFC5322.From, it is desirable to preserve the information about
   the original initiator of the message.

   A first option is to use the Original-From [RFC5703] (or X-Original-
   From) header field for this purpose in various contexts (X- header
   field names are discouraged by [RFC6648]).  However, handling of
   Original-From (or X-Original-From) is not defined anywhere.  It is
   not currently used consistently or displayed to the user, and in any
   situation where it is used, it is a new unauthenticated identifier
   available for exploitation unless included within the scope of the
   new DKIM signature(s).

   Another option for ReSenders is to rewrite the RFC5322.From header
   field address to a locally controlled address that will be forwarded
   back to the original sender (subject to its own ReSender forwarding
   mitigations).

4.1.3.2.  Avoiding Message Modification

   o  Forwarders can choose to add email header fields instead of
      modifying existing headers or bodies, for instance, to indicate a
      message may be spam.

   o  Forwarders can minimize the circumstances in which they choose to
      fix messages, preferring to preserve non-compliant headers to
      creating DKIM failures.

   o  Forwarders can choose to reject messages with suspect or harmful
      content instead of modifying them.

4.1.3.3.  Mailing Lists

   [RFC6377] provides some guidance on using DKIM with Mailing lists.
   The following mitigation techniques can be used to ease
   interoperability issues with DMARC and Mailing lists:

   o  Configuring the Mailing List Manager (MLM) to alter the
      RFC5322.From header field to use the domain of the MLM is a
      mitigation policy that is now present in several different Mailing
      List software distributions.  Since most list subscribers prefer
      to know the identity of the Author of the original message,
      typically this information may be provided in the display name
      part of the RFC5322.From header field.  This display name needs to
      be carefully crafted so as to not collide with the original
      display name of the Author, nor contain something that looks like
      an email address or domain name.  These modifications may to some
      extent defeat the purpose of DMARC itself.  It may make it
      difficult to ensure that users of all email clients can easily
      reply to the Author, the list, or all using the email client
      features provided for that purpose.  Use of the RFC5322.Reply-To
      header field can alleviate this problem depending on whether the
      Mailing List is configured to reply-to-list, reply-to-author, or
      reply-to-fixed-address; however, it is important to note that this
      header field can take multiple email addresses.  When altering the
      RFC5322.From, there are three possibilities:

      1.  change it to put the Mailing List email address,

      2.  change it to a locally defined address that will be forwarded
          back to the original sender, or

      3.  "break" the address by modifying the domain to a non-existent
          domain (such as by adding a suffix like ".invalid").

      The latter modification may create issues because it is an invalid
      domain name, and some MTAs may pay particular attention to the
      validity of email addresses in RFC5322.From and the reputation of
      the domains present there.

   o  Configuring the MLM to "wrap" the message in a MIME message/rfc822
      part and to send as the Mailing List email address.  Many email
      clients (as of the publication of this document), especially
      mobile clients, have difficulty reading such messages, and this is
      not expected to change soon.

   o  Configuring the MLM to not modify the message so that the DKIM
      signature remains valid.  Some Mailing Lists are set up this way
      and require few additional changes to ensure the DKIM signature is
      preserved.  Moving lists that currently modify mail to a policy
      like this may be too much of a change for the members of such
      lists.

   o  Rejecting posts or membership requests from domains with a DMARC
      policy other than "p=none".  However, members or potential members
      of such Mailing Lists may complain of unfair exclusion.

   o  To alleviate unsubscribes to the Mailing List due to the messages
      bouncing because of DMARC, the MLM needs to not act on
      notification messages due to message authentication issues.
      [RFC3463] specifies Enhanced Mail System Status Codes, which help
      differentiate between various failure conditions.  Correctly
      interpreting Extended SMTP error messages is useful in this case.
      In particular, extended status codes for SPF and DKIM causes are
      defined in [RFC7372], and DMARC-related failure indications are
      discussed in DMARC ([RFC7489], Section 10.3).

   All these techniques may provide some specific challenges to MUAs and
   different operational usages for end users (like rewriting filters to
   sort emails in folders).  There will be some time before all
   implications are understood and accommodated.

4.2.  Proposed and In-Progress Mitigations

   The following mitigations are based on Internet-Drafts (I-Ds) that
   are still in process.  They are described here to offer an
   exploratory path for solutions.  These solutions should not be used
   in a production environment.  Because of the transient nature of
   I-Ds, specific citations are not included because a number of them
   will inevitably become obsolete, and those that gain consensus in the
   community will become RFCs and should be discovered as such.

   o  Third-party authorization schemes provide ways to extend
      Identifier Alignment under control of the Domain Owner.

   o  Ways to canonicalize messages that transit Mailing Lists so that
      their alterations can be isolated from the original signed
      content.

   o  Mechanisms to record message transformations applied at each hop
      so they can be reversed and the original signed content recovered.

   o  "Conditional" DKIM signatures, whereby the Author domain indicates
      its signature is only good if accompanied by a signature from an
      expected downstream relay.

   o  Mechanisms to extend Authentication-Results [RFC7601] to multiple
      hops, creating a provable chain of custody as well as a view of
      message authentication results at each handling step.

4.2.1.  Getting More Radical: Requiring New Communication Paths between
        MUAs

   In practice, a number of operators are using strict alignment mode in
   DMARC in order to avoid receiving new and innovative forms of
   unwanted and unauthentic email through systems purporting to be
   Mailing List handlers.  The receiving ADMD has no knowledge of which
   lists the user has subscribed to and which they have not.  One avenue
   of exploration would be for the user to authorize Mailing Lists as
   proxies for authentication, at which point the receiving ADMD would
   be vesting some trust in the Mailing List service.  The creators of
   DKIM foresaw precisely this possibility at the time by not tightly
   binding any semantics to the RFC5322.From header field.  Some
   experimental work has taken place in this area, as mentioned above.
   Additional work might examine a new communication path to the user to
   authorize some form of transitive trust.

5.  Security Considerations

   This document is an analysis of DMARC's impact on indirect email
   flows.  It describes the possibility of accidental denial of service
   that can be created by rejections of messages by DMARC-aware mail
   receivers.

   Section 4.1.1.1 discusses the importance of appropriate DKIM key
   management vis-a-vis third-party email senders.

   Section 4.1.3.3 warns that rewriting the RFC5322.From header field to
   create an artificial domain name should not be done with any domain.

6.  References

6.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <http://www.rfc-editor.org/info/rfc2045>.

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes",
              RFC 3463, DOI 10.17487/RFC3463, January 2003,
              <http://www.rfc-editor.org/info/rfc3463>.

   [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
              January 2008, <http://www.rfc-editor.org/info/rfc5228>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <http://www.rfc-editor.org/info/rfc5598>.

   [RFC5703]  Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
              Tests, Iteration, Extraction, Replacement, and Enclosure",
              RFC 5703, DOI 10.17487/RFC5703, October 2009,
              <http://www.rfc-editor.org/info/rfc5703>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <http://www.rfc-editor.org/info/rfc6376>.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
              September 2011, <http://www.rfc-editor.org/info/rfc6377>.

   [RFC6648]  Saint-Andre, P., Crocker, D., and M. Nottingham,
              "Deprecating the "X-" Prefix and Similar Constructs in
              Application Protocols", BCP 178, RFC 6648,
              DOI 10.17487/RFC6648, June 2012,
              <http://www.rfc-editor.org/info/rfc6648>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <http://www.rfc-editor.org/info/rfc7208>.

   [RFC7372]  Kucherawy, M., "Email Authentication Status Codes",
              RFC 7372, DOI 10.17487/RFC7372, September 2014,
              <http://www.rfc-editor.org/info/rfc7372>.

6.2.  Informative References

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <http://www.rfc-editor.org/info/rfc7489>.

   [RFC7601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7601,
              DOI 10.17487/RFC7601, August 2015,
              <http://www.rfc-editor.org/info/rfc7601>.

Appendix A.  Example SPF Bounce

   This example illustrates a notification message "bounce".

A.1.  Initial Message

   Here is the message as it exits the Origin MTA (segv.d1.example):

 Return-Path: <jqd@d1.example>
 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
     (authenticated bits=0)
     by segv.d1.example with ESMTP id t0FN4a8O084569;
     Thu, 14 Jan 2015 15:00:01 -0800 (PST)
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
     s=20130426; t=1421363082;
     bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
     h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
      Content-Transfer-Encoding;
     b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
      bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
      gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
 Message-ID: <54B84785.1060301@d1.example>
 Date: Thu, 14 Jan 2015 15:00:01 -0800
 From: John Q Doe <jqd@d1.example>
 To: no-recipient@dmarc.org
 Subject: Example 1

 Hey gang,
 This is a test message.
 --J.

A.2.  Notification Message

   When dmarc.org rejects the message without a DKIM signature, it
   specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has
   no SPF record. dmarc.org has a reject policy in place for such non-
   passing cases.  Since there is no DKIM signature on the notification
   message, the failed SPF lookup results in a dmarc=fail, and
   d1.example could be expected to discard the notification message
   itself:

 Return-Path: <>
 Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
    by mx.d1.example with ESMTPS id Lkm25302jJR5
    for <jqd@d1.example>
    (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Thu, 14 Jan 2015 15:00:24 -0800 (PST)
 Authentication-Results: mx.d1.example;
    spf=none (d1.example: dmarc.org.local does not designate
    permitted sender hosts) smtp.mail=;
    dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
 MIME-Version: 1.0
 Received: from segv.d1.example (segv.d1.example [198.51.100.1])
  by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
  14 Jan 2015 15:00:24 -0800 (PST)
 From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
 To: jqd@d1.example
 Subject: Delivery Status Notification (Failure)
 Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
 Date: Thu, 14 Jan 2016 23:00:24 +0000
 Content-Type: text/plain; charset=UTF-8

 This is an automatically generated Delivery Status Notification

 Delivery to the following recipient failed permanently:

      no-recipient@dmarc.org

 Technical details of permanent failure:
 Your message was rejected by the server for the recipient domain
   dmarc.org by mail.dmarc.org [192.0.2.1].

 The error that the other server returned was:
 550 5.1.1 <no-recipient@dmarc.org>... User unknown

 ----- Original message -----
 Return-Path: <jqd@d1.example>
 Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
     [203.252.0.131]) (authenticated bits=0)
     by segv.d1.example with ESMTP id t0FN4a8O084569;
     Thu, 14 Jan 2015 15:00:01 -0800 (PST)
     (envelope-from jqd@d1.example)
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
     s=20130426; t=1421363082;
     bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
     h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
      Content-Transfer-Encoding;
     b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
      bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
      gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
 Message-ID: <54B84785.1060301@d1.example>
 Date: Thu, 14 Jan 2015 15:00:01 -0800
 From: John Q Doe <jqd@d1.example>
 To: no-recipient@dmarc.org
 Subject: Example 1

 Hey gang,
 This is a test message.
 --J.

Acknowledgments

   Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf
   E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF
   DMARC Working Group's wiki page listing all known interoperability
   issues with DMARC and indirect email flows.

   Tim Draegen created the first draft of this document from these
   contributions and by ham-fistedly mapping contributions into the
   language of [RFC5598].

Authors' Addresses

   Franck Martin (editor)
   LinkedIn
   Mountain View, CA
   United States of America

   Email: fmartin@linkedin.com


   Eliot Lear (editor)
   Cisco Systems GmbH
   Richtistrasse 7
   Wallisellen, ZH  CH-8304
   Switzerland

   Phone: +41 44 878 9200
   Email: lear@cisco.com


   Tim Draegen (editor)
   dmarcian, inc.
   PO Box 1007
   Brevard, NC  28712
   United States of America

   Email: tim@dmarcian.com


   Elizabeth Zwicky (editor)
   Yahoo
   Sunnyvale, CA
   United States of America

   Email: zwicky@yahoo-inc.com


   Kurt Andersen (editor)
   LinkedIn
   2029 Stierlin Court
   Mountain View, CA  94043
   United States of America

   Email: kandersen@linkedin.com