draft-ietf-dmarc-interoperability-03.txt   draft-ietf-dmarc-interoperability-04.txt 
DMARC Working Group F. Martin, Ed. DMARC Working Group F. Martin, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed. Intended status: Informational E. Lear, Ed.
Expires: November 23, 2015 Cisco Systems GmbH Expires: December 11, 2015 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
Eudaemonic Development LLC Eudaemonic Development LLC
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
May 22, 2015 June 9, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-03 draft-ietf-dmarc-interoperability-04
Abstract Abstract
DMARC introduces a mechanism for expressing domain-level policies and DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting. preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain messages do not flow directly from the author's administrative domain
to the final recipients. Collectively these email flows are referred to the final recipients. Collectively these email flows are referred
to as indirect email flows. This document describes interoperability to as indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for issues between DMARC and indirect email flows. Possible methods for
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 23, 2015. This Internet-Draft will expire on December 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3
2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4 2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4
2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5
2.4. Message Modification . . . . . . . . . . . . . . . . . . 6 2.4. Message Modification . . . . . . . . . . . . . . . . . . 5
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6
3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7
3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8
3.1.2.3. Email Address Internationalization . . . . . . . 8 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12
4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 12
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13
4.1.1.2. Message Modification . . . . . . . . . . . . . . 14 4.1.1.2. Message Modification . . . . . . . . . . . . . . 13
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14
4.1.2.3. Email Address Internationalization . . . . . . . 15 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 15 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 15 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 14
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 15 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 16 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 17
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 18 Paths Between MUAs . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
DMARC [RFC7489] introduces a mechanism for expressing domain-level DMARC [RFC7489] introduces a mechanism for expressing domain-level
policies and preferences for message validation, disposition, and policies and preferences for message validation, disposition, and
reporting. The DMARC mechanism can encounter several different types reporting. The DMARC mechanism can encounter several different types
of interoperability issues due to third-party message sourcing, of interoperability issues due to third-party message sourcing,
message transformation or rerouting. message transformation or rerouting.
DMARC is, as this writing, an Informational RFC, however it has a DMARC is, as this writing, an Informational RFC, however it has a
skipping to change at page 8, line 26 skipping to change at page 8, line 15
3.1.2.2. Header Standardization 3.1.2.2. Header Standardization
An MTA may standardize headers, usually in order to make non-RFC An MTA may standardize headers, usually in order to make non-RFC
compliant headers properly compliant. For instance, some common MTAs compliant headers properly compliant. For instance, some common MTAs
will correct comprehensible but non-compliant date formats to will correct comprehensible but non-compliant date formats to
compliant ones. This correction is outside the scope of DKIM compliant ones. This correction is outside the scope of DKIM
canonicalization and will invalidate DKIM signatures. This canonicalization and will invalidate DKIM signatures. This
correction is also outside the scope of this document in providing correction is also outside the scope of this document in providing
solutions for non RFC compliant emails. solutions for non RFC compliant emails.
3.1.2.3. Email Address Internationalization
A DMARC related issue may arise in the context of Email Address
Internationalization [RFC6530]. [RFC6854] allows group syntax in the
RFC5322.From header field during the transition period to SMTPUTF8.
If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non-
aware MTA, the non aware MTA will reject it. While an MTA will not
downgrade a message. The MUA or MSA may resend the message using the
group syntax to allow the non-aware MTA to receive the email.
In another case, a MDA, may use the group syntax to pass a message to
a non EAI/SMTPUTF8-aware MS (or user email client). This message
could then be forwarded to another recipient.
For an MTA, the group syntax may result in the impossibility of
finding a domain with a DMARC policy associated with it. If the
receiving MTA pays attention to the validity and reputation of
domains, this may present its own set of delivery problems. For
instance an MTA may refuse emails with no valid or emailable domain
in the RFC5322.From as to avoid simple workarounds against DMARC.
This case is not an interoperability issue with DMARC, but with other
email policies an MTA may have to support DMARC.
3.1.3. Message Delivery Agents 3.1.3. Message Delivery Agents
The MDA transfers a message from the MHS to a mailbox. Like the MSA, The MDA transfers a message from the MHS to a mailbox. Like the MSA,
the MDA consists of two sub-components: the MDA consists of two sub-components:
o MHS-focused MDA functions (hMDA) o MHS-focused MDA functions (hMDA)
o Recipient-focused MDA functions (rMDA) o Recipient-focused MDA functions (rMDA)
Both the hMDA and the rMDA can redirect a message to an alternative Both the hMDA and the rMDA can redirect a message to an alternative
skipping to change at page 15, line 5 skipping to change at page 14, line 25
they process all valid DKIM signatures and check them for they process all valid DKIM signatures and check them for
alignment. alignment.
4.1.2.2. Policy Override 4.1.2.2. Policy Override
o Receivers can amalgamate data from their user base to identify o Receivers can amalgamate data from their user base to identify
forwarders and use such list for a DMARC local policy override. forwarders and use such list for a DMARC local policy override.
This process may be easier for large receivers, where there is This process may be easier for large receivers, where there is
data and resources to create such lists, than for small receivers. data and resources to create such lists, than for small receivers.
4.1.2.3. Email Address Internationalization
o During the transition from email systems that do not allow EAI
(SMTPUTF8) to email systems that allow it, [RFC6854] allows the
MUA or MSA to use the group syntax for the RFC5322.From header
field to avoid a known MTA to reject the message (if RFC5322 is
implemented strictly). While this will alleviate the EAI problem,
it will allow a simple DMARC workaround since the message may no
longer have a single usable domain in the RFC5322.From header
field, making DMARC inapplicable. DMARC implementations that pay
attention to the validity of the domains in the RFC5322.From may
then have to choose between EAI transitioning compliance
(accepting the email without a domain in RFC5322.From) and
security (rejecting RFC-compliant email for lack of a domain in
the RFC5322.From). The practical solution is to upgrade MTAs to
support EAI (SMTPUTF8), avoiding the transition issue.
4.1.3. Mitigations for ReSenders 4.1.3. Mitigations for ReSenders
4.1.3.1. Changes to the RFC5322.From 4.1.3.1. Changes to the RFC5322.From
Many ReSender issues can be avoided by using an RFC5322.From under Many ReSender issues can be avoided by using an RFC5322.From header
the ReSender's control, instead of the initial RFC5322.From. This field under the ReSender's control, instead of the initial
will correct identifier alignment issues and allow arbitrary message RFC5322.From. This will correct identifier alignment issues and
modification, for instance. When ReSenders change the RFC5322.From, allow arbitrary message modification, for instance. When ReSenders
it is desirable to preserve the information about the original change the RFC5322.From, it is desirable to preserve the information
initiator of the message. The Original-From [RFC5703] (or X- about the original initiator of the message.
Original-From) header field is used for this purpose in various
contexts (X- header fields name are discouraged by [RFC6648]).
However, handling of Original-From (or X-Original-From) is not A first option is to use the Original-From [RFC5703] (or X-Original-
defined anywhere. It is not currently used consistently or displayed From) header field for this purpose in various contexts (X- header
to the user, but in any situation where it is used, it is a new fields name are discouraged by [RFC6648]). However, handling of
unauthenticated identifier available for exploitation. Original-From (or X-Original-From) is not defined anywhere. It is
not currently used consistently or displayed to the user, but in any
situation where it is used, it is a new unauthenticated identifier
available for exploitation.
Another option for ReSenders is to rewrite the RFC5322.From header
field address to a valid forwarding address to the original sender,
in a domain that the ReSender controls.
4.1.3.2. Avoiding Message Modification 4.1.3.2. Avoiding Message Modification
o Forwarders can choose to add email header fields instead of o Forwarders can choose to add email header fields instead of
modifying existing headers or bodies, for instance to indicate a modifying existing headers or bodies, for instance to indicate a
message may be spam. message may be spam.
o Forwarders can minimize the circumstances in which they choose to o Forwarders can minimize the circumstances in which they choose to
fix messages, preferring to preserve non-compliant headers to fix messages, preferring to preserve non-compliant headers to
creating DKIM failures. creating DKIM failures.
skipping to change at page 19, line 31 skipping to change at page 18, line 39
Tests, Iteration, Extraction, Replacement, and Enclosure", Tests, Iteration, Extraction, Replacement, and Enclosure",
RFC 5703, October 2009. RFC 5703, October 2009.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376, Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011. September 2011.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, September 2011. 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) [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM)
Authorized Third-Party Signatures", RFC 6541, February Authorized Third-Party Signatures", RFC 6541, February
2012. 2012.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. 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 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
April 2014. April 2014.
[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC
7372, September 2014. 7372, September 2014.
8.2. Informative References 8.2. Informative References
[I-D.kucherawy-dkim-delegate] [I-D.kucherawy-dkim-delegate]
 End of changes. 20 change blocks. 
89 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/