DMARC Working Group                                       F. Martin, Ed.
Internet-Draft                                                  LinkedIn
Intended status: Informational                              E. Lear, Ed.
Expires: August 2, September 21, 2015                           Cisco Systems GmbH
                                                         T. Draegen, Ed.
                                                        January 29,
                                                          E. Zwicky, Ed.
                                                          March 20, 2015

     Interoperability Issues Between DMARC and Indirect Email Flows


   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 originate from third party sources, are modified in transit,
   or are forwarded enroute to their final destination.  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

   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 August 2, September 21, 2015.

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
   ( 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
   2.  Causes of Interoperability Issues . . . . . . . . . . . . . .   3
     2.1.  Identifier Alignment  . . . . . . . . . . . . . . . . . .   4
     2.2.  Message Forwarding  . . . . . . . . . . . . . . . . . . .   4   5
     2.3.  Message Modification  . . . . . . . . . . . . . . . . . .   5
   3.  Internet Mail Architecture, DMARC, and Indirect Email Flows .   5
     3.1.  Message Handling System . . . . . . . . . . . . . . . . .   5
       3.1.1.  Message Submission Agents . . . . . . . . . . . . . .   5   6
       3.1.2.  Message Transfer Agents . . . . . . . . . . . . . . .   6   7  Message Encoding  . . . . . . . . . . . . . . . .   6   7  Anti-spam . . . . . . .  Header Standardization  . . . . . . . . . . . . .   7  Email Address Internationalization  . . . . . . .   7
       3.1.3.  Message Delivery Agents . . . . . . . . . . . . . . .   7   8
     3.2.  Mediators . . . . . . . . . . . . . . . . . . . . . . . .   7   8
       3.2.1.  Alias . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.2.  ReSenders . . . . . . . . . . . . . . . . . . . . . .   8   9
       3.2.3.  Mailing Lists . . . . . . . . . . . . . . . . . . . .   9  10
       3.2.4.  Gateways  . . . . . . . . . . . . . . . . . . . . . .   9  10
       3.2.5.  Boundary Filters  . . . . . . . . . . . . . . . . . .  10  11
     3.3.  Combinations  . . . . . . . . . . . . . . . . . . . . . .  10  11
   4.  Possible Solutions to Interoperability Issues . . . . . . . .  10  12
     4.1.  Identifier Alignment  . . . . . . . . . . . . . . . . . .  11  12
     4.2.  Message Modification  . . . . . . . . . . . . . . . . . .  11  13
     4.3.  Message Forwarding  . . . . . . . . . . . . . . . . . . .  11  14
       4.3.1.  Original-Authentication-Results . . . . . . . . . . .  12  14
     4.4.  Message Handling Services . . . . . . . . . . . . . . . .  12  14
       4.4.1.  Message Transfer Agents . . . . . . . . . . . . . . .  12  14  Encoding  . . . . . . . . . . . . . . . . . . . .  12  14  Filters . . . . . . . . . . . . . . . . . . . . .  12  14  Email Address Internationalization  . . . . . . .  12  15
     4.5.  Mediators . . . . . . . . . . . . . . . . . . . . . . . .  12  15
       4.5.1.  Mailing Lists . . . . . . . . . . . . . . . . . . . .  12  15
     4.6.  Getting More Radical: Requiring New Communication Paths
           Between MUA and the Message Store . . . . . . . . . . . .  13  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14  16
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14  16
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15  18

1.  Introduction

   DMARC [I-D.kucherawy-dmarc-base] [RFC7489] introduces a mechanism for expressing domain-level
   policies and preferences for message validation, disposition, and
   reporting.  DMARC is used to combat exact-domain phishing, to gain
   visibility into email infrastructure, and to provide email egress
   controls.  Due to wide adoption, the impact of DMARC-based email
   rejection policies on both direct and indirect email flows can be

   The DMARC mechanism can encounter several different types of
   interoperability issues due to third-party message sourcing, message
   transformation or rerouting.
   This is  These cases in which mail does not go
   directly from the author's administrative domain to the recipients
   are known collectively as indirect email flows.  In some of these
   cases, message content is modified as a result.

   The next section describes interoperability issues between DMARC and
   indirect email flows.  These issues are first described in the
   context of configuration behavior that DMARC requires from underlying
   authentication technology, and then described as they appear in
   context of the Internet Mail Architecture [RFC5598].

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

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

   What do we mean by "interoperability issues"?  We say that DMARC
   introduces interoperability issues or problems, when conformance to
   the DMARC specification leads an implementation to reject a message
   that is both compliant with the architecture as specified in
   [RFC5598] and would have been viewed as legitimate in the eyes of the
   intended recipient.  This the secondary effects of behaviors caused
   by that rejection.  Therefore, we can already conclude that DMARC
   poses no interoperability problems when legitimate messages properly
   validate through its specified processes.  The rest of this section,
   therefore, section
   delves into how legitimate messages may get rejected.

2.1.  Identifier Alignment

   A fundamental aspect of message source validation is understanding
   what defines the originator of a message source that is validated.  Each of the underlying
   mechanisms that DMARC uses (DKIM [RFC6376] or and SPF [RFC7208]) takes a
   different approach.  Therefore, the DMARC [I-D.kucherawy-dmarc-base] [RFC7489] mechanism
   attempts to predictably specify the domain of the originator that
   will be used for its purposes (reporting/message disposition).  This
   step is referred to as Identifier Alignment.

   DKIM provides a cryptographic means for a domain to be associated
   with a particular message.  However, the signing domain is  DKIM does not
   required to be related to the domain contained in the 5322.From field
   [RFC5322].  The DMARC identifier alignment process posits just such make any constraints on
   what domains may or must present this association.  However, for a
   relationship.  For an
   DKIM identifier to align in DKIM, DMARC, the signing domain must be part of
   the same organizational domain Organizational Domain as the domain in the
   5322.From field, RFC5322.From
   header field [RFC5322], and the signature must be valid.

   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: if an implementation cannot process multiple DKIM signatures
   it may lead to perfectly valid messages being flagged as not

   SPF provides authenticated domain identifiers two Authenticated Identifiers the first one is
   RFC7208.HELO [RFC7208] based on RFC5321.HELO/EHLO and the second one
   is RFC7208.MAILFROM [RFC7208]  based on either the
   5321.MailFrom RFC5321.MailFrom
   [RFC5321] domain or, if the 5321.MailFrom RFC5321.MailFrom address is absent (as in
   the case of "bounces"), on the domain found in the HELO/
   command.  More  Local policies, as well as DMARC often than not operators have not put only use the
   RFC7208.MAILFROM identifier.  Again, for an SPF identifier to align
   in DMARC, the validated domain must be part of the same
   Organizational Domain as the domain in the RFC5322.From header field.
   Even when an SPF record on domains found exists for the domain in RFC5322.From, SPF
   will not authenticate it unless it is also the HELO/EHLO SMTP command domain SPF checks.
   While aligning RFC5322.From and when
   present, RFC5321.MailFrom is usually possible,
   it could can be difficult to change this domain to the domain in the 5322.From, especially HELO/EHLO used for
   bounces to the domain in the RFC5322.From header field, especially
   when several mail streams share the same sending IP address.

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 of these behaviors involve mail being retransmitted by a message has been transmitted through new SMTP
   server.  As discussed above, for SPF to cause a forwarder, there will
   be no such relationship.  With SPF, DMARC pass, the
   domain of the 5321.MailFrom RFC5321.MailFrom or 5321.HELO/EHLO RFC5321.HELO/EHLO must match be aligned
   with that of the 5322.From.  Because
   forwarders generally do not modify RFC5322.From header field.  If the 5322.From, this test forwarder keeps
   the RFC5321.MailFrom, the SPF validation will
   fail.  Thus fail altogether unless
   the forwarder is an authorized part of the originator's mail sending
   infrastructure.  If the forwarder uses its own domain in the
   RFC5321.MailFrom and/or RFC5321.HELO/EHLO, SPF passes but the
   alignment with the RFC5322.From header field fails.  In either case,
   SPF cannot produce a DMARC implementation must rely on DKIM, if available,
   in these cases. pass, and DKIM will be required to get
   DMARC to pass.

2.3.  Message Modification

   Modification of email content invalidates most DKIM signatures.
   While  For
   instance while DKIM provides a length flag so that content can be
   appended (See Section 8.2 of RFC6376 [RFC6376] for additional discussion),
   security considerations), in practice, particularly with MIME-encoded
   [RFC2045] messages, a mailing list processor will do more than append
   (See Section 5.3 of [RFC5598] for details).  Even forwarding systems
   make content modifications.  Furthermore, the use of the length flag
   is by no means universal.

   DKIM has two canonicalizations: simple and relaxed.  The latter
   allows some modest in transit modifications that do not change the
   interpretation of the content of the email.  The relaxed
   canonicalization used to be computing intensive and may not have been
   preferred in the early deployment of DKIM.

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 fulfill
   the purpose of 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 of MUA 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 5322.From 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 domain identifiers
   related to Authenticated Identifiers
   aligned with the domain found in the 5322.From header. 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 5322.From 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 inherent difficulty in modifying the domain
   present in a message's 5322.From header. RFC5322.From header field.  Examples of this
   issue include:

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

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

   o  Email service providers - ESPs that service customers that are
      using freemail services where the freemail service publishes domains that 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
      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.  Message Encoding

   An MTA may change the message encoding.  For encoding, for instance it may convert
   8bits by converting
   8-bit mail sections to quoted-printable 7bits sections, or just
   change 7-bit sections.  This is
   outside the character set from US-ASCII to ISO-8859-4.  Such
   transformations scope of DKIM canonicalization and will invalidate any present DKIM signature.
   signatures that include message content.  Anti-spam

   To keep its reputation, an  Header Standardization

   An MTA that transfers message, may block or
   otherwise remove harmful content from messages that are likely standardize headers, usually in order to be
   unwanted by make non-RFC
   compliant headers properly compliant.  For instance, some common MTAs
   will correct comprehensible but non-compliant date formats to
   compliant ones.  Again, this is outside the next MTA.  Any such modifications would scope of DKIM
   canonicalization and will invalidate a DKIM signature. signatures.  Email Address Internationalization

   A DMARC interoperability issue arises in the context of Email Address
   Internationalization [RFC6530].  [RFC6854] allows group syntax in the
   RFC5322.From header field during the transition period to SMTPUTF8.  In the
   case where
   If an EAI/SMTPUTF8-aware MTA relays needs to transmit a message to a non-aware non-
   aware MTA, the EAI/SMTPUTF8-aware MTA system may transform the 5322.From
   RFC5322.From header field of the message to include group syntax that allows to
   allow the non-aware MTA to
   process receive the email.

   This transformation modifies will modify the original content of the message
   and will
   invalide may invalidate any DKIM signatures and possibly if the transformation is not
   done by the MSA or MUA.  In addition, group syntax will remove the
   ability for the DMARC mechanism to receive find an Organizational Domain that
   aligns with any authenticated domain identifier from a
   DKIM module. SPF or DKIM.

   In addition, the group syntax will result in an invalid domain in the
   RFC5322.From header field.  If the receiving MTA pays attention to
   the validity and reputation of domains, this may present its own set
   of delivery problems.

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
   domain identifiers DKIM-supplied Authenticated
   Identifiers as inputs to the DMARC mechanism.  There are also SIEVE
   extensions that modify the body.  SIEVE may become an issue when the
   email is reintroduced in the transport infrastructure.

