DMARC Working Group                                                     F. Martin, Ed.
Internet-Draft                                                  LinkedIn
Intended status: Informational                              E. Lear, Ed.
Expires: December 11, 2015 February 18, 2016                            Cisco Systems GmbH
                                                         T. Draegen, Ed.
                                              Eudaemonic Development LLC
                                                          dmarcian, inc.
                                                          E. Zwicky, Ed.
                                                                   Yahoo
                                                            June 9,
                                                        K. Andersen, Ed.
                                                                LinkedIn
                                                         August 17, 2015

     Interoperability Issues Between DMARC and Indirect Email Flows
                  draft-ietf-dmarc-interoperability-04
                  draft-ietf-dmarc-interoperability-05

Abstract

   DMARC introduces a mechanism for expressing domain-level policies and
   preferences for email message validation, disposition, and reporting.
   The DMARC mechanism can encounter 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 interoperability
   issues between DMARC and indirect email flows.  Possible methods for
   addressing interoperability issues are presented.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 11, 2015. February 18, 2016.

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . .   3   4
   2.  Causes of Interoperability Issues . . . . . . . . . . . . . .   3
     2.1.  Originator vs Receiver Perspective  . . . . . . . . . . .   4
     2.2.
     2.1.  Identifier Alignment  . . . . . . . . . . . . . . . . . .   4
     2.3.
     2.2.  Message Forwarding  . . . . . . . . . . . . . . . . . . .   5
     2.4.
     2.3.  Message Modification  . . . . . . . . . . . . . . . . . .   5   6
   3.  Internet Mail Architecture, DMARC, and Indirect Email Flows .   6
     3.1.  Message Handling System . . . . . . . . . . . . . . . . .   6   7
       3.1.1.  Message Submission Agents . . . . . . . . . . . . . .   6   7
       3.1.2.  Message Transfer Agents . . . . . . . . . . . . . . .   7   8
         3.1.2.1.  Message Encoding  . . . . . . . . . . . . . . . .   7   8
         3.1.2.2.  Header Standardization  . . . . . . . . . . . . .   8
         3.1.2.3.  Content Validation  . . . . . . . . . . . . . . .   9
       3.1.3.  Message Delivery Agents . . . . . . . . . . . . . . .   8   9
     3.2.  Mediators . . . . . . . . . . . . . . . . . . . . . . . .   8   9
       3.2.1.  Alias . . . . . . . . . . . . . . . . . . . . . . . .   8   9
       3.2.2.  ReSenders . . . . . . . . . . . . . . . . . . . . . .   9  10
       3.2.3.  Mailing Lists . . . . . . . . . . . . . . . . . . . .  10  11
         3.2.3.1.  Mailing List Operational Effects  . . . . . . . .  11
       3.2.4.  Gateways  . . . . . . . . . . . . . . . . . . . . . .  11  12
       3.2.5.  Boundary Filters  . . . . . . . . . . . . . . . . . .  11  12
     3.3.  Combinations  . . . . . . . . . . . . . . . . . . . . . .  12  13
   4.  Possible Mitigations of Interoperability Issues . . . . . . .  12  13
     4.1.  Mitigations in Current Use  . . . . . . . . . . . . . . .  13  14
       4.1.1.  Mitigations for Senders . . . . . . . . . . . . . . .  13  14
         4.1.1.1.  Identifier Alignment  . . . . . . . . . . . . . .  13  15
         4.1.1.2.  Message Modification  . . . . . . . . . . . . . .  13  15
       4.1.2.  Mitigations for Receivers . . . . . . . . . . . . . .  14  16
         4.1.2.1.  Identifier Alignment  . . . . . . . . . . . . . .  14  16
         4.1.2.2.  Policy Override . . . . . . . . . . . . . . . . .  14  16
       4.1.3.  Mitigations for ReSenders . . . . . . . . . . . . . .  14  16
         4.1.3.1.  Changes to the RFC5322.From . . . . . . . . . . .  14  16
         4.1.3.2.  Avoiding Message Modification . . . . . . . . . .  14  16
         4.1.3.3.  Mailing Lists . . . . . . . . . . . . . . . . . .  15  17
     4.2.  Proposed and In-Progress Mitigations  . . . . . . . . . .  16  18
       4.2.1.  Getting More Radical: Requiring New Communication
               Paths Between MUAs  . . . . . . . . . . . . . . . . .  17  19
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17  19
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17  19
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17  20
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18  20
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18  20
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  19  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  22

