DMARC Working Group F. Martin, Ed.
Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed.
Expires: August 2, 2015 Cisco Systems GmbH
T. Draegen, Ed.
Eudaemon
January 29, 2015
Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-00
Abstract
DMARC introduces a mechanism for expressing domain-level policies and
preferences for message validation, disposition, and reporting. The
DMARC mechanism can encounter interoperability issues when messages
originate from third party sources, are modified in transit, or are
forwarded enroute to their final destination. Collectively these
email flows are referred to as indirect email flows. This document
describes interoperability issues between DMARC and indirect email
flows. Possible methods for addressing interoperability issues are
presented.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Martin, et al. Expires August 2, 2015 [Page 1]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
(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 . . . . . . . . . . . . . . . . . . 3
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 4
2.3. Message Modification . . . . . . . . . . . . . . . . . . 5
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 5
3.1. Message Handling System . . . . . . . . . . . . . . . . . 5
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 5
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 6
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 6
3.1.2.2. Anti-spam . . . . . . . . . . . . . . . . . . . . 7
3.1.2.3. Email Address Internationalization . . . . . . . 7
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 7
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 10
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 10
4. Possible Solutions to Interoperability Issues . . . . . . . . 10
4.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 11
4.2. Message Modification . . . . . . . . . . . . . . . . . . 11
4.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 11
4.3.1. Original-Authentication-Results . . . . . . . . . . . 12
4.4. Message Handling Services . . . . . . . . . . . . . . . . 12
4.4.1. Message Transfer Agents . . . . . . . . . . . . . . . 12
4.4.1.1. Encoding . . . . . . . . . . . . . . . . . . . . 12
4.4.1.2. Filters . . . . . . . . . . . . . . . . . . . . . 12
4.4.1.3. Email Address Internationalization . . . . . . . 12
4.5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12
4.6. Getting More Radical: Requiring New Communication Paths
Between MUA and the Message Store . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Martin, et al. Expires August 2, 2015 [Page 2]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
DMARC [I-D.kucherawy-dmarc-base] introduces a mechanism for
expressing domain-level policies and preferences for message
validation, disposition, and reporting. DMARC is used to combat
exact-domain phishing, to gain visibility into email infrastructure,
and to provide email egress controls. Due to wide adoption, the
impact of DMARC-based email rejection policies on both direct and
indirect email flows can be significant.
The DMARC mechanism can encounter several different types of
interoperability issues due to message transformation or rerouting.
This is known collectively as indirect email flows. In some of these
cases, message content is modified as a result.
The next section describes interoperability issues between DMARC and
indirect email flows. These issues are first described in the
context of configuration behavior that DMARC requires from underlying
authentication technology, and then described as they appear in
context of the Internet Mail Architecture [RFC5598].
Lastly, possible methods for addressing interoperability issues are
presented. There are often multiple ways to address any given
interoperability issue. Whereas this document strives to be
comprehensive in its review, it should not be treated as complete.
1.1. Document Conventions
Notation regarding structured fields is taken from [RFC5598].
2. Causes of Interoperability Issues
What do we mean by "interoperability issues"? We say that DMARC
introduces interoperability issues or problems, when conformance to
the DMARC specification leads an implementation to reject a message
that is both compliant with the architecture as specified in
[RFC5598] and would have been viewed as legitimate in the eyes of the
intended recipient. This the secondary effects of behaviors caused
by that rejection. Therefore, we can already conclude that DMARC
poses no interoperability problems when messages properly validate
through its specified processes. The rest of this section,
therefore, delves into how legitimate messages may get rejected.
Martin, et al. Expires August 2, 2015 [Page 3]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
2.1. Identifier Alignment
A fundamental aspect of message source validation is understanding
how the originator of a message is validated. Each of the underlying
mechanisms that DMARC uses (DKIM [RFC6376] or SPF [RFC7208]) takes a
different approach. Therefore, the DMARC [I-D.kucherawy-dmarc-base]
mechanism attempts to predictably specify the domain of the
originator that will be used for its purposes (reporting/message
disposition). This step is referred to as Identifier Alignment.
DKIM provides a cryptographic means for a domain to be associated
with a particular message. However, the signing domain is not
required to be related to the domain contained in the 5322.From field
[RFC5322]. The DMARC identifier alignment process posits just such a
relationship. For an identifier to align in DKIM, the signing domain
must be part of the same organizational domain as the domain in the
5322.From field, and the signature must be valid.
In addition, DKIM allows for the possibility of multiple valid
signatures. The DMARC mechanism will process Authenticated
Identifiers that are based on DKIM signatures until an aligned
Authenticated Identifier is found (if any). However, operational
experience has shown that some implementations have difficulty
processing multiple signatures. The impact on DMARC processing is
clear: if an implementation cannot process multiple DKIM signatures
it may lead to perfectly valid messages being flagged as not
authentic.
SPF provides authenticated domain identifiers based on either the
5321.MailFrom [RFC5321] domain or, if the 5321.MailFrom address is
absent (as in the case of "bounces"), the domain found in the HELO/
EHLO SMTP command. More often than not operators have not put an SPF
record on domains found in the HELO/EHLO SMTP command and when
present, it could be difficult to change this domain to the domain in
the 5322.From, especially when several mail streams share the same
sending IP address.
2.2. Message Forwarding
Message forwarding is a generic concept encapsulating a variety of
behaviors. Section 3 describes forwarding behavior as it relates to
the components of the Internet Mail Architecture.
When a message has been transmitted through a forwarder, there will
be no such relationship. With SPF, the domain of the 5321.MailFrom
or 5321.HELO/EHLO must match that of the 5322.From. Because
forwarders generally do not modify the 5322.From, this test will
Martin, et al. Expires August 2, 2015 [Page 4]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
fail. Thus a DMARC implementation must rely on DKIM, if available,
in these cases.
2.3. Message Modification
Modification of email content invalidates most DKIM signatures.
While DKIM provides a length flag so that content can be appended
(See Section 8.2 of RFC6376 [RFC6376] for additional discussion), in
practice, particularly with MIME-encoded messages, a mailing list
processor will do more than append (See Section 5.3 of [RFC5598] for
details).
3. Internet Mail Architecture, DMARC, and Indirect Email Flows
This section describes components within the Internet Mail
Architecture [RFC5598] where interoperability issues between DMARC
and indirect email flows can be found.
3.1. Message Handling System
Section 4 of [RFC5598] describes six basic components that fulfill
the purpose of the Message Handling System (MHS):
o Message
o Message User Agent (MUA)
o Message Submission Agent (MSA)
o Message Transfer Agent (MTA)
o Message Delivery Agent (MDA)
o Message Store (MS)
Of these components MSA, MTA, and MDA are discussed in relation to
interoperability with DMARC.
A Mediator is a special class of MUA that is given special
consideration in this section due to the unique issues Mediators face
when attempting to interoperate with DMARC.
3.1.1. Message Submission Agents
An MSA accepts messages submitted by a Message User Agent (MUA) and
enforces the policies of the hosting ADministrative Management Domain
(ADMD) and the requirements of Internet standards.
Martin, et al. Expires August 2, 2015 [Page 5]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
MSAs are split into two sub-components:
o Author-focused MSA functions (aMSA)
o MHS-focused MSA functions (hMSA)
MSA interoperability issues with DMARC begin when an aMSA accepts a
message where the 5322.From header contains a domain that is outside
of the ADMD of the MSA. The ADMD will almost certainly not be
capable of sending email that yields authenticated domain identifiers
related to the domain found in the 5322.From header. Examples of
this issue include "forward-to-friend" functionality commonly found
on news/article websites or "send-as" functionality present on some
MUAs.
When an hMSA takes responsibility for transit of a message containing
a domain in the 5322.From header that is outside of the hMSA's ADMD,
the hMSA faces DMARC interoperability issues if the domain publishes
a DMARC policy of "quarantine" or "reject". These issues are marked
by an inherent difficulty in modifying the domain present in a
message's 5322.From header. Examples of this issue include:
o Pseudo-open relays - a residential ISP that allows its customers
to relay any domains through its infrastructure.
o Embedded devices - cable/dsl modems, firewalls, wireless access
points that send email using hardcoded domains.
o Email service providers - ESPs that service customers that are
using freemail services where the freemail service publishes a
DMARC "reject" policy.
o Calendaring software - an invited member of an event modifies the
event causing calendaring software to emit an update that appears
to come from the creator of the event.
3.1.2. Message Transfer Agents
MTAs relay a message until the message reaches a destination MDA.
3.1.2.1. Message Encoding
An MTA may change the message encoding. For instance it may convert
8bits mail sections to quoted-printable 7bits sections, or just
change the character set from US-ASCII to ISO-8859-4. Such
transformations invalidate any present DKIM signature.
Martin, et al. Expires August 2, 2015 [Page 6]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
3.1.2.2. Anti-spam
To keep its reputation, an MTA that transfers message, may block or
otherwise remove harmful content from messages that are likely to be
unwanted by the next MTA. Any such modifications would invalidate a
DKIM signature.
3.1.2.3. Email Address Internationalization
A DMARC interoperability issue arises in the context of Email Address
Internationalization [RFC6530]. [RFC6854] allows group syntax in the
5322.From header during the transition period to SMTPUTF8. In the
case where an EAI/SMTPUTF8-aware MTA relays a message to a non-aware
MTA, the EAI/SMTPUTF8-aware MTA may transform the 5322.From header of
the message to include group syntax that allows the non-aware MTA to
process the email.
This transformation modifies the content of the message and will
invalide any DKIM signatures and possibly remove the ability for the
DMARC mechanism to receive an authenticated domain identifier from a
DKIM module.
3.1.3. Message Delivery Agents
The MDA transfers a message from the MHS to a mailbox. Like the MSA,
the MDA consists of two sub-components:
o MHS-focused MDA functions (hMDA)
o Recipient-focused MDA functions (rMDA)
Both the hMDA and the rMDA can redirect a message to an alternative
address. DMARC interoperability issues related to redirecting of
messages are described in Section 3.2.
SIEVE [RFC5228] functionality often lives in the rMDA sub-component
and can cause DMARC interoperability issues. The SIEVE 'addheader'
and 'deleteheader' filtering actions can modify messages and
invalidate DKIM signatures, removing DKIM- supplied authenticated
domain identifiers as inputs to the DMARC mechanism.
3.2. Mediators
Descriptions of Mediators are largely imported from [RFC5598].
Mediators forward messages through a re-posting process. Mediators
share some functionality with basic MTA relaying, but have greater
flexibility in both addressing and content modifications.
Martin, et al. Expires August 2, 2015 [Page 7]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
DMARC interoperability issues are prevalent within the context of
Mediators, as Mediators represent a class of transformations that
mirror the concept of "indirect email flows".
3.2.1. Alias
An Alias is a simple re-addressing facility that provides one or more
new Internet Mail addresses, rather than a single, internal one. A
message continues through the transfer service for delivery to one or
more alternate addresses.
Aliases can be implemented by mailbox-level forwarding (e.g. through
"dot-forwarding") or SIEVE-level forwarding (through the SIEVE
'redirect' action). When an Alias preserves message content, DKIM
signatures may remain valid. However, Aliases extend the delivery
path beyond SPF's ability to grant authorization.
Examples of Aliasing include:
o Forwarding email between freemail providers to try different
interfaces while maintaining an original email address.
o Consolidating many email addresses into a single acccount to
centralize processing.
o Services that provides "activity based", "role based" , "vanity"
or "temporary" email addresses such as universities and
professional associations.
A fundamental challenge in dealing with workarounds involving Aliases
is that in many instances, the aMSA has no administrative
relationship to the ADMD of the alias. Another challenge is that the
underlying mechanisms upon which DMARC relies do not consider the
local-part of the addr-spec. While normally considered a perfectly
reasonable scaling feature, the underlying assumption is that Authors
will make use of aMSAs that are always authorized for a given domain.
For vanity domains, this assumption turns out to not hold.
3.2.2. ReSenders
ReSenders "splice" a message's addressing information to connect the
Author of the original message with the Recipient of the new message.
The new Recipient sees the message as being from the original Author,
even if the Mediator adds commentary.
ReSenders introduce DMARC interoperability issues as content
modification invalidates DKIM signatures. SPF's ability to grant
Martin, et al. Expires August 2, 2015 [Page 8]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
authorization via alignement is removed as the new Recipient receives
the message from the Mediator.
Without an ability to produce authenticated domain identifiers
relevant to the Author's 5322.From domain using either DKIM or SPF,
the new Recipient has almost no chance of successfully applying the
DMARC mechanism.
Examples of ReSenders include MUA-level forwarding by resending a
message to a new recipient or by forwarding a message "inline" to a
new recipient (this does not include forwarding a message "as an
attachment"). An additional example comes in the form of calendering
software that allows a meeting attendee (not the meeting organizer)
to modify the content of an invite causing the invitations to appear
to be reissued from the meeting organizer.
3.2.3. Mailing Lists
A Mailing List receives messages as an explicit addressee and then
re-posts them to a list of subscribed members. The Mailing List
performs a task that can be viewed as an elaboration of the ReSender.
Mailing Lists share the same DMARC interoperability issues as
ReSenders (Section 3.2.2), plus the following:
o Subscribed members may not receive email from members that post
using domains that publish a DMARC "p=reject" policy.
o Mailing Lists may interpret DMARC-related email rejection as an
inability to deliver email to the recipients that are checking and
enforcing DMARC policy. This processing may cause subscribed
members to be suspended or removed from the Mailing List.
3.2.4. Gateways
A Gateway performs the basic routing and transfer work of message
relaying, but it also is permitted to modify content, structure,
address, or attributes as needed to send the message into a messaging
environment that operates under different standards or potentially
incompatible policies.
Gateways share the same DMARC interoperability issues as ReSenders
(Section 3.2.2).
Gateways may share also the same DMARC interopreability issues as
MTAs (Section 3.1.2).
Martin, et al. Expires August 2, 2015 [Page 9]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
Gateway-level forwarding can introduce DMARC interoperability issues
if the Gateway is configured to rewrite the message to map between
recipient domains. For example, an acquisition may lead the
acquiring company to decide to decommission the acquired companies
domains by rewriting messages to use the domain of the acquiring
company.
3.2.5. Boundary Filters
To enforce security boundaries, organizations can subject messages to
analysis for conformance with its safety policies. A filter might
alter the content to render it safe, such as by removing content
deemed unacceptable.
Boundary Filters share the same DMARC interoperability issues as
ReSenders.
Examples of Boundary Filters include:
o Antispam services that remove or modify content.
o Any service that reformulates the 5322.body for any other reason.
o Secondary MX services. In this case, however, it is inappropriate
for a primary MX server to perform an SPF check against its own
secondaries. Rather, the secondary MX should perform this
function.
3.3. Combinations
The causes of indirect email flows can be combined. For example, a
university student may subscribe to a mailing list (using his
university email address) while this university email address is
configured to forward all emails to a freemail provider where a more
permanent email address for this student exists.
Within an organisation the message may passes through various MTAs
(Section 3.1.2) that performs each one a different function,
authentication, filtering, distribution,...
4. Possible Solutions to Interoperability Issues
Solutions to interoperability issues between DMARC and indirect email
flows vary from improving of underlying processors, such as proper
handling multiple DKIM signatures, to more radical approaches to the
messaging architecture. This section decribes possible ways to
address interoperability issues.
Martin, et al. Expires August 2, 2015 [Page 10]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
Through external knowledge it may be possible to determinine that the
DMARC mechanism cannot be applied to a particular message because
modification and/or forwarding is to be expected through the normal
course of operations for a given sender. This is known as an
"override".
4.1. Identifier Alignment
In the case of forwarders, identity alignment poses a substantial
concern. A receiving ADMD may track subscriptions to mailing lists,
so that different processing may be applied to those messages.
Various proposals have been submitted to provide either some form of
transitive trust between an email sender, a realy and an email
receiver, or to allow a modified version of DKIM to survive light
transformation to the message:
o DKIM conditional signatures, [I-D.levine-dkim-conditional]
o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and
[I-D.kucherawy-dkim-delegate]
o DKIM with light transformations, [I-D.kucherawy-dkim-list-canon]
4.2. Message Modification
Message modification invalidates DKIM signatures and complicates a
receiver's ability to generate authenticated domain identifiers from
a message. It is therefore important to review the MTAs
(Section 3.1.2) configuration to ensure no modification of the
message is done when simply forwarding the message. Furthermore
Filters should not add to or modify the body of the message, but
either rejecting the message or adding email headers to indicate the
result of the filter.
4.3. Message Forwarding
Forwarding messages without modification is referred to as
"transparent forwarding", and is a way to preserve the validity of
DKIM signatures.
The X-Original-From header is used in various contexts.
Note that Original-From is merely adding complexity to the 'who was
the author of this message' assessment, very possibly creating yet-
another security hole.
Martin, et al. Expires August 2, 2015 [Page 11]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
4.3.1. Original-Authentication-Results
Mentioned in early drafts [I-D.kucherawy-original-authres] as a way
to pass along Original Authentication Results to "downstream"
receivers.
4.4. Message Handling Services
4.4.1. Message Transfer Agents
4.4.1.1. Encoding
There is very little reason to modify the encoding of the message,
compatibility issues between international character sets are few
nowadays. No modification of the message should be done when simply
forwarding the message.
4.4.1.2. Filters
Filters should not add to or modify the body of the message, but
either should reject the message or add new email headers (not under
DKIM) to indicate the result of the filter.
4.4.1.3. Email Address Internationalization
The postmaster will choose the solution best for its users but really
to avoid DMARC not finding a single useable domain in the 5322.From,
the real solution is to upgrade your MTAs, if you want to do DMARC,
to support EAI (SMTPUTF8) so that the group syntax in the 5322.From
is not needed for interoperability issues during transition, and such
syntax be considered at least as suspicious when present.
4.5. Mediators
4.5.1. Mailing Lists
o One common mitigation policy is to configure the Mailing List
Manager (MLM) to alter the RFC5322.From field to use the domain of
the MLM. Since most list subscribers prefer to know the identity
of the author of the original message, typically this information
may be provided in the display name part of the RFC5322.From
field. This display name needs to be carefully crafted as to not
collide with the original display name of the author, nor contain
something that looks like an email address or domain name. These
modification may to some extent defeats the purpose of DMARC
itself. It may make it difficult to ensure that users of all
email clients can easily reply to author, list, or all using the
email client features provided for that purpose. Use of "Reply-
Martin, et al. Expires August 2, 2015 [Page 12]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
To" can alleviate this problem depending if the mailing list is
configured to reply-to-list, reply-to-author or reply-to-fixed-
address.
o Another common mitigation policy is to configure the MLM to "wrap"
the message in a MIME message/rfc822 part. This completely
bypasses the DMARC policy in clients that allow reading the part
as a message. Many email clients (as of August 2014) have
difficulty reading such messages.
o Finally a less common mitigation policy, is to configure the MLM
to not modify the message so that the DKIM signature remains
valid.
o To alleviate unsubscribes to the mailing list due to the messages
bouncing because of DMARC, the MLM needs to not act on bounces due
to Message Authentication issues. Correctly interpreting Extended
SMTP error messages is useful in this case.
All these techniques may provide some specific challenges in MUAs and
different operational usages for end users (like rewriting filters to
sort emails in folders). There will be some time before all
implications are understood and alleviated.
4.6. Getting More Radical: Requiring New Communication Paths Between
MUA and the Message Store
In practice a number of operators are using strict alignement mode in
DMARC in order to avoid receiving new and innovative forms of
unwanted and unauthentic mail through systems purporting to be
mailing list handlers. The receiving ADMD has no knowledge of which
lists the user has subscribed to and which they have not. One avenue
of exploration would be for the user to authorize mailing lists as
proxies for authentication, at which point the receiving ADMD would
be vesting some trust in the mailing list service. The creators of
DKIM foresaw precisely this possibility at the time by not tightly
binding any semantics to the 5322.From. Some experimental work has
taken place in this area, as mentioned above. Additional work might
examine a new communication path to the user to authorize third party
signatures.
5. IANA Considerations
No IANA considerations.
Martin, et al. Expires August 2, 2015 [Page 13]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
6. Security Considerations
No Security considerations.
7. Acknowledgments
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull,
Rolf E. Sonneveld, Tim Dragen and Franck Martin contributed to the
IETF DMARC Working Group's wiki page listing all known
interoperability issues with DMARC and indirect mail flows.
Tim Draegen created the first draft of this document from these
contributions and by carefully mapping contributions into the
language of [RFC5598].
8. References
8.1. Normative References
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 6530, February 2012.
[RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM)
Authorized Third-Party Signatures", RFC 6541, February
2012.
[RFC6854] Leiba, B., "Update to Internet Message Format to Allow
Group Syntax in the "From:" and "Sender:" Header Fields",
RFC 6854, March 2013.
Martin, et al. Expires August 2, 2015 [Page 14]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
April 2014.
8.2. Informative References
[I-D.kucherawy-dkim-delegate]
Kucherawy, M. and D. Crocker, "Delegating DKIM Signing
Authority", draft-kucherawy-dkim-delegate-01 (work in
progress), June 2014.
[I-D.kucherawy-dkim-list-canon]
Kucherawy, M., "A List-safe Canonicalization for
DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim-
list-canon-00 (work in progress), June 2014.
[I-D.kucherawy-dmarc-base]
Kucherawy, M. and E. Zwicky, "Domain-based Message
Authentication, Reporting and Conformance (DMARC)", draft-
kucherawy-dmarc-base-11 (work in progress), January 2015.
[I-D.kucherawy-original-authres]
Chew, M. and M. Kucherawy, "Original-Authentication-
Results Header Field", draft-kucherawy-original-authres-00
(work in progress), February 2012.
[I-D.levine-dkim-conditional]
Levine, J., "DKIM Conditional Signatures", draft-levine-
dkim-conditional-00 (work in progress), June 2014.
[I-D.otis-tpa-label]
Otis, D. and D. Black, "Third-Party Authorization Label",
draft-otis-tpa-label-00 (work in progress), May 2014.
Authors' Addresses
Franck Martin (editor)
LinkedIn
Mountain View, CA
USA
Email: fmartin@linkedin.com
Martin, et al. Expires August 2, 2015 [Page 15]
Internet-Draft DMARC Indirect Email Interop Issues January 2015
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)
Eudaemon
NC
USA
Email: tim@eudaemon.net
Martin, et al. Expires August 2, 2015 [Page 16]
