draft-ietf-dmarc-interoperability-05.txt   draft-ietf-dmarc-interoperability-06.txt 
DMARC F. Martin, Ed. DMARC F. Martin, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed. Intended status: Informational E. Lear, Ed.
Expires: February 18, 2016 Cisco Systems GmbH Expires: February 29, 2016 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
dmarcian, inc. dmarcian, inc.
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
K. Andersen, Ed. K. Andersen, Ed.
LinkedIn LinkedIn
August 17, 2015 August 28, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-05 draft-ietf-dmarc-interoperability-06
Abstract Abstract
DMARC introduces a mechanism for expressing domain-level policies and DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting. preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain messages do not flow directly from the author's administrative domain
to the final recipients. Collectively these email flows are referred to the final recipients. Collectively these email flows are referred
to as indirect email flows. This document describes interoperability to as indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for issues between DMARC and indirect email flows. Possible methods for
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2016. This Internet-Draft will expire on February 29, 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 2, line 29 skipping to change at page 2, line 29
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.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5
2.3. Message Modification . . . . . . . . . . . . . . . . . . 6 2.3. Message Modification . . . . . . . . . . . . . . . . . . 6
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6
3.1. Message Handling System . . . . . . . . . . . . . . . . . 7 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8
3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 9
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1. Mailing List Operational Effects . . . . . . . . 11 3.2.3.1. Mailing List Operational Effects . . . . . . . . 11
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13
4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 13
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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
specification is published as an Informational RFC and has seen specification is published as an Informational RFC and has seen
significant deployment within the email community. significant deployment within the email community.
Cases in which email does not flow directly from the author's Cases in which email does not flow directly from the author's
administrative domain to the recipient's domain(s) are collectively administrative domain to the recipient's domain(s) are collectively
referred to in this document as indirect email flows. Due to referred to in this document as indirect email flows. Due to
existing and increasing adoption of DMARC, the impact of DMARC-based existing and increasing adoption of DMARC, the impact of DMARC-based
email rejection policies on email flows can be significant for a email rejection policies on indirect email flows can be significant
select subset of general email traffic. for a select subset of general email traffic.
Several known causes of interoperability issues are presented, Several known causes of interoperability issues are presented,
followed by a description of components within the Internet Mail followed by a description of components within the Internet Mail
Architecture [RFC5598] where interoperability issues can arise. Architecture [RFC5598] where interoperability issues can arise.
Finally, known and possible methods for addressing interoperability Finally, known and possible methods for addressing interoperability
issues are presented. There are often multiple ways to address any issues are presented. There are often multiple ways to address any
given interoperability issue. While this document strives to be given interoperability issue. While this document strives to be
comprehensive in its review, it should not be treated as complete. comprehensive in its review, it should not be treated as complete.
Also, some practices which are in use at the time of this document Also, some practices which are in use at the time of this document
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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. The impact on DMARC processing is
clear: implementations that cannot process multiple DKIM signatures clear: implementations that cannot process multiple DKIM signatures
may incorrectly flag messages as "failing DMARC" and erroneously may incorrectly flag messages as "failing DMARC" and erroneously
apply DMARC based policy to otherwise conforming messages. apply DMARC based policy to otherwise conforming messages.
SPF can provide two Authenticated Identifiers. The first one is the SPF can provide two Authenticated Identifiers. The DMARC relevant
RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM
one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom [RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the
[RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as RFC5321.MailFrom address is absent (as in the case of "bounce"
in the case of "bounce" messages, on the domain found in the HELO/ messages, on the domain found in the RFC5321.HELO/EHLO SMTP command.
EHLO SMTP command. DMARC uses only the SPF results for the The SPF validated domain in RFC7208.MAILFROM must be part of the same
RFC7208.MAILFROM identifier for alignment (this is often true for Organizational Domain as the domain in the RFC5322.From header field
local policies outside of DMARC as well). The SPF validated domain to be aligned. It is important to note that even when an SPF record
in RFC7208.MAILFROM must be part of the same Organizational Domain as exists for the domain in RFC5322.From, SPF will not authenticate it
the domain in the RFC5322.From header field to be aligned. It is unless it is also the domain which the SPF analysis has checked.
important to note that even when an SPF record exists for the domain Also note that RFC7208.MAILFROM definition is different from
in RFC5322.From, SPF will not authenticate it unless it is also the RFC5321.MailFrom [RFC5321] definition.
domain which the SPF analysis has checked. Also note that
RFC7208.MAILFROM definition is different from RFC5321.MailFrom
[RFC5321] definition. The RFC7208.MAILFROM definition has not
changed from the RFC4408.MAILFROM [RFC4408] definition, the earlier
version of the SPF specification, however, not all implementations
have updated to the [RFC7208] algorithm which can lead to unexpected
results.
2.2. Message Forwarding 2.2. Message Forwarding
Message forwarding is a generic concept encapsulating a variety of Message forwarding is a generic concept encapsulating a variety of
behaviors. Section 3 describes forwarding behavior as it relates to behaviors. Section 3 describes forwarding behavior as it relates to
the components of the Internet Mail Architecture. the components of the Internet Mail Architecture.
All forwarding behavior involves the retransmission of email. As All forwarding behavior involves the retransmission of email. As
discussed above, in order for SPF to yield an Authenticated discussed above, in order for SPF to yield an Authenticated
Identifier that is pertinent to DMARC, the domain of the Identifier that is pertinent to DMARC, the domain of the
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
SPF-based Authenticated Identifiers: SPF-based Authenticated Identifiers:
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 may 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 of the
RFC5322.From header field. SPF may pass but Identifier Alignment RFC5322.From header field. SPF may pass but Identifier Alignment
with the RFC5322.From header field fails. with the RFC5322.From header field fails.
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
skipping to change at page 6, line 35 skipping to change at page 6, line 28
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). considerations), therefore, this method is only here mentionned for
completeness.
DKIM describes two canonicalizations for use when preparing headers DKIM describes two canonicalizations for use when preparing headers
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 folding) that
maintain the integrity of the content of the email. However, the maintain the integrity of the content of the email. However, the
relaxed canonicalization is more computationally intensive and may relaxed canonicalization is more computationally intensive and may
not have been preferred in the early deployment of DKIM, leaving some not have been preferred in the early deployment of DKIM, leaving some
deployments using the less forgiving "simple" canonicalization. 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 checkers which
have problems evaluating relaxed canonicalization correctly. have problems evaluating relaxed canonicalization correctly.
skipping to change at page 9, line 48 skipping to change at page 9, line 45
See [RFC5598] for a complete definition of Mediators. See [RFC5598] for a complete definition of Mediators.
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
as content modifications that invalidate DKIM signatures and Mail
From rewriting to support SPF authentication of resent mail when the
new Recipient receives the message from the Mediator 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
skipping to change at page 10, line 41 skipping to change at page 10, line 46
final recipient, so solutions to Alias-related DMARC failure should final recipient, so solutions to Alias-related DMARC failure should
not assume such a relationship. not assume such a relationship.
3.2.2. ReSenders 3.2.2. ReSenders
ReSenders "splice" a message's addressing information to connect the ReSenders "splice" a message's addressing information to connect the
Author of the original message with the Recipient(s) of the new Author of the original message with the Recipient(s) of the new
message. The new Recipient sees the message as being from the message. The new Recipient sees the message as being from the
original Author, even if the Mediator adds commentary. original Author, even if the Mediator adds commentary.
ReSenders introduce DMARC interoperability issues as content
modification invalidates DKIM signatures. SPF's ability to grant
authorization via alignment is removed as the new Recipient receives
the message from the Mediator rather than the initial organization.
Without Authenticated Identifiers aligned with the Author's Without Authenticated Identifiers aligned with the Author's
RFC5322.From header field domain, the new Recipient has no way to RFC5322.From header field domain, the new Recipient has no way to
achieve a passing DMARC evaluation. achieve a passing DMARC evaluation.
Examples of ReSenders include MUA-level forwarding by resending a Examples of ReSenders include MUA-level forwarding by resending a
message to a new recipient or by forwarding a message "inline" to 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 new recipient (this does not include forwarding a message "as an
attachment"). An additional example comes in the form of calendaring attachment"). An additional example comes in the form of calendaring
software that allows a meeting attendee (not the meeting organizer) software that allows a meeting attendee (not the meeting organizer)
to modify the content of an invite generating new invitations that to modify the content of an invite generating new invitations that
skipping to change at page 15, line 19 skipping to change at page 15, line 19
o MTAs handling multiple domains may also choose to align o MTAs handling multiple domains may also choose to align
RFC5321.HELO/EHLO to RFC5322.From, particularly when sending RFC5321.HELO/EHLO to RFC5322.From, particularly when sending
bounce messages. Dynamically adjusting the RFC5321.HELO based on bounce messages. Dynamically adjusting the RFC5321.HELO based on
the RFC5322.From may not be possible for some MTA software. the RFC5322.From may not be possible for some MTA software.
o MTAs may choose to DKIM sign bounces with an aligned domain to o MTAs may choose to DKIM sign bounces with an aligned domain to
allow DKIM-based DMARC pass. allow DKIM-based DMARC pass.
o MTAs sending email on behalf of multiple domains may require o MTAs sending email on behalf of multiple domains may require
Domain Owners to provide DKIM keys to use DKIM to avoid SPF Domain Owners to provide DKIM keys to use DKIM to avoid DMARC
alignment issues. Managing DKIM keys with a third party has alignment issues with SPF. Managing DKIM keys with a third party
security risks which should be carefully managed. has security risks which should be carefully managed. Methods
involving CNAMEs and/or subdomains may alleviate some risks.
o Senders who are sending on behalf of users in other Administrative o Senders who are sending on behalf of users in other Administrative
Domains may choose to use an RFC5322.From under the sender's Domains may choose to use an RFC5322.From under the sender's
control. The new From can be either a forwarding address in a control. The new From can be either a forwarding address in a
domain controlled by the Sender, or a placeholder address, with domain controlled by the Sender, or a placeholder address, with
the original user's address in a RFC5322.Reply-to header field. the original user's address in a RFC5322.Reply-to header field.
However, performing this modification may cause the recipient's However, performing this modification may cause the recipient's
MUA to deviate from customary behavior. MUA to deviate from customary behavior.
o Senders can use domains with distinct DMARC policies for email o Senders can use domains with distinct DMARC policies for email
skipping to change at page 19, line 47 skipping to change at page 19, line 47
5. IANA Considerations 5. IANA Considerations
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. However, it introduces no new security issues to Internet Receivers.
messaging.
In Section 4.1.1.1, it is discussed that DKIM key management with
third party email senders need to be done appropriately.
In Section 4.1.3.3, it is discussed that rewriting the RFC5322.From
header field and changing the domain name, should not be done with
any 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
skipping to change at page 20, line 27 skipping to change at page 20, line 31
8.1. Normative References 8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003. 3463, January 2003.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1", RFC
4408, April 2006.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
 End of changes. 15 change blocks. 
43 lines changed or deleted 41 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/