1.  Introduction

   DMARC [RFC7489] introduces a mechanism for expressing domain-level
   policies and preferences for message validation, disposition, and
   reporting.  The DMARC mechanism can encounter several different types
   of interoperability issues due to third-party message sourcing,
   message transformation or rerouting.

   At the time of the writing of this document, the DMARC is, base
   specification is published as this writing, an Informational RFC, however it RFC and has a seen
   significant deployment within the email community.

   Cases in which email does not flow directly from the author's
   administrative domain to the recipients 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 both direct and indirect email flows can be
   significant. 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.

   Lastly,

   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.
   Also, some practices which are in use at the time of this document
   may or may not be "best practices" as future standards evolve.

1.1.  Document Conventions

   Notation regarding structured fields is taken from [RFC5598].

   Organizational Domain and Authenticated Identifiers are specified in
   DMARC [RFC7489].

2.  Causes of Interoperability Issues

   Interoperability issues between DMARC and indirect email flows arise
   when conformance to the DMARC specification leads an 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.  To be clear, this document does

   Note that domains which assert a p=None policy and email which passes
   standard DMARC validation do not
   address emails have any interoperability issues.

   Email messages that do not conform to other email specifications but
   are considered legitimate by the intended recipient but
   which recipients are not conformant to other email specifications.
   discussed in this document.  The rest of this section describes
   several conceptual causes of interoperability issues.

2.1.  Originator vs Receiver Perspective

   Some Receivers are concerned that wanted email messages are received,
   regardless if such email messages are not strictly in conformance  Identifier Alignment

   DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to
   any standard or protocol.

   Some Originators, particularly for high value transactional messages,
   want the message discarded if it passes through an intermediary and
   is modified in any way resulting in a failure to validate.  Examples
   of such messages include those related to financial organizations and
   medical establishments.