3.2.  Mediators


   See [RFC5598] for a complete definition of Mediators are largely imported from [RFC5598]. 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 within the context of
   Mediators, as Mediators represent a class of transformations that
   mirror the concept of "indirect email flows". which are often used precisely for their ability to modify

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 alternate alternative addresses.

   Aliases can be implemented by mailbox-level forwarding (e.g. through
   "dot-forwarding") or SIEVE-level forwarding (through the SIEVE
   'redirect' action). action) or other methods.  When an Alias preserves message content,
   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.

   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 to
      centralize processing.

   o  Services that provides "activity based", "role based" , "vanity"
      or "temporary" email addresses such as universities and
      professional associations.

   A fundamental challenge in dealing  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 workarounds involving Aliases
   is that in many instances, the long term
      storage of emails.

   In most cases, the aMSA providing Alias services has no
   administrative relationship to the ADMD of the alias.  Another challenge is that the
   underlying mechanisms upon which final recipient, so
   solutions to Alias-related DMARC relies do failure should not consider the
   local-part of the addr-spec.  While normally considered a perfectly
   reasonable scaling feature, the underlying assumption is that Authors
   will make use of aMSAs that are always authorized for assume such a given domain.
   For vanity domains, this assumption turns out to not hold.

3.2.2.  ReSenders

   ReSenders "splice" a message's addressing information to connect the
   Author of the original message with the Recipient 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 alignement alignment is removed as the new Recipient receives
   the message from the Mediator.

   Without an ability to produce authenticated domain identifiers Authenticated Identifiers relevant to
   the Author's 5322.From RFC5322.From header field domain using either DKIM or
   SPF, the new Recipient has almost no chance of successfully applying
   the DMARC mechanism.

   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 calendering calendaring
   software that allows a meeting attendee (not the meeting organizer)
   to modify the content of an invite causing the invitations to appear
   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 them to a list of subscribed members.  The Mailing List
   performs a task that can be viewed as an elaboration of the ReSender.

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

   o  Subscribed  prepending the RFC5322.Subject header field with a tag, to allow
      the receiver to identify visually the mailing list.

   o  adding a footer to the email body to contain administrative

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

   o  PGP-encrypting the body to 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.

   Mailing Lists may also have the following DMARC interoperability

   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 as an
      inability to deliver email to the recipients that are checking and
      enforcing DMARC policy.  This processing may cause subscribed
      members to be suspended or removed from the Mailing List.
      [RFC3463] specifies Enhanced Mail System Status Codes which help
      differentiate between various bounces.  DMARC even defines
      specific codes to be used.

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 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 interopreability interoperability issues as
   MTAs (Section 3.1.2).

   Gateway-level forwarding can introduce DMARC interoperability issues
   if the Gateway is configured to rewrite the message to map between
   recipient domains.  For example, an acquisition may lead the
   acquiring company to decide to decommission the acquired companies
   domains by rewriting messages to use the domain of the acquiring
   company.  Since the To: header is usually DKIM-signed, this kind of
   rewriting will also cause DKIM signatures to fail.

