summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7960.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7960.txt')
-rw-r--r--doc/rfc/rfc7960.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7960.txt b/doc/rfc/rfc7960.txt
new file mode 100644
index 0000000..339eb2f
--- /dev/null
+++ b/doc/rfc/rfc7960.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) F. Martin, Ed.
+Request for Comments: 7960 LinkedIn
+Category: Informational E. Lear, Ed.
+ISSN: 2070-1721 Cisco Systems GmbH
+ T. Draegen, Ed.
+ dmarcian, inc.
+ E. Zwicky, Ed.
+ Yahoo
+ K. Andersen, Ed.
+ LinkedIn
+ September 2016
+
+
+ Interoperability Issues between Domain-based Message Authentication,
+ Reporting, and Conformance (DMARC) and Indirect Email Flows
+
+Abstract
+
+ Domain-based Message Authentication, Reporting, and Conformance
+ (DMARC) introduces a mechanism for expressing domain-level policies
+ and preferences for email message validation, disposition, and
+ reporting. However, the DMARC mechanism enables potentially
+ disruptive interoperability issues when messages do not flow directly
+ from the author's administrative domain to the final Recipients.
+ Collectively, these email flows are referred to as "indirect email
+ flows". This document describes these interoperability issues and
+ presents possible methods for addressing them.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7960.
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 1]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Document Conventions .......................................4
+ 2. Causes of Interoperability Issues ...............................4
+ 2.1. Identifier Alignment .......................................4
+ 2.1.1. DKIM Identifier(s) ..................................5
+ 2.1.2. SPF Identifier(s) ...................................6
+ 2.1.3. Multiple RFC5322.From Addresses .....................6
+ 2.2. Message Forwarding .........................................6
+ 2.3. Message Modification .......................................7
+ 3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
+ 3.1. Message Handling System ....................................8
+ 3.1.1. Message Submission Agents ...........................8
+ 3.1.2. Message Transfer Agents .............................9
+ 3.1.2.1. Message Encoding ...........................9
+ 3.1.2.2. Header Standardization ....................10
+ 3.1.2.3. Content Validation ........................10
+ 3.1.3. Message Delivery Agents ............................10
+ 3.2. Mediators .................................................11
+ 3.2.1. Alias ..............................................11
+ 3.2.2. ReSenders ..........................................12
+ 3.2.3. Mailing Lists ......................................12
+ 3.2.3.1. Mailing List Operational Effects ..........13
+ 3.2.4. Gateways ...........................................13
+ 3.2.5. Boundary Filters ...................................14
+ 3.3. Combinations ..............................................15
+ 4. Possible Mitigations of Interoperability Issues ................15
+ 4.1. Mitigations in Current Use ................................16
+ 4.1.1. Mitigations for Senders ............................16
+ 4.1.1.1. Identifier Alignment ......................16
+ 4.1.1.2. Message Modification ......................17
+ 4.1.2. Mitigations for Receivers ..........................17
+
+
+
+Martin, et al. Informational [Page 2]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ 4.1.2.1. Identifier Alignment ......................17
+ 4.1.2.2. Policy Override ...........................17
+ 4.1.3. Mitigations for ReSenders ..........................18
+ 4.1.3.1. Changes to the RFC5322.From ...............18
+ 4.1.3.2. Avoiding Message Modification .............18
+ 4.1.3.3. Mailing Lists .............................18
+ 4.2. Proposed and In-Progress Mitigations ......................20
+ 4.2.1. Getting More Radical: Requiring New
+ Communication Paths between MUAs ...................21
+ 5. Security Considerations ........................................21
+ 6. References .....................................................22
+ 6.1. Normative References ......................................22
+ 6.2. Informative References ....................................23
+ Appendix A. Example SPF Bounce ...................................24
+ A.1. Initial Message ...........................................24
+ A.2. Notification Message ......................................25
+ Acknowledgments ...................................................26
+ Authors' Addresses ................................................27
+
+1. Introduction
+
+ DMARC [RFC7489] introduces a mechanism for expressing domain-level
+ policies and preferences for message validation, disposition, and
+ reporting. The DMARC mechanism, especially when employed with
+ restrictive policies, encounters several different types of
+ interoperability issues due to third-party message sourcing, message
+ transformation, or rerouting. In particular, DMARC with restrictive
+ policies causes problems for many Mailing Lists.
+
+ At the time of writing this document, the DMARC base specification
+ has been published as Informational RFC 7489 [RFC7489] and has seen
+ significant deployment within the email community.
+
+ Cases in which email does not flow directly from the author's
+ administrative domain to the recipient's domain(s) are collectively
+ referred to in this document as "indirect email flows". Due to
+ existing and increasing adoption of DMARC, the impact of DMARC-based
+ email rejection policies on indirect email flows can be significant
+ for a select subset of general email traffic.
+
+ Several known causes of interoperability issues are presented,
+ followed by a description of components within the Internet Mail
+ Architecture [RFC5598] where interoperability issues can arise.
+
+ Finally, known and possible methods for addressing interoperability
+ issues are presented. There are often multiple ways to address any
+ given interoperability issue. While this document strives to be
+ comprehensive in its review, it should not be treated as complete.
+
+
+
+Martin, et al. Informational [Page 3]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ Note that some practices that are in use at the time of this document
+ may or may not be "best practices", especially as future standards
+ evolve.
+
+1.1. Document Conventions
+
+ The notation used in this document for structured fields is taken
+ from [RFC5598], Section 1.3.
+
+ The term "notification message" ([RFC5321], Section 4.5.5) is used to
+ refer to a message with a null RFC5321.MailFrom.
+
+ The terms "Organizational Domain" and "Authenticated Identifiers" are
+ specified in DMARC ([RFC7489], Section 3).
+
+ All words that begin with capital letters take their formal meanings
+ from these references.
+
+2. Causes of Interoperability Issues
+
+ Interoperability issues between DMARC and indirect email flows arise
+ when conformance to the DMARC specification leads a receiving
+ implementation to apply DMARC-based policy restrictions to messages
+ that are both compliant with the architecture as specified in
+ [RFC5598] and viewed as legitimate by the intended Recipient.
+
+ Note that domains that assert a "p=none" policy and email messages
+ that pass standard DMARC validation do not have any interoperability
+ issues.
+
+ Email messages that do not conform to IETF email specifications but
+ are considered legitimate by the intended Recipients are not
+ discussed in this document.
+
+ The rest of this section describes several conceptual causes of
+ interoperability issues.
+
+2.1. Identifier Alignment
+
+ Note to operators and administrators: The identifiers that are used
+ by the Sender Policy Framework (SPF) are technical components of the
+ transport process for SMTP. They may or may not, as described below,
+ bear a meaningful relationship to the content or source of the
+ message itself. This "relationship by proximity" can be a point of
+ confusion for non-technical end users, either recipients or senders.
+
+
+
+
+
+
+Martin, et al. Informational [Page 4]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF
+ [RFC7208] to perform message source validation. The DMARC [RFC7489]
+ specification refers to source domains that are validated by DKIM or
+ SPF as "Authenticated Identifiers". To be used by DMARC, an
+ "Authenticated Identifier" must also be related to the domain found
+ in the message's RFC5322.From header field [RFC5322]. This
+ relationship between an Authenticated Identifier's domain and the
+ domain of the RFC5322.From is referred to as "Identifier Alignment".
+
+ DMARC allows for Identifier Alignment to be determined in two
+ different modes: strict and relaxed. Strict mode requires an exact
+ match between the domain of any of the Authenticated Identifiers and
+ the message's RFC5322.From header field [RFC5322]. Relaxed mode
+ allows for Identifier Alignment if Authenticated Identifiers and the
+ message's RFC5322.From header field [RFC5322] share the same
+ Organizational Domain. In general, DMARC interoperability issues are
+ the same for both strict and relaxed alignment, but strict alignment
+ constrains the possible solutions because of the more rigorous
+ matching requirement. Some of the mitigations described in this
+ document only work with the relaxed mode of Identifier Alignment.
+
+2.1.1. DKIM Identifier(s)
+
+ DKIM provides a cryptographic means for one or more domain
+ identifiers to be associated with a particular message. As a
+ standalone technology, DKIM identifiers are not required to be
+ related to the source of the message's content. However, for a DKIM
+ identifier to align in DMARC, the signing domain of a valid signature
+ must be part of the same Organizational Domain as the domain in the
+ RFC5322.From header field [RFC5322].
+
+ In addition, DKIM allows for the possibility of multiple valid
+ signatures. These multiple signatures may be from the same or
+ different domains; there are no restrictions within the DKIM
+ specification. The DMARC mechanism will process Authenticated
+ Identifiers that are based on DKIM signatures until an aligned
+ Authenticated Identifier is found (if any). However, operational
+ experience has shown that some implementations have difficulty
+ processing multiple signatures. Implementations that cannot process
+ multiple DKIM signatures may incorrectly flag messages as "not
+ passing" (DMARC alignment) and erroneously apply DMARC-based policy
+ to otherwise conforming messages.
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 5]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+2.1.2. SPF Identifier(s)
+
+ The SPF specification [RFC7208] defines two Authenticated Identifiers
+ for each message. These identifiers derive from:
+
+ a. the RFC5321.MailFrom [RFC5321] domain, and
+
+ b. the RFC5321.HELO/.EHLO SMTP domain.
+
+ In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
+ defined to be based on RFC5321.MailFrom unless that value is absent
+ (as in the case of notification messages), in which case, the second
+ (RFC5321.HELO/.EHLO) identifier value is used. This "fallback"
+ definition has occasionally been misunderstood by operators of MTA
+ systems since notification messages are often an "automatic" feature
+ of MTA software. Some MTA software does not provide the ability to
+ apply a DKIM signature to such notification messages.
+
+ See Appendix A for an example treatment of this scenario.
+
+ For the purposes of DMARC validation/alignment, the hybrid
+ RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if
+ it is aligned with the RFC5322.From [RFC5322] domain. The alignment
+ of the validated domain is determined based on the DMARC record's
+ "strict" or "relaxed" designation as described above for the DKIM
+ identifiers and in [RFC7489].
+
+2.1.3. Multiple RFC5322.From Addresses
+
+ [RFC5322] permits only one From header field, but it may contain
+ multiple mailboxes. Since this is an extremely rare usage, DMARC
+ specifies that the handling of this situation is implementation
+ dependent.
+
+ Because the presence of multiple domains can be used by an attacker
+ (an attacker could add their domain to the RFC5322.From field,
+ provide arbitrary new content, and sign the message), the DMARC
+ specification recommends that the strictest policy be applied to such
+ messages (Section 6.6.1 of [RFC7489]).
+
+2.2. Message Forwarding
+
+ Section 3 describes forwarding behavior as it relates to the
+ components of the Internet Mail Architecture.
+
+ All forwarding operations involve the retransmission of email. As
+ discussed above, in order for SPF to yield an Authenticated
+ Identifier that is pertinent to DMARC, the domain of the
+
+
+
+Martin, et al. Informational [Page 6]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ RFC7208.MAILFROM must be in alignment with the RFC5322.From header
+ field. Forwarding introduces specific issues to the availability of
+ SPF-based Authenticated Identifiers:
+
+ o If the RFC5321.MailFrom is present and the forwarder maintains the
+ original RFC5321.MailFrom, SPF validation will fail unless the
+ forwarder is an authorized part of the originator's email sending
+ infrastructure. If the forwarder replaces the RFC5321.MailFrom
+ with its own domain, SPF might pass, but Identifier Alignment with
+ the RFC5322.From header field will fail.
+
+ o If the RFC5321.MailFrom is empty (as in the case of Delivery
+ Status Notifications), the RFC5321.HELO/.EHLO domain of the
+ forwarder will likely be in a different Organizational Domain than
+ the original RFC5322.From header field's domain. SPF may pass,
+ but Identifier Alignment with the RFC5322.From header field will
+ fail.
+
+ In both cases, SPF cannot yield relevant Authenticated Identifiers,
+ and DKIM must be relied upon to produce results that are relevant to
+ DMARC.
+
+2.3. Message Modification
+
+ Modification of email content invalidates most DKIM signatures, and
+ many message-forwarding systems modify email content. Mailing List
+ processors are a common example of such systems, but other forwarding
+ systems also make modifications.
+
+ Although DKIM provides a length flag so that content can be appended
+ without invalidating the signature, in practice, particularly with
+ MIME-encoded [RFC2045] messages, a Mailing List processor will do
+ more than simply append content (see Section 5.3 of [RFC5598] for
+ details). Furthermore, the length flag is seldom used due to
+ security issues (see Section 8.2 of [RFC6376] for additional security
+ considerations). Therefore, this method is only mentioned here for
+ completeness.
+
+ DKIM describes two canonicalizations for use when preparing the
+ header and body for DKIM processing: simple and relaxed. The latter
+ is designed to accommodate trivial modifications to whitespace and
+ folding that, at least in the header case, generally have no semantic
+ significance. However, the relaxed canonicalization is more
+ computationally intensive and may not have been preferred in the
+ early deployment of DKIM, leaving some deployments using the less
+ forgiving "simple" canonicalization. While the prevalence is
+ unknown, there are some DKIM verifiers that have problems evaluating
+ relaxed canonicalization correctly.
+
+
+
+Martin, et al. Informational [Page 7]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+3. Internet Mail Architecture, DMARC, and Indirect Email Flows
+
+ This section describes components within the Internet Mail
+ Architecture [RFC5598] where interoperability issues between DMARC
+ and indirect email flows can be found.
+
+3.1. Message Handling System
+
+ Section 4 of [RFC5598] describes six basic components that make up
+ the Message Handling System (MHS):
+
+ o Message
+
+ o Message User Agent (MUA)
+
+ o Message Submission Agent (MSA)
+
+ o Message Transfer Agent (MTA)
+
+ o Message Delivery Agent (MDA)
+
+ o Message Store (MS)
+
+ Of these components, MSA, MTA, and MDA are discussed in relation to
+ interoperability with DMARC.
+
+ Section 5 of [RFC5598] also defines a Mediator as a hybrid of several
+ component types. A Mediator is given special consideration in this
+ section due to the unique issues they face when attempting to
+ interoperate with DMARC.
+
+3.1.1. Message Submission Agents
+
+ An MSA accepts messages submitted by a Message User Agent (MUA) and
+ enforces the policies of the hosting ADministrative Management Domain
+ (ADMD) and the requirements of Internet standards.
+
+ MSAs are split into two sub-components:
+
+ o Author-focused MSA functions (aMSA)
+
+ o MHS-focused MSA functions (hMSA)
+
+ MSA interoperability issues with DMARC begin when an aMSA accepts a
+ message where the RFC5322.From header field contains a domain that is
+ outside of the ADMD of the MSA. This situation manifests in one of
+ several ways, such as when someone uses a mail service with their own
+ domain but has failed to properly configure an SPF record or when an
+
+
+
+Martin, et al. Informational [Page 8]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ MUA attempts to transmit mail as someone else. Examples of the
+ latter situation include "forward-to-friend" functionality commonly
+ found on news/article websites or "send-as" functionality present on
+ some MUAs.
+
+ When an hMSA takes responsibility for transit of a message containing
+ a domain in the RFC5322.From header field that is outside of the
+ hMSA's ADMD, the hMSA faces DMARC interoperability issues if the
+ domain publishes a DMARC policy of "quarantine" or "reject". These
+ issues are marked by the inherent difficulty of establishing
+ alignment with the domain present in a message's RFC5322.From header
+ field. Examples of this issue include:
+
+ o Partially open relays - a residential ISP that allows its
+ customers to relay non-local domains through its infrastructure.
+
+ o Embedded devices - cable/DSL modems, firewalls, wireless access
+ points, and printers that send email using hardcoded domains.
+
+ o Devices that send mail on behalf of a user - scanners, security
+ cameras, and alarms that send mail as their owner or a device
+ user.
+
+ o Email service providers - ESPs that service customers who are
+ using domains that publish a DMARC "reject" policy.
+
+ o Calendaring software - an invited member of an event modifies the
+ event, causing the calendaring software to emit an update that
+ claims to come from the creator of the event.
+
+3.1.2. Message Transfer Agents
+
+ MTAs relay a message until the message reaches a destination MDA.
+ Some common message-handling strategies break the integrity of DKIM
+ signatures. A restrictive DMARC policy along with a broken DKIM
+ signature causes latent interoperability problems to become overt
+ problems.
+
+3.1.2.1. Message Encoding
+
+ An MTA may modify the message encoding, for instance, by converting
+ 8-bit MIME sections to quoted-printable 7-bit sections. This
+ modification is outside the scope of DKIM canonicalization and will
+ invalidate DKIM signatures that include message content.
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 9]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ An MTA could also re-encode the message without changing the encoding
+ type: receiving a MIME-encoded message and producing a semantically
+ and semiotically equivalent MIME body that is not identical to the
+ original. This is characteristic of systems that use some other
+ message representation internally.
+
+3.1.2.2. Header Standardization
+
+ An MTA may rewrite headers to bring them into compliance with
+ existing RFCs. For example, some common MTAs will correct
+ comprehensible but non-compliant date formats to compliant ones.
+
+ Header rewriting is outside the scope of DKIM canonicalization and
+ will invalidate DKIM signatures. All downstream DMARC processing
+ with be unable to utilize DKIM to yield Authenticated Identifiers due
+ to header rewriting.
+
+ Providing solutions for issues relating to non-RFC-compliant emails
+ is outside the scope of this document.
+
+3.1.2.3. Content Validation
+
+ An MTA may also implement security-motivated changes to the content
+ of email messages, dropping or altering sections of messages, causing
+ breakage of DKIM signatures.
+
+3.1.3. Message Delivery Agents
+
+ The MDA transfers a message from the MHS to a mailbox. Like the MSA,
+ the MDA consists of two sub-components:
+
+ o MHS-focused MDA functions (hMDA)
+
+ o Recipient-focused MDA functions (rMDA)
+
+ Both the hMDA and the rMDA can redirect a message to an alternative
+ address. DMARC interoperability issues related to redirecting of
+ messages are described in Section 3.2.
+
+ Sieve [RFC5228] functionality often lives in the rMDA sub-component
+ and can cause DMARC interoperability issues. The Sieve 'addheader'
+ and 'deleteheader' filtering actions can modify messages and
+ invalidate DKIM signatures, removing DKIM-supplied Authenticated
+ Identifiers as inputs to the DMARC mechanism. There are also Sieve
+ extensions [RFC5703] that modify the body. Sieve alterations may
+ only become an issue when the email is reintroduced into the
+ transport infrastructure.
+
+
+
+
+Martin, et al. Informational [Page 10]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+3.2. Mediators
+
+ Mediators [RFC5598] forward messages through a re-posting process.
+ Mediators share some functionality with basic MTA relaying but have
+ greater flexibility in both addressing and content modifications.
+
+ DMARC interoperability issues are common within the context of
+ Mediators, which are often used precisely for their ability to modify
+ messages.
+
+ The DMARC design does not cope with some Mediator functionality such
+ as content modifications that invalidate DKIM signatures and
+ RFC5321.MailFrom rewriting to support SPF authentication of re-sent
+ mail when the new Recipient receives the message from the Mediator
+ rather than the initial organization.
+
+3.2.1. Alias
+
+ An Alias is a simple re-addressing facility that provides one or more
+ new Internet Mail addresses, rather than a single, internal one. A
+ message continues through the transfer service for delivery to one or
+ more alternative addresses.
+
+ Aliases can be implemented by mailbox-level forwarding (e.g., through
+ "dot-forwarding"), Sieve-level forwarding (through the Sieve
+ "redirect" action), or other methods. When an Alias preserves
+ message content and does not make significant header changes, DKIM
+ signatures may remain valid. However, Aliases often extend the
+ delivery path outside of the scope covered by the originating ADMD's
+ SPF record(s).
+
+ Examples of Aliasing include:
+
+ o Forwarding email between free email (freemail) providers to try
+ different interfaces while maintaining an original email address;
+
+ o Consolidating many email addresses into a single account to
+ centralize processing; and
+
+ o Services that provide "activity-based", "role-based", "vanity", or
+ "temporary" email addresses such as universities and professional
+ associations. For instance, professional or alumni institutions
+ may offer their members an Alias for the duration of their
+ membership but may not want to deal with the long-term storage of
+ emails.
+
+
+
+
+
+
+Martin, et al. Informational [Page 11]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ In most cases, the aMSA providing Alias services has no
+ administrative relationship to the ADMD of the originator or the
+ Final Recipient, so solutions to Alias-related DMARC failure should
+ not assume such a relationship.
+
+3.2.2. ReSenders
+
+ ReSenders "splice" a message's addressing information to connect the
+ Author of the original message with the Recipient(s) of the new
+ message. The new Recipient sees the message as being from the
+ original Author, even if the Mediator adds commentary.
+
+ Without Authenticated Identifiers aligned with the Author's
+ RFC5322.From header field domain, the new Recipient has no way to
+ achieve a passing DMARC evaluation.
+
+ Examples of ReSenders include MUA-level forwarding by resending a
+ message to a new Recipient or by forwarding a message "inline" to a
+ new Recipient (this does not include forwarding a message "as an
+ attachment"). An additional example comes in the form of calendaring
+ software that allows a meeting attendee (not the meeting organizer)
+ to modify the content of an invite generating new invitations that
+ claim to be reissued from the meeting organizer.
+
+3.2.3. Mailing Lists
+
+ A Mailing List receives messages as an explicit addressee and then
+ reposts them to a list of subscribed members. The Mailing List
+ performs a task that can be viewed as an elaboration of the ReSender
+ actions.
+
+ Mailing Lists share the same DMARC interoperability issues as
+ ReSenders (Section 3.2.2) and very commonly modify headers or message
+ content in ways that will cause DKIM to fail, including:
+
+ o prepending the RFC5322.Subject header field with a tag, to allow
+ the Recipient to easily identify the Mailing List within a subject
+ line listing;
+
+ o adding a footer to the email body to contain administrative
+ instructions;
+
+ o removing some MIME-parts from the email or converting the message
+ to text only;
+
+ o encrypting the body with the Recipient's key using PGP (Pretty
+ Good Privacy) or S/MIME;
+
+
+
+
+Martin, et al. Informational [Page 12]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ o enforcing community standards by rewriting banned words; and
+
+ o allowing moderators to add arbitrary commentary to messages
+ (discussed in [RFC6377]).
+
+ Any such modifications would invalidate a DKIM signature.
+
+ Header and content modifications are common for many Mailing Lists
+ and are often central to present Mailing List functionality and
+ usage. Furthermore, MUAs have come to rely on Mailing List message
+ modifications to present messages to end users in expected ways.
+
+3.2.3.1. Mailing List Operational Effects
+
+ Mailing Lists may also have the following DMARC interoperability
+ issues:
+
+ o Subscribed members may not receive email from members that post
+ using domains that publish a DMARC "p=reject" policy.
+
+ o Mailing Lists may interpret DMARC-related email rejections as an
+ inability to deliver email to the Recipients that are checking and
+ enforcing DMARC policy. This processing may cause subscribers
+ that are checking and enforcing DMARC policy to be inadvertently
+ suspended or removed from the Mailing List.
+
+3.2.4. Gateways
+
+ A Gateway performs the basic routing and transfer work of message
+ relaying, but it is also permitted to modify content, structure,
+ addressing, and/or other attributes as needed to send the message
+ into a messaging environment that operates under different standards
+ or potentially incompatible policies.
+
+ Gateways share the same DMARC interoperability issues as ReSenders
+ (Section 3.2.2).
+
+ Gateways may also share the same DMARC interoperability issues as
+ MTAs (Section 3.1.2).
+
+ Receiver systems on the non-SMTP side of a protocol Gateway may be
+ unable to evaluate DKIM and SPF. If a message passes through a
+ second protocol Gateway back into the SMTP domain, the
+ transformations commonly break the original DKIM signature(s).
+
+ Gateway-level forwarding can introduce DMARC interoperability issues
+ if the Gateway is configured to rewrite the message into alternate
+ receiving domains. For example, an acquisition may lead an acquiring
+
+
+
+Martin, et al. Informational [Page 13]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ company to decide to decommission the acquired company's domains by
+ rewriting messages to use the domain of the acquiring company. Since
+ the RFC5322.To header field is usually DKIM-signed, this kind of
+ rewriting will invalidate such DKIM signatures.
+
+3.2.5. Boundary Filters
+
+ To enforce security boundaries, organizations can subject messages to
+ analysis for conformance with their safety policies. A filter might
+ alter the content to render it safe, such as by removing or otherwise
+ altering content deemed unacceptable.
+
+ Boundary Filters share the same DMARC interoperability issues as
+ ReSenders.
+
+ Issues may arise with SPF and DKIM evaluation if performed after
+ filter modifications.
+
+ Examples of Boundary Filters include:
+
+ o Malware scanning: To protect readers and its reputation, an MTA
+ that transfers a message may remove content believed to be harmful
+ from messages, reformulate content to canonical formats in order
+ to make them more trustworthy or easier to scan, and/or add text
+ in the body to indicate the message has been scanned. Any such
+ modifications would invalidate a DKIM signature.
+
+ o Spam filtering: To protect its reputation and assist other MTAs,
+ an MTA may modify a message to indicate its decision that the
+ message is likely to be unwanted and/or add text in the body to
+ indicate that such filtering has been done.
+
+ o Other text additions: An MTA may add an organizational disclaimer
+ or advertisement, for instance.
+
+ o URL alteration: Some systems will rewrite or alter embedded URLs
+ as a way to control the potential threat from malware.
+
+ o Secondary MX services: The secondary MX for an organization may be
+ external to the normal mail processing for the organization, and
+ it may queue and forward to the primary when it becomes available.
+ This will not invalidate DKIM but will prevent the primary from
+ validating SPF normally. In this case, however, it is
+ inappropriate for a primary MX server to perform an SPF check
+ against its own secondaries. Rather, the secondary MX should
+ perform this function and employ some trusted mechanism to
+ communicate the results of the SPF, DKIM, and DMARC evaluation(s)
+ to the primary MX server.
+
+
+
+Martin, et al. Informational [Page 14]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+3.3. Combinations
+
+ Indirect email flows can be combined. For example, a university
+ student may subscribe to a Mailing List (using his university email
+ address) while this university email address is configured to forward
+ all emails to a freemail or a post-education corporate account
+ provider where a more permanent email address for this student
+ exists.
+
+ Within an organization, the message may pass through various MTAs
+ (Section 3.1.2), each of which performs a different function
+ (authentication, filtering, distribution, etc.).
+
+4. Possible Mitigations of Interoperability Issues
+
+ Solutions to interoperability issues between DMARC and indirect email
+ flows vary widely in their scope and implications. They range from
+ improvements to underlying processing, such as proper handling of
+ multiple DKIM signatures, to more radical changes to the messaging
+ architecture. This section describes possible ways to address
+ interoperability issues. Note that these particular mechanisms may
+ not be considered "best practices" and may, in some cases, violate
+ various conventions or expectations.
+
+ Receivers sometimes need to deliver email messages that do not
+ conform to any standard or protocol, but are otherwise desired by end
+ users. Mitigating the impact of DMARC on indirect email flows is
+ especially important to receivers that operate services where ease of
+ use and compatibility with existing email flows is a priority.
+
+ DMARC provides a mechanism (local policy) for receivers to make
+ decisions about identity alignment acceptability based on information
+ outside DMARC and communicate those decisions as "overrides" to the
+ sender. This facility can be used to ease some interoperability
+ issues, although care is needed to ensure that this does not create
+ loopholes for abuse.
+
+ To further complicate the usage of mitigations, mitigation may not be
+ desired if the email in question is of a certain category of high
+ value or high risk (security-related) transactional messages (dealing
+ with financial transactions or medical records, for example). In
+ these cases, mitigating the impact of DMARC due to indirect email
+ flows may not be desirable (counterproductive or allowing for abuse).
+
+ As a final note, mail systems are diverse and widely deployed.
+ Systems of various ages and capabilities are expected to preserve
+ interoperability with the rest of the SMTP ecosystem. For instance,
+ Qmail is still used, although the base code has not been updated
+
+
+
+Martin, et al. Informational [Page 15]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ since 1998. ezmlm, a once popular MLM, is still deployed but has not
+ been updated since 1997, although a new version (ezmlm-idx) exists.
+ Old versions of other open- and closed-source MTAs are still commonly
+ in operation. When dealing with aging or unsupported systems, some
+ solutions may be time-consuming and/or disruptive to implement.
+
+4.1. Mitigations in Current Use
+
+ Because DMARC is already widely deployed, many operators already have
+ mitigations in use. These mitigations vary in their effectiveness
+ and side effects but have the advantage that they are currently
+ available.
+
+4.1.1. Mitigations for Senders
+
+4.1.1.1. Identifier Alignment
+
+ o MTAs handling multiple domains may choose to change
+ RFC5321.MailFrom to align with RFC5322.From to improve SPF
+ usability for DMARC.
+
+ o MTAs handling multiple domains may also choose to align
+ RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending
+ notification messages. Dynamically adjusting the
+ RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible
+ for some MTA software.
+
+ o MTAs may choose to DKIM-sign notification messages with an aligned
+ domain to allow a DKIM-based DMARC pass.
+
+ o MTAs sending email on behalf of multiple domains may require
+ Domain Owners to provide DKIM keys to use DKIM to avoid SPF
+ validation issues, given the requirement for DMARC alignment with
+ the RFC5322.From header field. Managing DKIM keys with a third
+ party has security risks that should be carefully managed (see
+ also [RFC6376], Section 8). Methods involving CNAMEs and/or
+ subdomains may alleviate some risks.
+
+ o Senders who are sending on behalf of users in other administrative
+ domains may choose to use an RFC5322.From under the sender's
+ control. The new From can be either a forwarding address in a
+ domain controlled by the Sender or a placeholder address, with the
+ original user's address in an RFC5322.Reply-to header field.
+ However, performing this modification may cause the Recipient's
+ MUA to deviate from customary behavior.
+
+
+
+
+
+
+Martin, et al. Informational [Page 16]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ o When implementing "forward-to-friend" functionality, one approach
+ to avoid DMARC failures is to pass a well-formed message to the
+ user's MUA so that it may fill in an appropriate identity and
+ submit through its own MSA.
+
+ o Senders can use domains with distinct DMARC policies for email
+ sent directly and email known to use indirect mail flows.
+ However, for most well-known brands, all active domains are likely
+ to be targeted equally by abusers.
+
+4.1.1.2. Message Modification
+
+ o Senders can maximize survivability of DKIM signatures by limiting
+ the header fields they sign and using relaxed canonicalization.
+ Using the DKIM length tag to allow appended signatures is
+ discouraged due to the security risk created by allowing arbitrary
+ content to be appended to legitimate email.
+
+ o Senders can also maximize survivability by starting with RFC-
+ compliant headers and common body formats.
+
+ o In order to minimize transport-based conversions, Senders can
+ convert messages to a lowest denominator MIME content-transfer
+ encoding such as quoted-printable or base64 before signing
+ ([RFC6376], Section 5.3).
+
+4.1.2. Mitigations for Receivers
+
+4.1.2.1. Identifier Alignment
+
+ o Receivers should update DKIM handling libraries to ensure that
+ they process all valid DKIM signatures and check each signature
+ for alignment.
+
+4.1.2.2. Policy Override
+
+ o Receivers can amalgamate data from their user base to create lists
+ of forwarders and use such lists to inform DMARC local policy
+ overrides. This process may be easier for large receivers where
+ data and resources to create such lists are more readily available
+ than at smaller sites, where there are fewer accounts that receive
+ forwarded mail and other resources may be scarce.
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 17]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+4.1.3. Mitigations for ReSenders
+
+4.1.3.1. Changes to the RFC5322.From
+
+ Many ReSender issues can be avoided by using an RFC5322.From header
+ field under the ReSender's control, instead of the initial
+ RFC5322.From. This will correct Identifier Alignment issues and
+ allow arbitrary message modification as long as the ReSender signs
+ the message with an aligned domain signature. When ReSenders change
+ the RFC5322.From, it is desirable to preserve the information about
+ the original initiator of the message.
+
+ A first option is to use the Original-From [RFC5703] (or X-Original-
+ From) header field for this purpose in various contexts (X- header
+ field names are discouraged by [RFC6648]). However, handling of
+ Original-From (or X-Original-From) is not defined anywhere. It is
+ not currently used consistently or displayed to the user, and in any
+ situation where it is used, it is a new unauthenticated identifier
+ available for exploitation unless included within the scope of the
+ new DKIM signature(s).
+
+ Another option for ReSenders is to rewrite the RFC5322.From header
+ field address to a locally controlled address that will be forwarded
+ back to the original sender (subject to its own ReSender forwarding
+ mitigations).
+
+4.1.3.2. Avoiding Message Modification
+
+ o Forwarders can choose to add email header fields instead of
+ modifying existing headers or bodies, for instance, to indicate a
+ message may be spam.
+
+ o Forwarders can minimize the circumstances in which they choose to
+ fix messages, preferring to preserve non-compliant headers to
+ creating DKIM failures.
+
+ o Forwarders can choose to reject messages with suspect or harmful
+ content instead of modifying them.
+
+4.1.3.3. Mailing Lists
+
+ [RFC6377] provides some guidance on using DKIM with Mailing lists.
+ The following mitigation techniques can be used to ease
+ interoperability issues with DMARC and Mailing lists:
+
+ o Configuring the Mailing List Manager (MLM) to alter the
+ RFC5322.From header field to use the domain of the MLM is a
+ mitigation policy that is now present in several different Mailing
+
+
+
+Martin, et al. Informational [Page 18]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ List software distributions. Since most list subscribers prefer
+ to know the identity of the Author of the original message,
+ typically this information may be provided in the display name
+ part of the RFC5322.From header field. This display name needs to
+ be carefully crafted so as to not collide with the original
+ display name of the Author, nor contain something that looks like
+ an email address or domain name. These modifications may to some
+ extent defeat the purpose of DMARC itself. It may make it
+ difficult to ensure that users of all email clients can easily
+ reply to the Author, the list, or all using the email client
+ features provided for that purpose. Use of the RFC5322.Reply-To
+ header field can alleviate this problem depending on whether the
+ Mailing List is configured to reply-to-list, reply-to-author, or
+ reply-to-fixed-address; however, it is important to note that this
+ header field can take multiple email addresses. When altering the
+ RFC5322.From, there are three possibilities:
+
+ 1. change it to put the Mailing List email address,
+
+ 2. change it to a locally defined address that will be forwarded
+ back to the original sender, or
+
+ 3. "break" the address by modifying the domain to a non-existent
+ domain (such as by adding a suffix like ".invalid").
+
+ The latter modification may create issues because it is an invalid
+ domain name, and some MTAs may pay particular attention to the
+ validity of email addresses in RFC5322.From and the reputation of
+ the domains present there.
+
+ o Configuring the MLM to "wrap" the message in a MIME message/rfc822
+ part and to send as the Mailing List email address. Many email
+ clients (as of the publication of this document), especially
+ mobile clients, have difficulty reading such messages, and this is
+ not expected to change soon.
+
+ o Configuring the MLM to not modify the message so that the DKIM
+ signature remains valid. Some Mailing Lists are set up this way
+ and require few additional changes to ensure the DKIM signature is
+ preserved. Moving lists that currently modify mail to a policy
+ like this may be too much of a change for the members of such
+ lists.
+
+ o Rejecting posts or membership requests from domains with a DMARC
+ policy other than "p=none". However, members or potential members
+ of such Mailing Lists may complain of unfair exclusion.
+
+
+
+
+
+Martin, et al. Informational [Page 19]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ o To alleviate unsubscribes to the Mailing List due to the messages
+ bouncing because of DMARC, the MLM needs to not act on
+ notification messages due to message authentication issues.
+ [RFC3463] specifies Enhanced Mail System Status Codes, which help
+ differentiate between various failure conditions. Correctly
+ interpreting Extended SMTP error messages is useful in this case.
+ In particular, extended status codes for SPF and DKIM causes are
+ defined in [RFC7372], and DMARC-related failure indications are
+ discussed in DMARC ([RFC7489], Section 10.3).
+
+ All these techniques may provide some specific challenges to MUAs and
+ different operational usages for end users (like rewriting filters to
+ sort emails in folders). There will be some time before all
+ implications are understood and accommodated.
+
+4.2. Proposed and In-Progress Mitigations
+
+ The following mitigations are based on Internet-Drafts (I-Ds) that
+ are still in process. They are described here to offer an
+ exploratory path for solutions. These solutions should not be used
+ in a production environment. Because of the transient nature of
+ I-Ds, specific citations are not included because a number of them
+ will inevitably become obsolete, and those that gain consensus in the
+ community will become RFCs and should be discovered as such.
+
+ o Third-party authorization schemes provide ways to extend
+ Identifier Alignment under control of the Domain Owner.
+
+ o Ways to canonicalize messages that transit Mailing Lists so that
+ their alterations can be isolated from the original signed
+ content.
+
+ o Mechanisms to record message transformations applied at each hop
+ so they can be reversed and the original signed content recovered.
+
+ o "Conditional" DKIM signatures, whereby the Author domain indicates
+ its signature is only good if accompanied by a signature from an
+ expected downstream relay.
+
+ o Mechanisms to extend Authentication-Results [RFC7601] to multiple
+ hops, creating a provable chain of custody as well as a view of
+ message authentication results at each handling step.
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 20]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+4.2.1. Getting More Radical: Requiring New Communication Paths between
+ MUAs
+
+ In practice, a number of operators are using strict alignment mode in
+ DMARC in order to avoid receiving new and innovative forms of
+ unwanted and unauthentic email through systems purporting to be
+ Mailing List handlers. The receiving ADMD has no knowledge of which
+ lists the user has subscribed to and which they have not. One avenue
+ of exploration would be for the user to authorize Mailing Lists as
+ proxies for authentication, at which point the receiving ADMD would
+ be vesting some trust in the Mailing List service. The creators of
+ DKIM foresaw precisely this possibility at the time by not tightly
+ binding any semantics to the RFC5322.From header field. Some
+ experimental work has taken place in this area, as mentioned above.
+ Additional work might examine a new communication path to the user to
+ authorize some form of transitive trust.
+
+5. Security Considerations
+
+ This document is an analysis of DMARC's impact on indirect email
+ flows. It describes the possibility of accidental denial of service
+ that can be created by rejections of messages by DMARC-aware mail
+ receivers.
+
+ Section 4.1.1.1 discusses the importance of appropriate DKIM key
+ management vis-a-vis third-party email senders.
+
+ Section 4.1.3.3 warns that rewriting the RFC5322.From header field to
+ create an artificial domain name should not be done with any domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 21]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
+ <http://www.rfc-editor.org/info/rfc2045>.
+
+ [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
+ RFC 3463, DOI 10.17487/RFC3463, January 2003,
+ <http://www.rfc-editor.org/info/rfc3463>.
+
+ [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
+ Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
+ January 2008, <http://www.rfc-editor.org/info/rfc5228>.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ DOI 10.17487/RFC5321, October 2008,
+ <http://www.rfc-editor.org/info/rfc5321>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <http://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
+ DOI 10.17487/RFC5598, July 2009,
+ <http://www.rfc-editor.org/info/rfc5598>.
+
+ [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
+ Tests, Iteration, Extraction, Replacement, and Enclosure",
+ RFC 5703, DOI 10.17487/RFC5703, October 2009,
+ <http://www.rfc-editor.org/info/rfc5703>.
+
+ [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+ "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
+ RFC 6376, DOI 10.17487/RFC6376, September 2011,
+ <http://www.rfc-editor.org/info/rfc6376>.
+
+ [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
+ Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
+ September 2011, <http://www.rfc-editor.org/info/rfc6377>.
+
+ [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
+ "Deprecating the "X-" Prefix and Similar Constructs in
+ Application Protocols", BCP 178, RFC 6648,
+ DOI 10.17487/RFC6648, June 2012,
+ <http://www.rfc-editor.org/info/rfc6648>.
+
+
+
+Martin, et al. Informational [Page 22]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
+ Authorizing Use of Domains in Email, Version 1", RFC 7208,
+ DOI 10.17487/RFC7208, April 2014,
+ <http://www.rfc-editor.org/info/rfc7208>.
+
+ [RFC7372] Kucherawy, M., "Email Authentication Status Codes",
+ RFC 7372, DOI 10.17487/RFC7372, September 2014,
+ <http://www.rfc-editor.org/info/rfc7372>.
+
+6.2. Informative References
+
+ [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
+ Message Authentication, Reporting, and Conformance
+ (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
+ <http://www.rfc-editor.org/info/rfc7489>.
+
+ [RFC7601] Kucherawy, M., "Message Header Field for Indicating
+ Message Authentication Status", RFC 7601,
+ DOI 10.17487/RFC7601, August 2015,
+ <http://www.rfc-editor.org/info/rfc7601>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 23]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+Appendix A. Example SPF Bounce
+
+ This example illustrates a notification message "bounce".
+
+A.1. Initial Message
+
+ Here is the message as it exits the Origin MTA (segv.d1.example):
+
+ Return-Path: <jqd@d1.example>
+ Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
+ (authenticated bits=0)
+ by segv.d1.example with ESMTP id t0FN4a8O084569;
+ Thu, 14 Jan 2015 15:00:01 -0800 (PST)
+ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
+ s=20130426; t=1421363082;
+ bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
+ h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
+ Content-Transfer-Encoding;
+ b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
+ bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
+ gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
+ Message-ID: <54B84785.1060301@d1.example>
+ Date: Thu, 14 Jan 2015 15:00:01 -0800
+ From: John Q Doe <jqd@d1.example>
+ To: no-recipient@dmarc.org
+ Subject: Example 1
+
+ Hey gang,
+ This is a test message.
+ --J.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 24]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+A.2. Notification Message
+
+ When dmarc.org rejects the message without a DKIM signature, it
+ specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has
+ no SPF record. dmarc.org has a reject policy in place for such non-
+ passing cases. Since there is no DKIM signature on the notification
+ message, the failed SPF lookup results in a dmarc=fail, and
+ d1.example could be expected to discard the notification message
+ itself:
+
+ Return-Path: <>
+ Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
+ by mx.d1.example with ESMTPS id Lkm25302jJR5
+ for <jqd@d1.example>
+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
+ Thu, 14 Jan 2015 15:00:24 -0800 (PST)
+ Authentication-Results: mx.d1.example;
+ spf=none (d1.example: dmarc.org.local does not designate
+ permitted sender hosts) smtp.mail=;
+ dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
+ MIME-Version: 1.0
+ Received: from segv.d1.example (segv.d1.example [198.51.100.1])
+ by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
+ 14 Jan 2015 15:00:24 -0800 (PST)
+ From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
+ To: jqd@d1.example
+ Subject: Delivery Status Notification (Failure)
+ Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
+ Date: Thu, 14 Jan 2016 23:00:24 +0000
+ Content-Type: text/plain; charset=UTF-8
+
+ This is an automatically generated Delivery Status Notification
+
+ Delivery to the following recipient failed permanently:
+
+ no-recipient@dmarc.org
+
+ Technical details of permanent failure:
+ Your message was rejected by the server for the recipient domain
+ dmarc.org by mail.dmarc.org [192.0.2.1].
+
+ The error that the other server returned was:
+ 550 5.1.1 <no-recipient@dmarc.org>... User unknown
+
+ ----- Original message -----
+ Return-Path: <jqd@d1.example>
+ Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
+ [203.252.0.131]) (authenticated bits=0)
+
+
+
+Martin, et al. Informational [Page 25]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+ by segv.d1.example with ESMTP id t0FN4a8O084569;
+ Thu, 14 Jan 2015 15:00:01 -0800 (PST)
+ (envelope-from jqd@d1.example)
+ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
+ s=20130426; t=1421363082;
+ bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
+ h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
+ Content-Transfer-Encoding;
+ b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
+ bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
+ gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
+ Message-ID: <54B84785.1060301@d1.example>
+ Date: Thu, 14 Jan 2015 15:00:01 -0800
+ From: John Q Doe <jqd@d1.example>
+ To: no-recipient@dmarc.org
+ Subject: Example 1
+
+ Hey gang,
+ This is a test message.
+ --J.
+
+Acknowledgments
+
+ Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf
+ E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF
+ DMARC Working Group's wiki page listing all known interoperability
+ issues with DMARC and indirect email flows.
+
+ Tim Draegen created the first draft of this document from these
+ contributions and by ham-fistedly mapping contributions into the
+ language of [RFC5598].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 26]
+
+RFC 7960 DMARC Indirect Email Interop Issues September 2016
+
+
+Authors' Addresses
+
+ Franck Martin (editor)
+ LinkedIn
+ Mountain View, CA
+ United States of America
+
+ Email: fmartin@linkedin.com
+
+
+ Eliot Lear (editor)
+ Cisco Systems GmbH
+ Richtistrasse 7
+ Wallisellen, ZH CH-8304
+ Switzerland
+
+ Phone: +41 44 878 9200
+ Email: lear@cisco.com
+
+
+ Tim Draegen (editor)
+ dmarcian, inc.
+ PO Box 1007
+ Brevard, NC 28712
+ United States of America
+
+ Email: tim@dmarcian.com
+
+
+ Elizabeth Zwicky (editor)
+ Yahoo
+ Sunnyvale, CA
+ United States of America
+
+ Email: zwicky@yahoo-inc.com
+
+
+ Kurt Andersen (editor)
+ LinkedIn
+ 2029 Stierlin Court
+ Mountain View, CA 94043
+ United States of America
+
+ Email: kandersen@linkedin.com
+
+
+
+
+
+
+
+Martin, et al. Informational [Page 27]
+