draft-ietf-dmarc-interoperability-08.txt   draft-ietf-dmarc-interoperability-09.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: April 21, 2016 Cisco Systems GmbH Expires: May 8, 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
October 19, 2015 November 5, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-08 draft-ietf-dmarc-interoperability-09
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 April 21, 2016. This Internet-Draft will expire on May 8, 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 4, line 20 skipping to change at page 4, line 20
DMARC [RFC7489]. DMARC [RFC7489].
2. Causes of Interoperability Issues 2. Causes of Interoperability Issues
Interoperability issues between DMARC and indirect email flows arise Interoperability issues between DMARC and indirect email flows arise
when conformance to the DMARC specification leads a receiving when conformance to the DMARC specification leads a receiving
implementation to apply DMARC based policy restrictions to messages implementation to apply DMARC based policy restrictions to messages
that are both compliant with the architecture as specified in that are both compliant with the architecture as specified in
[RFC5598] and viewed as legitimate by the intended recipient. [RFC5598] and viewed as legitimate by the intended recipient.
Note that domains which assert a p=None policy and email which passes Note that domains which assert a "p=none" policy and email which
standard DMARC validation do not have any interoperability issues. passes standard DMARC validation do not have any interoperability
issues.
Email messages that do not conform to other email specifications but Email messages that do not conform to other email specifications but
are considered legitimate by the intended recipients are not are considered legitimate by the intended recipients are not
discussed in this document. The rest of this section describes discussed in this document. The rest of this section describes
several conceptual causes of interoperability issues. several conceptual causes of interoperability issues.
2.1. Identifier Alignment 2.1. Identifier Alignment
DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
source validation. The DMARC [RFC7489] mechanism refers to source source validation. The DMARC [RFC7489] mechanism refers to source
skipping to change at page 5, line 26 skipping to change at page 5, line 27
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 RFC5321.HELO/EHLO SMTP domain. The SPF validated messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated
domain in RFC7208.MAILFROM must be part of the same Organizational domain in RFC7208.MAILFROM must be part of the same Organizational
Domain as the domain in the RFC5322.From header field to be aligned. Domain as the domain in the RFC5322.From header field to be aligned.
It is important to note that even when an SPF record exists for the It is important to note that even when an SPF record exists for the
domain in RFC5322.From, SPF will not authenticate it unless it is domain in RFC5322.From [RFC5322], SPF will not authenticate it unless
also the domain which the SPF analysis has checked. Also note that it is also the domain checked by SPF. Also note that the
RFC7208.MAILFROM definition is different from RFC5321.MailFrom RFC7208.MAILFROM definition is different from the 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
skipping to change at page 6, line 7 skipping to change at page 6, line 7
o If the RFC5321.MailFrom is present and the forwarder maintains the o If the RFC5321.MailFrom is present and the forwarder maintains the
original RFC5321.MailFrom, SPF validation will fail unless the original RFC5321.MailFrom, SPF validation will fail unless the
forwarder is an authorized part of the originator's email sending forwarder is an authorized part of the originator's email sending
infrastructure. If the forwarder replaces the RFC5321.MailFrom infrastructure. If the forwarder replaces the RFC5321.MailFrom
with its own domain, SPF might pass but Identifier Alignment with with its own domain, SPF might pass but Identifier Alignment with
the RFC5322.From header field will fail. the RFC5322.From header field will fail.
o If the RFC5321.MailFrom is empty (as in the case of Delivery o If the RFC5321.MailFrom is empty (as in the case of Delivery
Status Notifications), the RFC5321.Helo domain of the forwarder Status Notifications), the RFC5321.Helo domain of the forwarder
will likely be in different organizational domain of the will likely be in different organizational domain than the orignal
RFC5322.From header field. SPF may pass but Identifier Alignment RFC5322.From header field's domain. SPF may pass but Identifier
with the RFC5322.From header field fails. Alignment with the RFC5322.From header field will fail.
In both cases, SPF cannot yield relevant Authenticated Identifiers, In both cases, SPF cannot yield relevant Authenticated Identifiers,
and DKIM must be relied upon to produce results that are relevant to and DKIM must be relied upon to produce results that are relevant to
DMARC. DMARC.
2.3. Message Modification 2.3. Message Modification
Modification of email content invalidates most DKIM signatures, and Modification of email content invalidates most DKIM signatures, and
many message forwarding systems modify email content. Mailing list many message forwarding systems modify email content. Mailing list
processors are a common example of such systems, but other forwarding processors are a common example of such systems, but other forwarding
systems also make modifications. systems also make modifications.
Although DKIM provides a length flag so that content can be appended Although DKIM provides a length flag so that content can be appended
without invalidating the signature, in practice, particularly with without invalidating the signature, in practice, particularly with
MIME-encoded [RFC2045] messages, a mailing list processor will do MIME-encoded [RFC2045] messages, a mailing list processor will do
more than simply append content (see Section 5.3 of [RFC5598] for more than simply append content (see Section 5.3 of [RFC5598] for
details). Furthermore, the length flag is seldom used due to details). Furthermore, the length flag is seldom used due to
security issues (see Section 8.2 of [RFC6376] for additional security security issues (see Section 8.2 of [RFC6376] for additional security
considerations), therefore, this method is only here mentionned for considerations), therefore, this method is only here mentioned for
completeness. completeness.
DKIM describes two canonicalizations for use when preparing headers DKIM describes two canonicalizations for use when preparing header
and body for DKIM processing: simple and relaxed. The latter allows and body for DKIM processing: simple and relaxed. The latter allows
for trivial modifications (largely regarding whitespace folding) that for trivial modifications (largely regarding whitespace and folding)
maintain the integrity of the content of the email. However, the that maintain the integrity of the content of the email. However,
relaxed canonicalization is more computationally intensive and may the relaxed canonicalization is more computationally intensive and
not have been preferred in the early deployment of DKIM, leaving some may not have been preferred in the early deployment of DKIM, leaving
deployments using the less forgiving "simple" canonicalization. some deployments using the less forgiving "simple" canonicalization.
While the prevalence is unknown, there are some DKIM checkers which While the prevalence is unknown, there are some DKIM verifiers which
have problems evaluating relaxed canonicalization correctly. have problems evaluating relaxed canonicalization correctly.
3. Internet Mail Architecture, DMARC, and Indirect Email Flows 3. Internet Mail Architecture, DMARC, and Indirect Email Flows
This section describes components within the Internet Mail This section describes components within the Internet Mail
Architecture [RFC5598] where interoperability issues between DMARC Architecture [RFC5598] where interoperability issues between DMARC
and indirect email flows can be found. and indirect email flows can be found.
3.1. Message Handling System 3.1. Message Handling System
skipping to change at page 8, line 12 skipping to change at page 8, line 12
o Pseudo-open relays - a residential ISP that allows its customers o Pseudo-open relays - a residential ISP that allows its customers
to relay non-local domains through its infrastructure. to relay non-local domains through its infrastructure.
o Embedded devices - cable/DSL modems, firewalls, wireless access o Embedded devices - cable/DSL modems, firewalls, wireless access
points, printers that send email using hardcoded domains. points, printers that send email using hardcoded domains.
o Devices that send mail on behalf of a user - scanners, security o Devices that send mail on behalf of a user - scanners, security
cameras, alarms that send mail as their owner or a device user. cameras, alarms that send mail as their owner or a device user.
o Email service providers - ESPs that service customers who are o Email service providers - ESPs that service customers who are
using domains which publish a DMARC "reject" policy. using domains that publish a DMARC "reject" policy.
o Calendaring software - an invited member of an event modifies the o Calendaring software - an invited member of an event modifies the
event causing calendaring software to emit an update that claims event causing calendaring software to emit an update that claims
to come from the creator of the event. to come from the creator of the event.
3.1.2. Message Transfer Agents 3.1.2. Message Transfer Agents
MTAs relay a message until the message reaches a destination MDA. MTAs relay a message until the message reaches a destination MDA.
3.1.2.1. Message Encoding 3.1.2.1. Message Encoding
An MTA may modify the message encoding, for instance by converting An MTA may modify the message encoding, for instance by converting
8-bit MIME sections to quoted-printable 7-bit sections. This 8-bit MIME sections to quoted-printable 7-bit sections. This
modification is outside the scope of DKIM canonicalization and will modification is outside the scope of DKIM canonicalization and will
invalidate DKIM signatures that include message content. invalidate DKIM signatures that include message content.
An MTA may also re-encode the message without changing the encoding An MTA could also re-encode the message without changing the encoding
type, receiving a MIME-encoded message and producing a semantically type, receiving a MIME-encoded message and producing a semantically
and syntactically equivalent MIME body that is not identical to the and syntactically equivalent MIME body that is not identical to the
original. This is characteristic of systems that use some other original. This is characteristic of systems that use some other
message representation internally. message representation internally.
3.1.2.2. Header Standardization 3.1.2.2. Header Standardization
An MTA may rewrite headers to bring headers into compliance with An MTA may rewrite headers to bring them into compliance with
existing RFCs. For example, some common MTAs will correct existing RFCs. For example, some common MTAs will correct
comprehensible but non-compliant date formats to compliant ones. comprehensible but non-compliant date formats to compliant ones.
Header rewriting is outside the scope of DKIM canonicalization and Header rewriting is outside the scope of DKIM canonicalization and
will invalidate DKIM signatures. All downstream DMARC processing will invalidate DKIM signatures. All downstream DMARC processing
with be unable to utilize DKIM to yield Authenticated Identifiers due with be unable to utilize DKIM to yield Authenticated Identifiers due
to header rewriting. to header rewriting.
Providing solutions for issues relating to non RFC-compliant emails Providing solutions for issues relating to non RFC-compliant emails
is outside the scope of this document. is outside the scope of this document.
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Mediators forward messages through a re-posting process. Mediators Mediators forward messages through a re-posting process. Mediators
share some functionality with basic MTA relaying, but have greater share some functionality with basic MTA relaying, but have greater
flexibility in both addressing and content modifications. flexibility in both addressing and content modifications.
DMARC interoperability issues are common within the context of DMARC interoperability issues are common within the context of
Mediators, which are often used precisely for their ability to modify Mediators, which are often used precisely for their ability to modify
messages. messages.
The DMARC design does not cope with some Mediator functionality such The DMARC design does not cope with some Mediator functionality such
as content modifications that invalidate DKIM signatures and Mail as content modifications that invalidate DKIM signatures and
From rewriting to support SPF authentication of resent mail when the RFC5321.MailFrom rewriting to support SPF authentication of resent
new Recipient receives the message from the Mediator rather than the mail when the new Recipient receives the message from the Mediator
initial organization. rather than the initial organization.
3.2.1. Alias 3.2.1. Alias
An Alias is a simple re-addressing facility that provides one or more An Alias is a simple re-addressing facility that provides one or more
new Internet Mail addresses, rather than a single, internal one. A new Internet Mail addresses, rather than a single, internal one. A
message continues through the transfer service for delivery to one or message continues through the transfer service for delivery to one or
more alternative addresses. more alternative addresses.
Aliases can be implemented by mailbox-level forwarding (e.g. through Aliases can be implemented by mailbox-level forwarding (e.g. through
"dot-forwarding") or SIEVE-level forwarding (through the SIEVE "dot-forwarding") or SIEVE-level forwarding (through the SIEVE
'redirect' action) or other methods. When an Alias preserves message 'redirect' action) or other methods. When an Alias preserves message
content and does not make significant header changes, DKIM signatures content and does not make significant header changes, DKIM signatures
may remain valid. However, Aliases often extend the delivery path may remain valid. However, Aliases often extend the delivery path
outside of the scope covered by the originating ADMD's SPF record(s). outside of the scope covered by the originating ADMD's SPF record(s).
Examples of Aliasing include: Examples of Aliasing include:
o Forwarding email between freemail providers to try different o Forwarding email between free email (freemail) providers to try
interfaces while maintaining an original email address. different interfaces while maintaining an original email address;
o Consolidating many email addresses into a single account to o Consolidating many email addresses into a single account to
centralize processing. centralize processing;
o Services that provide "activity based", "role based" , "vanity" or o Services that provide "activity based", "role based" , "vanity" or
"temporary" email addresses such as universities and professional "temporary" email addresses such as universities and professional
associations. For instance professional or alumni institutions associations. For instance professional or alumni institutions
may offer their members an alias for the duration of their may offer their members an alias for the duration of their
membership but may not want to deal with the long term storage of membership but may not want to deal with the long term storage of
emails. emails.
In most cases, the aMSA providing Alias services has no In most cases, the aMSA providing Alias services has no
administrative relationship to the ADMD of the originator or the administrative relationship to the ADMD of the originator or the
skipping to change at page 11, line 22 skipping to change at page 11, line 22
reposts them to a list of subscribed members. The Mailing List reposts them to a list of subscribed members. The Mailing List
performs a task that can be viewed as an elaboration of the ReSender performs a task that can be viewed as an elaboration of the ReSender
actions. actions.
Mailing Lists share the same DMARC interoperability issues as Mailing Lists share the same DMARC interoperability issues as
ReSenders (Section 3.2.2), and very commonly modify headers or ReSenders (Section 3.2.2), and very commonly modify headers or
message content in ways that will cause DKIM to fail, including: message content in ways that will cause DKIM to fail, including:
o prepending the RFC5322.Subject header field with a tag, to allow o prepending the RFC5322.Subject header field with a tag, to allow
the recipient to easily identify the mailing list within a subject the recipient to easily identify the mailing list within a subject
line listing. line listing;
o adding a footer to the email body to contain administrative o adding a footer to the email body to contain administrative
instructions. instructions;
o removing some MIME-parts from the email or converting the message o removing some MIME-parts from the email or converting the message
to text only. to text only;
o PGP-encrypting or S/MIME encrypting the body with the receiver's o PGP-encrypting or S/MIME encrypting the body with the receiver's
key. key;
o enforcing community standards by rewriting banned words. o enforcing community standards by rewriting banned words;
o allowing moderators to add arbitrary commentary to messages. o allowing moderators to add arbitrary commentary to messages
(discussed in [RFC6377]).
Any such modifications would invalidate a DKIM signature. Any such modifications would invalidate a DKIM signature.
Header and content modifications are common for many mailing lists Header and content modifications are common for many mailing lists
and are often central to present mailing list functionality and and are often central to present mailing list functionality and
usage. Furthermore, MUAs have come to rely on mailing list message usage. Furthermore, MUAs have come to rely on mailing list message
modifications to present messages to end users in expected ways. modifications to present messages to end users in expected ways.
3.2.3.1. Mailing List Operational Effects 3.2.3.1. Mailing List Operational Effects
skipping to change at page 14, line 33 skipping to change at page 14, line 33
desired if the email in question is of a certain category of high desired if the email in question is of a certain category of high
value or high risk (security-related) transactional messages (dealing value or high risk (security-related) transactional messages (dealing
with financial transactions or medical records, for example). In with financial transactions or medical records, for example). In
these cases, mitigating the impact of DMARC due to indirect email these cases, mitigating the impact of DMARC due to indirect email
flows may not be desirable (counter-productive, or allowing for flows may not be desirable (counter-productive, or allowing for
abuse). abuse).
As a final note, mail systems are diverse and widely deployed. As a final note, mail systems are diverse and widely deployed.
Systems of various ages and capabilities are expected to preserve Systems of various ages and capabilities are expected to preserve
interoperability with the rest of the SMTP ecosystem. For instance, interoperability with the rest of the SMTP ecosystem. For instance,
Qmail is still used and the base code has not been updated since Qmail is still used, although the base code has not been updated
1998. Ezmlm, a once popular mailing list manager, is still deployed since 1998. ezmlm, a once popular mailing list manager, is still
and has not been updated since 1997, although a new version, Ezmlm- deployed but has not been updated since 1997, although a new version,
idx exists. Old versions of other open and closed source MTAs are ezmlm-idx exists. Old versions of other open and closed source MTAs
still commonly in operation. When dealing with aging or unsupported are still commonly in operation. When dealing with aging or
systems, some solutions may be time-consuming and/or disruptive to unsupported systems, some solutions may be time-consuming and/or
implement. disruptive to implement.
4.1. Mitigations in Current Use 4.1. Mitigations in Current Use
Because DMARC is already widely deployed, many operators already have Because DMARC is already widely deployed, many operators already have
mitigations in use. These mitigations vary in their effectiveness mitigations in use. These mitigations vary in their effectiveness
and side effects, but have the advantage that they are currently and side effects, but have the advantage that they are currently
available. available.
4.1.1. Mitigations for Senders 4.1.1. Mitigations for Senders
4.1.1.1. Identifier Alignment 4.1.1.1. Identifier Alignment
o MTAs handling multiple domains may choose to change o MTAs handling multiple domains may choose to change
RFC5321.MailFrom to align with RFC5322.From to improve SPF RFC5321.MailFrom to align with RFC5322.From to improve SPF
usability for DMARC. usability for DMARC.
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 non-
bounce messages. Dynamically adjusting the RFC5321.HELO based on delivery (also known as "bounce") messages (ref [RFC5321] section
the RFC5322.From may not be possible for some MTA software. 3.6.3). Dynamically adjusting the RFC5321.HELO based on the
RFC5322.From may not be possible for some MTA software.
o MTAs may choose to DKIM sign bounces with an aligned domain to 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 SPF Domain Owners to provide DKIM keys to use DKIM to avoid SPF
validation issues, given the requirement for DMARC alignment with validation issues, given the requirement for DMARC alignment with
the RFC5322.From header field. Managing DKIM keys with a third the RFC5322.From header field. Managing DKIM keys with a third
party has security risks which should be carefully managed. party has security risks that should be carefully managed (see
Methods involving CNAMEs and/or subdomains may alleviate some also [RFC6376] section 8). Methods involving CNAMEs and/or
risks. 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
skipping to change at page 17, line 26 skipping to change at page 17, line 26
content instead of modifying them. content instead of modifying them.
4.1.3.3. Mailing Lists 4.1.3.3. Mailing Lists
[RFC6377] provides some guidance on using DKIM with Mailing lists. [RFC6377] provides some guidance on using DKIM with Mailing lists.
The following mitigation techniques can be used to ease The following mitigation techniques can be used to ease
interoperability issues with DMARC and Mailing lists: interoperability issues with DMARC and Mailing lists:
o Configuring the Mailing List Manager (MLM) to alter the o Configuring the Mailing List Manager (MLM) to alter the
RFC5322.From header field to use the domain of the MLM is a RFC5322.From header field to use the domain of the MLM is a
mitigation policy which is now present in several different mitigation policy that is now present in several different Mailing
Mailing List software distributions. Since most list subscribers List software distributions. Since most list subscribers prefer
prefer to know the identity of the author of the original message, to know the identity of the author of the original message,
typically this information may be provided in the display name typically this information may be provided in the display name
part of the RFC5322.From header field. This display name needs to part of the RFC5322.From header field. This display name needs to
be carefully crafted as to not collide with the original display be carefully crafted as to not collide with the original display
name of the author, nor contain something that looks like an email name of the author, nor contain something that looks like an email
address or domain name. These modifications may to some extent address or domain name. These modifications may to some extent
defeat the purpose of DMARC itself. It may make it difficult to defeat the purpose of DMARC itself. It may make it difficult to
ensure that users of all email clients can easily reply to the ensure that users of all email clients can easily reply to the
author, the list, or all using the email client features provided author, the list, or all using the email client features provided
for that purpose. Use of RFC5322.Reply-To header field can for that purpose. Use of RFC5322.Reply-To header field can
alleviate this problem depending on whether the mailing list is alleviate this problem depending on whether the mailing list is
skipping to change at page 18, line 10 skipping to change at page 18, line 10
back to the original sender, or back to the original sender, or
3. "break" the address by modifying the domain to a non-existent 3. "break" the address by modifying the domain to a non-existent
domain (such as by adding a suffix like ".invalid".) domain (such as by adding a suffix like ".invalid".)
The later modification may create issues because it is an invalid The later modification may create issues because it is an invalid
domain name, and some MTAs may pay particular attention to the domain name, and some MTAs may pay particular attention to the
validity of email addresses in RFC5322.From and the reputation of validity of email addresses in RFC5322.From and the reputation of
the domains present there. the domains present there.
o Another mitigation policy is to configure the MLM to "wrap" the o Configuring the MLM to "wrap" the message in a MIME message/rfc822
message in a MIME message/rfc822 part and to send as the Mailing part and to send as the Mailing List email address. Many email
List email address. Many email clients (as of August 2015), clients (as of August 2015), especially mobile clients, have
especially mobile clients, have difficulty reading such messages difficulty reading such messages and this is not expected to
and this is not expected to change soon. change soon.
o Another mitigation policy, is to configure the MLM to not modify o Configuring the MLM to not modify the message so that the DKIM
the message so that the DKIM signature remains valid. Some signature remains valid. Some Mailing Lists are set up this way
Mailing Lists are set up this way and require few additional and require few additional changes to ensure the DKIM signature is
changes to ensure the DKIM signature is preserved. Moving lists preserved. Moving lists that currently modify mail to a policy
that currently modify mail to a policy like this, may be too much like this, may be too much of a change for the members of such
of a change for the members of such lists. lists.
o Another mitigation policy, is to reject posts or membership o Rejecting posts or membership requests from domains with a DMARC
requests from domains with a DMARC policy other than p=none. policy other than "p=none". However members or potential members
However members or potential members of such Mailing Lists may of such Mailing Lists may complain of unfair exclusion.
complain of unfair exclusion.
o To alleviate unsubscribes to the Mailing List due to the messages 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 bouncing because of DMARC, the MLM needs to not act on bounces due
to Message Authentication issues. [RFC3463] specifies Enhanced to Message Authentication issues. [RFC3463] specifies Enhanced
Mail System Status Codes which help differentiate between various Mail System Status Codes which help differentiate between various
bounces. Correctly interpreting Extended SMTP error messages is bounces. Correctly interpreting Extended SMTP error messages is
useful in this case. In particular, extended status codes are useful in this case. In particular, extended status codes are
defined in [RFC7372] and in DMARC [RFC7489]. defined in [RFC7372] and in DMARC [RFC7489].
All these techniques may provide some specific challenges to MUAs and All these techniques may provide some specific challenges to MUAs and
different operational usages for end users (like rewriting filters to different operational usages for end users (like rewriting filters to
sort emails in folders). There will be some time before all sort emails in folders). There will be some time before all
implications are understood and adjusted to. implications are understood and accommodated.
4.2. Proposed and In-Progress Mitigations 4.2. Proposed and In-Progress Mitigations
The following mitigations are based on Internet Drafts which have not The following mitigations are based on Internet Drafts which have not
yet received broad consensus. They are described here to offer yet received broad consensus. They are described here to offer
exploratory path for solutions. These solutions should not be used exploratory path for solutions. These solutions should not be used
in a production environment. in a production environment.
o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and
[I-D.kucherawy-dkim-delegate] provide ways to extend identifier [I-D.kucherawy-dkim-delegate] provide ways to extend identifier
alignment under the control of the domain owner. alignment under the control of the domain owner.
o DKIM with constrained transformations, o DKIM with constrained transformations,
[I-D.kucherawy-dkim-list-canon] is proposed to allow message [I-D.kucherawy-dkim-list-canon] is proposed to record a canonical
modification. list posting format for signing, so that typical MLM changes do
not invalidate signatures.
o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform] o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform]
is proposed to indicate what limited transformations were done to is proposed to indicate what limited transformations were done to
the message so that a receiver could reverse them and confirm the the message so that a receiver could reverse them and confirm the
validity of the orignal DKIM signature. validity of the orignal DKIM signature.
o [I-D.kucherawy-original-authres] is intended as a way to pass o [I-D.kucherawy-original-authres] is intended as a way to pass
along Original Authentication Results to "downstream" receivers. along Original Authentication Results to "downstream" receivers.
It is not widely implemented and relies on a trust relationship It is not widely implemented and relies on a trust relationship
between the forwarder and the other receivers. between the forwarder and the other receivers.
o [I-D.levine-dkim-conditional] could be used to have the sender add o [I-D.levine-dkim-conditional] could be used to have the sender add
a limited DKIM signature, that signs only a very limited set of a limited DKIM signature, that signs only a very limited set of
header fields and not the body of the message. This DKIM header fields and not the body of the message. If accompanied by
signature would come with the condition that a subsequent known suitable other DKIM signature(s) it may be possible to achieve
domain fully DKIM sign the message. For instance a Mailing List DMARC alignment while limiting the possibilities of replay attack.
could transform the message, add its DKIM signature and there
would be a valid DKIM signature aligned with the RFC5322.From that
would satisfy DMARC while limiting the possibilities of replay
attack.
o [I-D.andersen-arc] (and the accompanying usage recommendations o [I-D.andersen-arc] (and the accompanying usage recommendations
[I-D.jones-arc-usage]) provides a proposed mechanism to provide an [I-D.jones-arc-usage]) proposes a mechanism to provide an
authenticated channel for the initial received authentication authenticated channel for the initial received authentication
results to be conveyed through multiple ReSenders results to be conveyed through multiple ReSenders
("intermediaries" in the terminology used in the draft) to the ("intermediaries" in the terminology used in the draft) to the
ultimate receiving system. This information is proposed as the ultimate receiving system. This information is proposed as the
basis for improved local policy decisions by the receiver. basis for improved local policy decisions by the receiver.
4.2.1. Getting More Radical: Requiring New Communication Paths Between 4.2.1. Getting More Radical: Requiring New Communication Paths Between
MUAs MUAs
In practice a number of operators are using strict alignment mode in In practice a number of operators are using strict alignment mode in
skipping to change at page 20, line 17 skipping to change at page 20, line 17
This document contains no actions for IANA. [RFC Editor: Please This document contains no actions for IANA. [RFC Editor: Please
delete this section prior to publication.] delete this section prior to publication.]
6. Security Considerations 6. Security Considerations
This document is an analysis of DMARC's impact on indirect email This document is an analysis of DMARC's impact on indirect email
flows. It describes the possibility of accidental denial-of-service flows. It describes the possibility of accidental denial-of-service
that can be created by rejections of messages by DMARC-aware Mail that can be created by rejections of messages by DMARC-aware Mail
Receivers. Receivers.
In Section 4.1.1.1, it is discussed that DKIM key management with In Section 4.1.1.1, discusses the importance of appropriate DKIM key
third party email senders need to be done appropriately. management vis a vis third party email senders.
In Section 4.1.3.3, it is discussed that rewriting the RFC5322.From In Section 4.1.3.3, warns that rewriting the RFC5322.From header
header field and changing the domain name, should not be done with field and changing the domain name should not be done with any
any domain. domain.
7. Acknowledgments 7. Acknowledgments
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull,
Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the
IETF DMARC Working Group's wiki page listing all known IETF DMARC Working Group's wiki page listing all known
interoperability issues with DMARC and indirect email flows. interoperability issues with DMARC and indirect email flows.
Tim Draegen created the first draft of this document from these Tim Draegen created the first draft of this document from these
contributions and by hamfistedly mapping contributions into the contributions and by hamfistedly mapping contributions into the
 End of changes. 35 change blocks. 
83 lines changed or deleted 82 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/