3.2.5.  Boundary Filters

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

   Boundary Filters share the same DMARC interoperability issues as

   Examples of Boundary Filters include:

   o  Antispam services  Anti-spam: To keep its reputation, an MTA that transfers a message
      may remove or modify content. harmful content from messages that are likely to be
      unwanted by the next MTA 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 that reformulates the 5322.body RFC5322.body for any other reason.
      reason, for instance adding an organizational disclaimer.

   o  Secondary MX services.  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

3.3.  Combinations

   The causes of 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 provider where a more
   permanent email address for this student exists.

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

4.  Possible Solutions to Interoperability Issues

   Solutions to interoperability issues between DMARC and indirect email
   flows vary widely in their scope and implications.  They range from improving of
   improvements to underlying processors, such as proper handling
   multiple DKIM signatures, to more radical approaches to the messaging
   architecture.  This section decribes describes possible ways to address
   interoperability issues.

   Through external knowledge it

   Mail systems are diverse and widely deployed and are expected to
   continue to work with old systems.  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 exists.  In
   this constrained environment, some solutions may be possible time-consuming
   and/or disruptive to determinine that the implement.

   DMARC mechanism cannot be applied provides for receivers to a particular message because
   modification and/or forwarding is make decisions about identity
   alignment acceptability based on information outside the DMARC
   headers and communicate those decisions as "overrides" to be expected through the normal
   course of operations for a given sender.
   This facility can be used to ease some interoperability issues,
   although care is known as an
   "override". needed to ensure that this does not create loopholes
   that abusers can use arbitrarily.

