draft-ietf-dmarc-interoperability-13.txt   draft-ietf-dmarc-interoperability-14.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: June 10, 2016 Cisco Systems GmbH Expires: July 21, 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
December 8, 2015 January 18, 2016
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-13 draft-ietf-dmarc-interoperability-14
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 June 10, 2016. This Internet-Draft will expire on July 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 4 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5 2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5
2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5 2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.1.3. Multiple RFC5322.from Addresses . . . . . . . . . . . 6
2.3. Message Modification . . . . . . . . . . . . . . . . . . 6 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6
2.3. Message Modification . . . . . . . . . . . . . . . . . . 7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7
3.1. Message Handling System . . . . . . . . . . . . . . . . . 7 3.1. Message Handling System . . . . . . . . . . . . . . . . . 7
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9
3.1.2.2. Header Standardization . . . . . . . . . . . . . 9 3.1.2.2. Header Standardization . . . . . . . . . . . . . 9
3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1. Mailing List Operational Effects . . . . . . . . 12 3.2.3.1. Mailing List Operational Effects . . . . . . . . 12
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14
4. Possible Mitigations of Interoperability Issues . . . . . . . 14 4. Possible Mitigations of Interoperability Issues . . . . . . . 14
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15
4.1.1.2. Message Modification . . . . . . . . . . . . . . 16 4.1.1.2. Message Modification . . . . . . . . . . . . . . 16
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17
4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 17 4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 17
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 22
A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 22
A.2. Bounce message . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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.
At the time of the writing of this document, the DMARC base At the time of the writing of this document, the DMARC base
skipping to change at page 4, line 31 skipping to change at page 4, line 34
passes standard DMARC validation do not have any interoperability passes standard DMARC validation do not have any interoperability
issues. issues.
Email messages that do not conform to IETF email specifications but Email messages that do not conform to IETF 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
Note to operators and administrators: The identifiers which are used
by DKIM and SPF are technical components of the transport process for
SMTP. They may or may not, as described below, bear a meaningful
relationship to the content or source of the message itself. This
"relationship by proximity" can be a point of confusion for non-
technical end users, either recipients or senders.
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] specification refers to
domains that are validated by DKIM or SPF as Authenticated source domains that are validated by DKIM or SPF as "Authenticated
Identifiers. DMARC requires an Authenticated Identifier to be Identifiers". To be used by DMARC an "Authenticated Identifier" must
related to the domain found in the message's RFC5322.from header also be related to the domain found in the message's RFC5322.from
field [RFC5322]. This relationship is referred to as Identifier header field [RFC5322]. This relationship between an Authenticated
Alignment. Identifier's domain and the domain of the RFC5322.from is referred to
as "Identifier Alignment".
DMARC allows for Identifier Alignment to be achieved in two different DMARC allows for Identifier Alignment to be determined in two
modes: strict and relaxed. Strict mode requires an exact match of different modes: strict and relaxed. Strict mode requires an exact
either of the Authenticated Identifiers to the message's RFC5322.from match between the domain of any of the Authenticated Identifiers and
header field [RFC5322]. Relaxed mode allows for Identifier Alignment the message's RFC5322.from header field [RFC5322]. Relaxed mode
if Authenticated Identifiers and the message's RFC5322.from header allows for Identifier Alignment if Authenticated Identifiers and the
field [RFC5322] share the same Organizational Domain. In general, message's RFC5322.from header field [RFC5322] share the same
interoperability issues between strict and relaxed modes are the Organizational Domain. In general, DMARC interoperability issues are
same, with strict mode constraining the application of possible the same for both strict and relaxed alignment, but strict alignment
solutions. The mitigations described in this document generally constrains the possible solutions because of the more rigorous
require a relaxed mode of Identifier Alignment. matching requirement. The mitigations described in this document
generally require the relaxed mode of Identifier Alignment.
2.1.1. DKIM Identifier(s) 2.1.1. DKIM Identifier(s)
DKIM provides a cryptographic means for one or more domain identifier DKIM provides a cryptographic means for one or more domain identifier
to be associated with a particular message. As a standalone to be associated with a particular message. As a standalone
technology DKIM identifiers are not required to be relevant to the technology DKIM identifiers are not required to be related to the
content of a message. However, for a DKIM identifier to align in source of the message's content. However, for a DKIM identifier to
DMARC, the signing domain of a valid signature must be part of the align in DMARC, the signing domain of a valid signature must be part
same Organizational Domain as the domain in the RFC5322.from header of the same Organizational Domain as the domain in the RFC5322.from
field [RFC5322]. header field [RFC5322].
In addition, DKIM allows for the possibility of multiple valid In addition, DKIM allows for the possibility of multiple valid
signatures. The DMARC mechanism will process Authenticated signatures. The DMARC mechanism will process Authenticated
Identifiers that are based on DKIM signatures until an aligned Identifiers that are based on DKIM signatures until an aligned
Authenticated Identifier is found (if any). However, operational Authenticated Identifier is found (if any). However, operational
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. Implementations that cannot process
clear: implementations that cannot process multiple DKIM signatures multiple DKIM signatures may incorrectly flag messages as "not
may incorrectly flag messages as "failing DMARC" and erroneously passing" (DMARC alignment) and erroneously apply DMARC-based policy
apply DMARC based policy to otherwise conforming messages. to otherwise conforming messages.
2.1.2. SPF Identifier(s) 2.1.2. SPF Identifier(s)
The SPF specification [RFC7208] defines two Authenticated Identifiers The SPF specification [RFC7208] defines two Authenticated Identifiers
for each message. These identifiers derive from: for each message. These identifiers derive from:
a. the RFC5321.mailfrom [RFC5321] domain, and a. the RFC5321.mailfrom [RFC5321] domain, and
b. the RFC5321.HELO/EHLO SMTP domain. b. the RFC5321.HELO/EHLO SMTP domain.
In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
defined to be based on RFC5321.mailfrom unless that value is absent defined to be based on RFC5321.mailfrom unless that value is absent
(as in the case of "bounce" messages) in which case, the second (as in the case of "bounce" messages) in which case, the second
(RFC5321.HELO/EHLO) identifier value is used. This "fallback" (RFC5321.HELO/EHLO) identifier value is used. This "fallback"
definition has occasionally been misunderstood by senders since definition has occasionally been misunderstood by operators of MTA
"bounce" messages are often an "automatic" feature of MTA software. systems since "bounce" messages are often an "automatic" feature of
MTA software. Some MTA software does not provide the ability to
apply a DKIM signature to such bounce messages.
See Appendix A for an example treatment of this scenario.
For the purposes of DMARC validation/alignment, the hybrid For the purposes of DMARC validation/alignment, the hybrid
RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only
if, it is aligned with the RFC5322.from [RFC5322] domain. The if, it is aligned with the RFC5322.from [RFC5322] domain. The
alignment of the validated domain is determined based on the DMARC alignment of the validated domain is determined based on the DMARC
record's "strict" or "relaxed" designation as described above for the record's "strict" or "relaxed" designation as described above for the
DKIM identifiers and in [RFC7489]. DKIM identifiers and in [RFC7489].
2.1.3. Multiple RFC5322.from Addresses
[RFC5322] permits only one From header field, but it may contain
multiple mailboxes. Since this is an extremely rare usage, DMARC
specifies that the handling of this situation is implementation
dependent.
Because the presence of multiple domains can be used by an attacker
(an attacker could add their domain to the RFC5322.from field,
provide arbitrary new content, and sign the message) the DMARC
specification recommends that the strictest policy be applied to such
messages (section 6.6.1 [RFC7489]).
2.2. Message Forwarding 2.2. Message Forwarding
Section 3 describes forwarding behavior as it relates to the Section 3 describes forwarding behavior as it relates to the
components of the Internet Mail Architecture. 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
RFC7208.MAILFROM must be in alignment with the RFC5322.from header RFC7208.MAILFROM must be in alignment with the RFC5322.from header
field. Forwarding introduces specific issues to the availability of field. Forwarding introduces specific issues to the availability of
skipping to change at page 22, line 17 skipping to change at page 22, line 41
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
Authors' Addresses Appendix A. Appendix A - Example SPF Bounce
A.1. Initial Message
Here is the message as it exits the Origin MTA (segv.d1.example):
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Hey gang,
This is a test message.
--J.
A.2. Bounce message
When dmarc.org bounces the message without a DKIM signature, it
specifies the HELO/EHLO domain as dmarc.org.local which has no SPF
record. dmarc.org has a reject policy in place for such non-passing
cases. Since there is no DKIM signature on the bounce message, the
failed SPF lookup results in a dmarc=fail and d1.example could be
expected to discard the bounce message itself:
Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [10.255.0.1])
by mx.d1.example with ESMTPS id Lkm25302jJR;5
for <jqd@d1.example>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example;
spf=none (d1.example: dmarc.org.local does not designate
permitted sender hosts) smtp.mail=;
dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
MIME-Version: 1.0
Return-Path: <>
Received: by 10.10.10.131 with SMTP id u67mr102828634qge.33; Thu,
14 Jan 2015 15:00:24 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
To: jqd@d1.example
Subject: Delivery Status Notification (Failure)
Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
Date: Thu, 14 Jan 2016 23:00:24 +0000
Content-Type: text/plain; charset=UTF-8
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
no-recipient@dmarc.org
Technical details of permanent failure:
Your message was rejected by the server for the recipient domain
dmarc.org by mail.dmarc.org. [10.255.0.1].
The error that the other server returned was:
550 5.1.1 <no-recipient@dmarc.org>... User unknown
----- Original message -----
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Hey gang,
This is a test message.
--J.
Authors' Addresses
Franck Martin (editor) Franck Martin (editor)
LinkedIn LinkedIn
Mountain View, CA Mountain View, CA
USA USA
Email: fmartin@linkedin.com Email: fmartin@linkedin.com
Eliot Lear (editor) Eliot Lear (editor)
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
 End of changes. 23 change blocks. 
50 lines changed or deleted 176 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/