2.2.  Identifier Alignment

   DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform perform message
   source validation.  The DMARC [RFC7489] mechanism refers to source
   domains that are validated by DKIM or SPF as Authenticated
   Identifiers.  DMARC requires an Authenticated Identifier to be
   relevant
   related to the domain found in the message's RFC5322.From header
   field [RFC5322].  This relevancy relationship is referred to as Identifier
   Alignment.

   DMARC allows for Identifier Alignment can to be strict, where the domains exactly achieved in two different
   modes: strict and relaxed.  Strict mode requires an exact match
   each others, or relaxed where the domains are part of
   either of the Authenticated Identifiers to 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.  There are, in  In general, the same
   interoperability issues between strict and relaxed alignment, however
   in modes are the
   same, with strict mode constraining the application of possible solutions are more constrained when
   possible.  This Document mainly implies
   solutions.  The mitigations described in this document generally
   require a relaxed mode of Identifier Alignment.

   DKIM provides a cryptographic means for a domain identifier to be
   associated with a particular message.  As a standalone technology
   DKIM does identifiers are not make any constraints on
   what domains may or must present this association. required to be relevant to the content of a
   message.  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.  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.  The impact on DMARC processing is
   clear: implementations that cannot process multiple DKIM signatures
   may incorrectly flag messages as "failing DMARC" and erroneously
   apply DMARC based policy to otherwise legitimate conforming messages.

   SPF can provide two Authenticated Identifiers based on two different
   SPF identities: Identifiers.  The first one is the
   RFC7208.HELO [RFC7208] and based on the RFC5321.HELO/EHLO.  The second
   one is the RFC7208.MAILFROM
   [RFC7208]. [RFC7208] based on the RFC5321.MailFrom
   [RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as
   in the case of "bounce" messages, on the domain found in the HELO/
   EHLO SMTP command.  DMARC uses only the SPF results for the
   RFC7208.MAILFROM identifier for
   alignment. alignment (this is often true for
   local policies outside of DMARC as well).  The SPF validated domain
   in RFC7208.MAILFROM must be part of the same Organizational Domain as
   the domain in the RFC5322.From header field to be aligned.  It is
   important to note that even when an SPF record exists for the domain
   in RFC5322.From, SPF will not authenticate it unless it is also the
   domain in RFC7208.MAILFROM,
   furthermore, which the SPF analysis has checked.  Also note that
   RFC7208.MAILFROM definition is different from RFC5321.MailFrom
   [RFC5321] definition.

2.3.  The RFC7208.MAILFROM definition has not
   changed from the RFC4408.MAILFROM [RFC4408] definition, the earlier
   version of the SPF specification, however, not all implementations
   have updated to the [RFC7208] algorithm which can lead to unexpected
   results.

2.2.  Message Forwarding

   Message forwarding is a generic concept encapsulating a variety of
   behaviors.  Section 3 describes forwarding behavior as it relates to
   the components of the Internet Mail Architecture.

   All forwarding behavior involves the retransmission of these behaviors involve email being retransmitted by a new
   SMTP server. email.  As
   discussed above, in order for SPF to cause a DMARC pass, yield an Authenticated
   Identifier that is pertinent to DMARC, the domain of the RFC7208.MAILFROM,
   RFC7208.MAILFROM must be aligned in alignment with that of the RFC5322.From header field:
   field.  Forwarding introduces specific issues to the availability of
   SPF-based Authenticated Identifiers:

   o  If the RFC5321.MailFrom is not empty present and if the forwarder keeps maintains the
      original RFC5321.MailFrom, the SPF validation will fail altogether unless the
      forwarder is an authorized part of the originator's email sending
      infrastructure.  On another hand, if  If the forwarder
      uses replaces the RFC5321.MailFrom
      with its own domain in the RFC5321.MailFrom, domain, SPF passes may pass but the
      alignment Identifier Alignment with
      the RFC5322.From header field fails. will fail.

   o  If the RFC5321.MailFrom is empty, empty (as in the case of Delivery
      Status Notifications), the RFC5321.Helo domain of the forwarder
      will likely be in different organizational domain of the
      RFC5322.From.
      RFC5322.From header field.  SPF may pass but the alignment Identifier Alignment
      with the RFC5322.From header field fails.

   In either case, both cases, SPF cannot produce a DMARC pass, yield relevant Authenticated Identifiers,
   and DKIM will must be
   required relied upon to get DMARC produce results that are relevant to pass.

2.4.
   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 the most 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 (See Section 8.2 of

   [RFC6376] for additional security considerations),
   without invalidating the signature, in practice, particularly with
   MIME-encoded [RFC2045] messages, a mailing list processor will do
   more than simply append (See content (see Section 5.3 of [RFC5598] for
   details).  Furthermore, the use of the length flag is seldom found in
   emails in part because used due to
   security issues (see Section 8.2 of its [RFC6376] for additional security challenges.
   considerations).

   DKIM has describes two canonicalizations to use for use when preparing headers
   and body
   separately: for DKIM processing: simple and relaxed.  The latter allows some modest in
   transit
   for trivial modifications (largely regarding whitespace folding) that do not change
   maintain the interpretation integrity of the content of the email.  The  However, the
   relaxed canonicalization is more computing 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 as this may checkers which
   have been more significant than today. 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.

   A Mediator is a special class hybrid of MUA several component types that is given
   special consideration in this section due to the unique issues
   Mediators 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.  The ADMD will almost certainly not
   be capable of sending email that yields Authenticated Identifiers
   aligned with the domain found in the RFC5322.From header field.
   Examples of this issue 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 an the inherent difficulty in of establishing
   alignment with the domain present in a message's RFC5322.From header
   field.  Examples of this issue include:

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

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

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

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

   o  Calendaring software - an invited member of an event modifies the
      event causing calendaring software to emit an update that appears 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.

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 may also re-encode the message without changing the encoding
   type, receiving a MIME-encoded message and producing a semantically
   and syntactically 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 standardize headers, usually in order rewrite headers to make non-RFC
   compliant bring headers properly compliant. into compliance with
   existing RFCs.  For instance, example, some common MTAs will correct
   comprehensible but non-compliant date formats to compliant ones.  This correction

   Header rewriting is outside the scope of DKIM canonicalization and
   will invalidate DKIM signatures.  This
   correction is also outside the scope of this document in providing
   solutions for non RFC compliant emails.  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 that modify the body.  SIEVE alterations may only become
   an issue when the email is reintroduced in into the transport
   infrastructure.

3.2.  Mediators

   See [RFC5598] for a complete definition of Mediators.

   Mediators 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 prevalent common within the context of
   Mediators, which are often used precisely for their ability to modify
   messages.

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") or 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
   beyond SPF's ability to grant authorization.
   outside of the scope covered by the originating ADMD's SPF record(s).

   Examples of Aliasing include:

   o  Forwarding email between freemail providers to try different
      interfaces while maintaining an original email address.

   o  Consolidating many email addresses into a single acccount account to
      centralize processing.

   o  Services that provides provide "activity based", "role based" , "vanity" or
      "temporary" email addresses such as universities and professional
      associations.  For instance professional or alumni institutions
      may offer to 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.

   ReSenders introduce DMARC interoperability issues as content
   modification invalidates DKIM signatures.  SPF's ability to grant
   authorization via alignment is removed as the new Recipient receives
   the message from the Mediator. Mediator rather than the initial organization.

   Without an ability to produce Authenticated Identifiers relevant to aligned with the Author's
   RFC5322.From header field domain using either DKIM or
   SPF, domain, the new Recipient has almost no chance of successfully applying
   the way to
   achieve a passing DMARC mechanism. 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 causing the generating new invitations to appear 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
   re-posts
   reposts them to a list of subscribed members.  The Mailing List
   performs a task that can be viewed as an elaboration of the ReSender. 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 receiver recipient to easily identify visually the mailing list. 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  PGP-encrypting or S/MIME encrypting the body to with the receiver's
      key.

   o  enforcing community standards by rewriting banned words.

   o  allowing moderators to add arbitrary commentary to messages.

   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 rejection rejections as an
      inability to deliver email to the recipients that are checking and
      enforcing DMARC policy.  This processing may cause subscribed
      members subscribers
      that are checking and enforcing DMARC policy to be inadvertently
      suspended or removed from the Mailing List.

   These changes are common for many mailing lists and receivers are
   used to them.  Furthermore MUA expects certain mailing list behavior
   in presenting emails to the end users

3.2.4.  Gateways

   A Gateway performs the basic routing and transfer work of message
   relaying, but it also is permitted to modify content, structure,
   address, or
   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 share also 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 to map between into alternate
   recipient domains.  For example, an acquisition may lead the 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 also cause invalidate such DKIM signatures to fail. 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 if with SPF and DKIM is evaluated evaluation if performed after the
   filter modifications.

   Examples of Boundary Filters include:

   o  Anti-spam:  Malware scanning: To keep protect readers and its reputation, an MTA
      that transfers a message may remove harmful content from messages that are likely believed to be
      unwanted by the next MTA and/or add text 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  Any service  Spam filtering: To protect reputation and assist other MTAs, an
      MTA may modify a message to indicate its decision that reformulates the RFC5322.body for any other
      reason, for instance adding 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. disclaimer
      or advertisement, for instance.

   o  Secondary MX services. services: The secondary MX for an organization may be
      external to the normal mail processing for the organization, and
      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. 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

   The causes of indirect

   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 processors, such as proper handling of
   multiple DKIM signatures, to more radical approaches changes to the messaging
   architecture.  This section describes possible ways to address
   interoperability issues.

   Mail  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 (counter-productive, or allowing for
   abuse).

   As a final note, mail systems are diverse and widely deployed deployed.
   Systems of various ages and capabilities are expected to
   continue to work preserve
   interoperability with old systems. the rest of the SMTP ecosystem.  For instance,
   Qmail is still used and the base code has not been updated since
   1998.  Ezmlm, a once popular mailing list manager, is still deployed
   and has not been updated since 1997, although a new version, Ezmlm-idx Ezmlm-
   idx exists.  In
   this constrained environment,  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.

   DMARC provides 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 that
   abusers can use arbitrarily.

4.1.  Mitigations in Current Use

   At many places where

   Because DMARC is already widely deployed, many operators already have
   mitigations are 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
      bounce messages.  Adjusting dynamically  Dynamically adjusting the RFC5321.HELO based on
      the RFC5322.From may not be possible for some MTA software.

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

   o  MTAs handling sending email on behalf of multiple domains may require DMARC-using senders
      Domain Owners to provide DKIM keys and to use DKIM to avoid SPF
      alignment issues.
      Handling  Managing DKIM keys with a third party has its
      security challenges. risks which should be carefully managed.

   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 a RFC5322.Reply-to header field.
      However
      However, performing this modification may affect what cause the recipient expects in its MUA. recipient's
      MUA to deviate from customary behavior.

   o  Senders can use different domains with different distinct DMARC policies for email
      sent directly and email known to use indirect mail flow.
      However flows.
      However, for 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, using relaxed canonicalization sign and by using relaxed canonicalization.
      Using the DKIM length tag to allow appended signatures. 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 the chances of transport transport-based conversions, Senders can
      convert the message messages to a suitable 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 them each signature
      for alignment.

4.1.2.2.  Policy Override

   o  Receivers can amalgamate data from their user base to identify create lists
      of forwarders and use such list for a lists to inform DMARC local policy override.
      overrides.  This process may be easier for large receivers, receivers where there is
      data and resources to create such lists, lists are more readily available
      than for small receivers. at smaller sites where the recipient footprint 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, for instance. 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
   fields name 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, but and in any
   situation where it is used, it is a new unauthenticated identifier
   available for exploitation. 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 valid forwarding locally controlled address which will be forwarded
   back to the original sender,
   in a domain that the sender (subject to its own ReSender controls. 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.
   Here are some remediation
   The following mitigation techniques on using DMARC can be used to ease
   interoperability issues with DMARC and Mailing lists:

   o  One mitigation policy, which is now present on several Mailing
      List software, is to configure  Configuring the Mailing List Manager (MLM) to alter the
      RFC5322.From header field to use the domain of the MLM. MLM is a
      mitigation policy which 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 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 RFC5322.Reply-To header field can
      alleviate this problem depending on whether the mailing list is
      configured to reply-to-list, reply-
      to-author reply-to-author or reply-to-fixed-address, 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 two possibilities, to three possibilities:

      1.  change it to put the mailing list email address, or to

      2.  change it to add a suffix like ".invalid" locally-defined address which will be forwarded
          back to the domain of original sender, or

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

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

   o  Another mitigation policy is to configure 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 August 2014) 2015),
      especially mobile clients, have difficulty reading such messages. messages
      and this is not expected to change soon.

   o  Another mitigation policy, is to configure the MLM to not modify
      the message so that the DKIM signature remains valid.  Some
      Mailing Lists are mainly setup set up this way and require little
      modifications few additional
      changes to ensure the DKIM signature is preserved.  However
      moving to this policy a list  Moving lists
      that do extensive modification currently modify mail to the
      email, a policy like this, may be too much
      of a change for the members of such list. lists.

   o  Another mitigation policy, is to reject 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 bounces due
      to Message Authentication issues.  [RFC3463] specifies Enhanced
      Mail System Status Codes which help differentiate between various
      bounces.  Correctly interpreting Extended SMTP error messages is
      useful in this case in particular case.  In particular, extended status codes are
      defined in [RFC7372] and in DMARC. DMARC [RFC7489].

   All these techniques may provide some specific challenges in 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 alleviated. adjusted to.

4.2.  Proposed and In-Progress Mitigations

   The following mitigations are based on Internet Drafts which have not
   yet received broad consensus.  They are described here to offer
   exploratory path for solutions.  These solutions should not be used
   in a production environment.

   o  Third party authorization, [RFC6541], [I-D.otis-tpa-label] and
      [I-D.kucherawy-dkim-delegate] provide ways to extend identifier
      alignment under the control of the domain owner.

   o  DKIM with constrained transformations,
      [I-D.kucherawy-dkim-list-canon] is proposed to allow message
      modification.

   o  DKIM with recorded transformations, [I-D.kucherawy-dkim-transform]
      is proposed to indicate what limited transformations were done to
      the message so that a receiver could reverse them and confirm the
      validity of the orignal DKIM signature.

   o  [I-D.kucherawy-original-authres] is intended as a way to pass
      along Original Authentication Results to "downstream" receivers.
      It is not widely implemented and relies on a trust relationship
      between the forwarder and the other receivers.

   o  [I-D.levine-dkim-conditional] could be used to have the sender add
      a limited DKIM signature, that signs only a very limited set of
      header fields and not the body of the message.  This DKIM
      signature would come with the condition that a subsequent known
      domain fully DKIM sign the message.  For instance a Mailing List
      could transform the message, add its DKIM signature and there
      would be a valid DKIM signature aligned with the RFC5322.From that
      would satisfy DMARC while limiting the possibilities of replay
      attack.

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.  IANA Considerations

   This document contains no actions for IANA.  [RFC Editor: Please
   delete this section prior to publication.]

6.  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.  However, it introduces no new security issues to Internet
   messaging.

7.  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 hamfistedly mapping contributions into the
   language of [RFC5598].

8.  References

8.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
              3463, January 2003.

   [RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
              for Authorizing Use of Domains in E-Mail, Version 1", RFC
              4408, April 2006.

   [RFC5228]  Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", RFC 5228, January 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
              2009.

   [RFC5703]  Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
              Tests, Iteration, Extraction, Replacement, and Enclosure",
              RFC 5703, October 2009.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
              September 2011.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", BCP 167, RFC 6377, September 2011.

   [RFC6541]  Kucherawy, M., "DomainKeys Identified Mail (DKIM)
              Authorized Third-Party Signatures", RFC 6541, February
              2012.

   [RFC6648]  Saint-Andre, P., Crocker, D., and M. Nottingham,
              "Deprecating the "X-" Prefix and Similar Constructs in
              Application Protocols", BCP 178, RFC 6648, June 2012.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              April 2014.

   [RFC7372]  Kucherawy, M., "Email Authentication Status Codes", RFC
              7372, September 2014.

8.2.  Informative References

   [I-D.kucherawy-dkim-delegate]
              Kucherawy, M. and D. Crocker, "Delegating DKIM Signing
              Authority", draft-kucherawy-dkim-delegate-01 (work in
              progress), June 2014.

   [I-D.kucherawy-dkim-list-canon]
              Kucherawy, M., "A List-safe Canonicalization for
              DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim-
              list-canon-00 (work in progress), June 2014.

   [I-D.kucherawy-dkim-transform]
              Kucherawy, M., "Recognized Transformations of Messages
              Bearing DomainKeys Identified Mail (DKIM) Signatures",
              draft-kucherawy-dkim-transform-00 (work in progress),
              April 2015.

   [I-D.kucherawy-original-authres]
              Chew, M. and M. Kucherawy, "Original-Authentication-
              Results Header Field", draft-kucherawy-original-authres-00
              (work in progress), February 2012.

   [I-D.levine-dkim-conditional]
              Levine, J., "DKIM Conditional Signatures", draft-levine-
              dkim-conditional-00 (work in progress), June 2014.

   [I-D.otis-tpa-label]
              Otis, D. and D. Black, "Third-Party Authorization Label",
              draft-otis-tpa-label-00 (work in progress), May 2014.

   [RFC7489]  Kucherawy, M. and E. Zwicky, "Domain-based Message
              Authentication, Reporting, and Conformance (DMARC)", RFC
              7489, March 2015.

Authors' Addresses

   Franck Martin (editor)
   LinkedIn
   Mountain View, CA
   USA

   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)
   Eudaemonic Development LLC
   dmarcian, inc.
   PO Box 19443
   Asheville, 1007
   Brevard, NC  28815  28712
   USA

   Email: tim@eudev.net tim@dmarcian.com

   Elizabeth Zwicky (editor)
   Yahoo
   Sunnyvale, CA
   USA

   Email: zwicky@yahoo-inc.com

   Kurt Andersen (editor)
   LinkedIn
   2029 Stierlin Court
   Mt. View, CA  94043
   USA

   Email: kandersen@linkedin.com