4.1.  Identifier Alignment

   In the case of forwarders, identity

   Currently used work-arounds and fixes to identifier alignment poses a substantial
   concern.  A receiving ADMD issues:

   o  MTAs handling multiple domains may track subscriptions choose to mailing lists,
   so that different processing change
      RFC5321.MailFrom to align with RFC5322.From to improve SPF
      usability for DMARC.

   o  MTAs handling multiple domains may be applied also choose to those align HELO/EHLO
      to RFC5322.From, particularly when sending bounce messages.

   Various proposals have been submitted

   o  MTAs may choose to provide either some form of
   transitive trust between an email sender, a realy and an email
   receiver, or DKIM sign bounces to allow a modified version of DKIM-based DMARC

   o  MTAs handling multiple domains may require DMARC-using senders to
      provide DKIM keys and use DKIM to survive light
   transformation avoid SPF alignment issues.

   o  ReSenders may choose to change RFC5322.From to one under the
      ReSender's control, avoiding alignment issues with the message: original.

   o  Receivers should update DKIM conditional signatures, [I-D.levine-dkim-conditional] handling libraries to ensure that
      they process all valid DKIM signatures and check them for

   Proposed and in-progress work-arounds and fixes to identifier
   alignment issues:

   o  Third party authorization, [RFC6541], [I-D.otis-tpa-label] and

   o  DKIM with light transformations, [I-D.kucherawy-dkim-list-canon] provide ways to extend identifier
      alignment under the control of the domain owner.

