draft-ietf-dmarc-interoperability-06.txt   draft-ietf-dmarc-interoperability-07.txt 
DMARC F. Martin, Ed. DMARC F. Martin, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed. Intended status: Informational E. Lear, Ed.
Expires: February 29, 2016 Cisco Systems GmbH Expires: March 31, 2016 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
dmarcian, inc. dmarcian, inc.
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
K. Andersen, Ed. K. Andersen, Ed.
LinkedIn LinkedIn
August 28, 2015 September 28, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-06 draft-ietf-dmarc-interoperability-07
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 44 skipping to change at page 1, line 44
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 February 29, 2016. This Internet-Draft will expire on March 31, 2016.
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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 13
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15
4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 16 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 16
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 16 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 19 Paths Between MUAs . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
experience has shown that some implementations have difficulty experience has shown that some implementations have difficulty
processing multiple signatures. The impact on DMARC processing is processing multiple signatures. The impact on DMARC processing is
clear: implementations that cannot process multiple DKIM signatures clear: implementations that cannot process multiple DKIM signatures
may incorrectly flag messages as "failing DMARC" and erroneously may incorrectly flag messages as "failing DMARC" and erroneously
apply DMARC based policy to otherwise conforming messages. apply DMARC based policy to otherwise conforming messages.
SPF can provide two Authenticated Identifiers. The DMARC relevant SPF can provide two Authenticated Identifiers. The DMARC relevant
Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM
[RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the [RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the
RFC5321.MailFrom address is absent (as in the case of "bounce" RFC5321.MailFrom address is absent (as in the case of "bounce"
messages, on the domain found in the RFC5321.HELO/EHLO SMTP command. messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated
The SPF validated domain in RFC7208.MAILFROM must be part of the same domain in RFC7208.MAILFROM must be part of the same Organizational
Organizational Domain as the domain in the RFC5322.From header field Domain as the domain in the RFC5322.From header field to be aligned.
to be aligned. It is important to note that even when an SPF record It is important to note that even when an SPF record exists for the
exists for the domain in RFC5322.From, SPF will not authenticate it domain in RFC5322.From, SPF will not authenticate it unless it is
unless it is also the domain which the SPF analysis has checked. also the domain which the SPF analysis has checked. Also note that
Also note that RFC7208.MAILFROM definition is different from RFC7208.MAILFROM definition is different from RFC5321.MailFrom
RFC5321.MailFrom [RFC5321] definition. [RFC5321] definition.
2.2. Message Forwarding 2.2. Message Forwarding
Message forwarding is a generic concept encapsulating a variety of Message forwarding is a generic concept encapsulating a variety of
behaviors. Section 3 describes forwarding behavior as it relates to behaviors. Section 3 describes forwarding behavior as it relates to
the components of the Internet Mail Architecture. the components of the Internet Mail Architecture.
All forwarding behavior involves the retransmission of email. As All forwarding behavior involves the retransmission of email. As
discussed above, in order for SPF to yield an Authenticated discussed above, in order for SPF to yield an Authenticated
Identifier that is pertinent to DMARC, the domain of the Identifier that is pertinent to DMARC, the domain of the
skipping to change at page 15, line 19 skipping to change at page 15, line 19
o MTAs handling multiple domains may also choose to align o MTAs handling multiple domains may also choose to align
RFC5321.HELO/EHLO to RFC5322.From, particularly when sending RFC5321.HELO/EHLO to RFC5322.From, particularly when sending
bounce messages. Dynamically adjusting the RFC5321.HELO based on bounce messages. Dynamically adjusting the RFC5321.HELO based on
the RFC5322.From may not be possible for some MTA software. the RFC5322.From may not be possible for some MTA software.
o MTAs may choose to DKIM sign bounces with an aligned domain to o MTAs may choose to DKIM sign bounces with an aligned domain to
allow DKIM-based DMARC pass. allow DKIM-based DMARC pass.
o MTAs sending email on behalf of multiple domains may require o MTAs sending email on behalf of multiple domains may require
Domain Owners to provide DKIM keys to use DKIM to avoid DMARC Domain Owners to provide DKIM keys to use DKIM to avoid SPF
alignment issues with SPF. Managing DKIM keys with a third party validation issues, given the requirement for DMARC alignment with
has security risks which should be carefully managed. Methods the RFC5322.From header field. Managing DKIM keys with a third
involving CNAMEs and/or subdomains may alleviate some risks. party has security risks which should be carefully managed.
Methods involving CNAMEs and/or subdomains may alleviate some
risks.
o Senders who are sending on behalf of users in other Administrative o Senders who are sending on behalf of users in other Administrative
Domains may choose to use an RFC5322.From under the sender's Domains may choose to use an RFC5322.From under the sender's
control. The new From can be either a forwarding address in a control. The new From can be either a forwarding address in a
domain controlled by the Sender, or a placeholder address, with domain controlled by the Sender, or a placeholder address, with
the original user's address in a RFC5322.Reply-to header field. the original user's address in a RFC5322.Reply-to header field.
However, performing this modification may cause the recipient's However, performing this modification may cause the recipient's
MUA to deviate from customary behavior. MUA to deviate from customary behavior.
o Senders can use domains with distinct DMARC policies for email o Senders can use domains with distinct DMARC policies for email
 End of changes. 8 change blocks. 
18 lines changed or deleted 20 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/