4.2.  Message Modification

   Message modification invalidates DKIM signatures and complicates a
   receiver's ability to generate authenticated domain identifiers Authenticated Identifiers from a
   message.  It  Avoiding message modification wherever possible is
   therefore important to review the MTAs
   (Section 3.1.2) configuration desirable.

   Currently used work-arounds and fixes to ensure no message modification issues:

   o  Senders can maximize survivability of DKIM signatures by limiting
   message is done when simply forwarding the message.  Furthermore
   Filters should not add header fields they sign, using relaxed canonicalization and by
      using length to or modify the allow appended signatures.

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

   o  Forwarders can choose to add email headers instead of the message, but
   either rejecting the message modifying
      existing headers or adding email bodies.

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

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

   o  If message modification is required, the filter. RFC5322.From may be

   Proposed and in-progress work-arounds and fixes to message
   modification issues:

   o  DKIM with constrained transformations,

4.3.  Message Forwarding

   Forwarding messages without modification is referred to as
   "transparent forwarding", and is a way to preserve the validity of
   DKIM signatures.

   Currently used work-arounds and fixes to message forwarding issues:

   o  Senders should use DKIM signing to allow transparent forwarding to

   o  ReSenders may choose to change RFC5322.From to one under the
      ReSender's control, avoiding alignment issues with the original.

   The X-Original-From Original-From [RFC5703] (or X-Original-From) header is used in
   various contexts. contexts (X- header fields name are discouraged by

   Note that Original-From (or X-Original-From) is merely adding
   complexity to the 'who was the author of this message' assessment,
   very possibly creating yet-
   another yet-another security hole.

4.3.1.  Original-Authentication-Results


   [I-D.kucherawy-original-authres] has been mentioned in early DMARC
   drafts [I-D.kucherawy-original-authres] as a way to pass along Original Authentication Results to
   "downstream" receivers.

4.4.  Message Handling Services

4.4.1.  Message Transfer Agents  Encoding

   There is very little reason are few reasons to modify the encoding of the message,
   compatibility issues between international character sets are few
   nowadays.  No  More mail systems supports 8bitMIME, therefore the need
   for transport encoding changes are rarer.  By default no modification
   of the message should be done when simply forwarding the message.  Filters

   Filters should not add to or modify the body of the message, but
   either should reject the message or add new email headers (not under
   DKIM) to indicate the result of the filter.  Email Address Internationalization

   The postmaster

   During the transition from email systems that do not allow EAI
   (SMTPUTF8) to email system that allows it, [RFC6854] allows using the
   group syntax for the RFC5322.From header field rather than rejecting
   the message (if RFC5322 is implemented strictly).  Allowing the group
   syntax is at the appreciation of the postmaster, that will always
   choose the solution best for its users user, but really to avoid DMARC not
   finding a single useable domain in the 5322.From, RFC5322.From header field, the
   real solution is to upgrade your MTAs, if you want to do DMARC, to support EAI (SMTPUTF8) so (SMTPUTF8).  In
   that case a sending SMTPUTF8 MTA does not need to require a downgrade
   of the group syntax message to ASCII identifiers.  Encouraging, by rejection or
   reputation scoring, the presence of a domain in the 5322.From RFC5322.From
   header field is not needed for interoperability issues during transition, and such
   syntax be considered at least as suspicious when present. easier.

4.5.  Mediators

4.5.1.  Mailing Lists

   [RFC6377] provides some guidance on using DKIM with Mailing lists.
   Here are some other remediations techniques:

   o  One common mitigation policy is to configure the Mailing List
      Manager (MLM) to alter the RFC5322.From header field to use the
      domain of the MLM.  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 modification may to some extent
      defeats the purpose of DMARC itself.  It may make it difficult to
      ensure that users of all email clients can easily reply to author,
      list, or all using the email client features provided for that
      purpose.  Use of "Reply-
      To" "Reply-To" can alleviate this problem depending
      if the mailing list is configured to reply-to-list, reply-to-author reply-to-
      author or reply-to-fixed-
      address. reply-to-fixed-address.

   o  Another common mitigation policy is to configure the MLM to "wrap"
      the message in a MIME message/rfc822 part.  This completely
      bypasses the DMARC policy in clients that allow reading the part
      as a message.  Many email clients (as of August 2014) have
      difficulty reading such messages.

   o  Finally a less common mitigation policy, is to configure the MLM
      to not modify the message so that the DKIM signature remains

   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.  Correctly interpreting Extended
      SMTP error messages is useful in this case. case ([RFC7372]).

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

4.6.  Getting More Radical: Requiring New Communication Paths Between
      MUA and the Message Store

   In practice a number of operators are using strict alignement mode in
   DMARC in order to avoid receiving new and innovative forms of
   unwanted and unauthentic mail 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 5322.From. 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 third party signatures.

5.  IANA Considerations

   No IANA considerations.

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

6.  Security Considerations

   No 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

7.  Acknowledgments

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

   Tim Draegen created the first draft of this document from these
   contributions and by carefully 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.

   [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

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

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, February 2012.

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

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

   [RFC6854]  Leiba, B., "Update to Internet Message Format to Allow
              Group Syntax in the "From:" and "Sender:" Header Fields",
              RFC 6854, March 2013.

   [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

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

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

              Kucherawy, M. and E. Zwicky, "Domain-based Message
              Authentication, Reporting and Conformance (DMARC)", draft-
              kucherawy-dmarc-base-11 (work in progress), January 2015.

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

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

              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)
   Mountain View, CA

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

   Phone: +41 44 878 9200

   Tim Draegen (editor)


   Elizabeth Zwicky (editor)
   Sunnyvale, CA