draft-ietf-sieve-refuse-reject-06.txt   draft-ietf-sieve-refuse-reject-07.txt 
Sieve Working Group Aaron Stone, Ed. Sieve Working Group A. Stone, Ed.
Internet-Draft Hydric Acid Internet-Draft Hydric Acid
Updates: 3028 (if approved) Updates: 3028 (if approved)
Intended status: Standards Track December 14, 2007 Intended status: Standards Track May 26, 2008
Expires: June 5, 2008 Expires: November 27, 2008
Sieve Email Filtering: Extensions for Rejecting Messages Sieve Email Filtering: Reject and Extended Reject Extensions
draft-ietf-sieve-refuse-reject-06 draft-ietf-sieve-refuse-reject-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 5, 2008. This Internet-Draft will expire on November 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo updates the definition of the Sieve mail filtering language This memo updates the definition of the Sieve mail filtering language
"reject" extension, originally defined in RFC 3028. "reject" extension, originally defined in RFC 3028.
A "Joe-job" is a spam run forged to appear as though it came from an A "Joe-job" is a spam run forged to appear as though it came from an
innocent party, who is then generally flooded by automated bounces, innocent party, who is then generally flooded by automated bounces,
Message Disposition Notifications (MDNs), and personal messages with Message Disposition Notifications (MDNs), and personal messages with
complaints. The original Sieve "reject" action defined in RFC 3028 complaints. The original Sieve "reject" action defined in RFC 3028
required use of MDNs for rejecting messages, thus contributing to the required use of MDNs for rejecting messages, thus contributing to the
flood of Joe-job spam to victims of Joe-jobs. flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow This memo updates the definition of the "reject" action to allow
messages to be refused during the SMTP transaction, and defines the messages to be refused during the SMTP transaction, and defines the
"ereject" action to require messages to be refused during the SMTP "ereject" action to require messages to be refused during the SMTP
transaction. transaction, if possible.
The "ereject" action is intended to replace the "reject" action The "ereject" action is intended to replace the "reject" action
wherever possible. wherever possible.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Sieve 'reject' and 'ereject' Extentions . . . . . . . . . . . 3 2. Sieve 'reject' and 'ereject' Extentions . . . . . . . . . . . 3
2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Rejecting a message at the SMTP/LMTP protocol level . 4 2.1.1. Rejecting a message at the SMTP/LMTP protocol level . 4
2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 4 2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5
2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Rejecting a message by sending an MDN . . . . . . . . 6 2.2.1. Rejecting a message by sending an MDN . . . . . . . . 6
2.3. Compatibility with other actions . . . . . . . . . . . . . 7 2.3. Silent upgrade from reject to ereject . . . . . . . . . . 7
2.4. Details of protocol level refusal . . . . . . . . . . . . 8 2.4. Compatibility with other actions . . . . . . . . . . . . . 7
3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 9 2.5. Details of protocol level refusal . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. reject extension registration . . . . . . . . . . . . . . 10 5.1. reject extension registration . . . . . . . . . . . . . . 10
5.2. ereject extension registration . . . . . . . . . . . . . . 10 5.2. ereject extension registration . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The Sieve mail filtering language [SIEVEBIS], as originally defined The Sieve mail filtering language [SIEVEBIS], as originally defined
in RFC 3028 [SIEVE], specified that the "reject" action shall discard in RFC 3028 [SIEVE], specified that the "reject" action shall discard
a message and send a Message Disposition Notification [MDN] to the a message and send a Message Disposition Notification [MDN] to the
envelope sender along with an explanatory message. envelope sender along with an explanatory message. RFC 5228
[SIEVEBIS] does not define any reject action, hence the purpose of
this document.
This document updates the definition of the "reject" action to permit This document updates the definition of the "reject" action to permit
refusal of the message during the SMTP transaction, if possible, and refusal of the message during the SMTP transaction, if possible, and
defines a new "ereject" action to require refusal of the message defines a new "ereject" action to require refusal of the message
during the SMTP transaction. during the SMTP transaction, if possible.
Implementations are further encouraged to use spam-detection systems Implementations are further encouraged to use spam-detection systems
to determine the level of risk associated with sending an MDN, and to determine the level of risk associated with sending an MDN, and
this document allows implementations to silently drop the MDN if the this document allows implementations to silently drop the MDN if the
rejected message is deemed to be likely spam. rejected message is deemed to be likely spam.
Further discussion highlighting the risks of generating MDNs and the Further discussion highlighting the risks of generating MDNs and the
benefits of protocol-level refusal can be found in [Joe-DoS]. benefits of protocol-level refusal can be found in [Joe-DoS].
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
Conventions for notations are as in RFC 3028 [SIEVE] Section 1.1. Conventions for notations are as in RFC 3028 [SIEVE] Section 1.1.
This document does not attempt to define spam or how it should be This document does not attempt to define spam or how it should be
identified, nor to define an email virus or how it should be identified, nor to define an email virus or how it should be
detected. Implementations are advised to follow best practices and detected. Implementors are advised to follow best practices and keep
keep abreast of current research in these fields. abreast of current research in these fields.
2. Sieve 'reject' and 'ereject' Extentions 2. Sieve 'reject' and 'ereject' Extentions
2.1. Action ereject 2.1. Action ereject
Usage: ereject <reason: string> Usage: ereject <reason: string>
Sieve implementations that implement the "ereject" action must use Sieve implementations that implement the "ereject" action must use
the "ereject" capability string. the "ereject" capability string.
skipping to change at page 4, line 18 skipping to change at page 4, line 20
1. Refuse message delivery by sending a 5XX response code over SMTP 1. Refuse message delivery by sending a 5XX response code over SMTP
[SMTP] or LMTP [LMTP]. See Section 2.1.1 for more details. [SMTP] or LMTP [LMTP]. See Section 2.1.1 for more details.
2. Discard the message if a return-path verification clearly 2. Discard the message if a return-path verification clearly
indicates that the message has a forged return-path. indicates that the message has a forged return-path.
3. Send a non-delivery report to the envelope sender ([REPORT] 3. Send a non-delivery report to the envelope sender ([REPORT]
[DSN]). See Section 2.1.2 for more details. [DSN]). See Section 2.1.2 for more details.
The ereject action MUST NOT be available in environments that do not The ereject action MUST NOT be available in environments that do not
support protocol level rejection, e.g. an MUA. support protocol level rejection, e.g. an MUA, and MUST be available
in all other environments that support the reject action.
Example:
require ["ereject"];
if address "from" "someone@example.com" {
ereject "I no longer accept mail from this address";
}
2.1.1. Rejecting a message at the SMTP/LMTP protocol level 2.1.1. Rejecting a message at the SMTP/LMTP protocol level
Sieve implementations that are able to reject messages at the SMTP/ Sieve implementations that are able to reject messages at the SMTP/
LMTP level MUST do so and SHOULD use the 550 response code. Note LMTP level MUST do so and SHOULD use the 550 response code. Note
that if a message is arriving over SMTP and has multiple recipients, that if a message is arriving over SMTP and has multiple recipients,
some of whom have accepted the message, Section 2.1.2 defines how to some of whom have accepted the message, Section 2.1.2 defines how to
reject such a message. reject such a message.
Note that SMTP [SMTP] does not allow non-ASCII characters in the SMTP Note that SMTP [SMTP] does not allow non-ASCII characters in the SMTP
skipping to change at page 4, line 41 skipping to change at page 4, line 51
client and the server use an SMTP extension that allows for client and the server use an SMTP extension that allows for
transmission of non-ASCII reply text. (One example of such an SMTP transmission of non-ASCII reply text. (One example of such an SMTP
extension is described in [UTF8-RESP].) In the absence of such an extension is described in [UTF8-RESP].) In the absence of such an
SMTP extension, the Sieve engine MUST replace any reason string being SMTP extension, the Sieve engine MUST replace any reason string being
sent at the protocol level and containing non-ASCII characters with sent at the protocol level and containing non-ASCII characters with
an implementation-defined ASCII-only string. an implementation-defined ASCII-only string.
Users who don't like this behavior should consider using the "reject" Users who don't like this behavior should consider using the "reject"
action described in Section 2.2, if available. action described in Section 2.2, if available.
See Section 2.4 for the detailed instructions about performing See Section 2.5 for the detailed instructions about performing
protocol level rejection. protocol level rejection.
2.1.2. Rejecting a message by sending a DSN 2.1.2. Rejecting a message by sending a DSN
An implementation may receive a message via SMTP that has more than An implementation may receive a message via SMTP that has more than
one RCPT TO that has been accepted by the server, and at least one one RCPT TO that has been accepted by the server, and at least one
but not all of them are refusing delivery (whether the refusal is but not all of them are refusing delivery (whether the refusal is
caused by a Sieve "ereject" action or for some other reason). In caused by a Sieve "ereject" action or for some other reason). In
this case, the server MUST accept the message and generate DSNs for this case, the server MUST accept the message and generate DSNs for
all recipients that are refusing it. Note that this exception does all recipients that are refusing it. Note that this exception does
not apply to LMTP, as LMTP is able to reject messages on a per- not apply to LMTP, as LMTP is able to reject messages on a per-
recipient basis. recipient basis. (However, the LMTP client may then have no choice
but to generate a DSN to report the error, which may result in
blowback.)
Note that according to [DSN], Delivery Status Notifications MUST NOT Note that according to [DSN], Delivery Status Notifications MUST NOT
be generated if the MAIL FROM (or Return-Path) is empty. be generated if the MAIL FROM (or Return-Path) is empty.
The DSN message MUST follow the requirements of [DSN] and [REPORT] The DSN message MUST follow the requirements of [DSN] and [REPORT]
The action-value field defined in [DSN], Section 2.3.3, MUST contain The action-value field defined in [DSN], Section 2.3.3, MUST contain
the value "failed". The human-readable portion of the non-delivery the value "failed". The human-readable portion of the non-delivery
report MUST contain the reason string from the "ereject" action and report MUST contain the reason string from the "ereject" action and
SHOULD contain additional text alerting the apparent original sender SHOULD contain additional text alerting the apparent original sender
that the message was refused by an email filter. This part of the that the message was refused by an email filter. This part of the
skipping to change at page 5, line 43 skipping to change at page 6, line 7
Sieve implementations that implement the "reject" action must use the Sieve implementations that implement the "reject" action must use the
"reject" capability string. "reject" capability string.
The "reject" action cancels the implicit keep and refuses delivery of The "reject" action cancels the implicit keep and refuses delivery of
a message. The reason string is a UTF-8 [UTF-8] string specifying a message. The reason string is a UTF-8 [UTF-8] string specifying
the reason for refusal. Unlike the "ereject" action described above, the reason for refusal. Unlike the "ereject" action described above,
this action would always favor preserving the exact text of the this action would always favor preserving the exact text of the
refusal reason. Typically the "reject" action refuses delivery of a refusal reason. Typically the "reject" action refuses delivery of a
message by sending back an MDN to the alleged sender (see message by sending back an MDN to the alleged sender (see
Section 2.2.1). However implementations MAY refuse delivery over Section 2.2.1). However implementations MAY refuse delivery over
protocol (as detailed in Section 2.4), if and only if all of the protocol (as detailed in Section 2.5), if and only if all of the
following conditions are true: following conditions are true:
1. The reason string consists of only US-ASCII characters 1. The reason string consists of only US-ASCII characters
or or
The reason string contains non-US-ASCII and both client and The reason string contains non-US-ASCII and both client and
server support and negotiate use of an SMTP/LMTP extension for server support and negotiate use of an SMTP/LMTP extension for
sending UTF-8 responses. sending UTF-8 responses.
2. LMTP protocol is used 2. LMTP protocol is used
or or
SMTP protocol is used and the message contains a single recipient SMTP protocol is used and the message has a single recipient
or or
SMTP protocol is used, the message contains multiple recipients SMTP protocol is used, the message has multiple recipients, and
and all of them refused message delivery (whether using Sieve or all of them refused message delivery (whether using Sieve or
not). not).
Script generators SHOULD ensure that a rejection action being
executed as a result of an anti-spam/anti-virus positive test be done
using the ereject action, as it is more suitable for such rejections.
Script generators MAY automatically upgrade scripts that previously
used the reject action for anti-spam/anti-virus related rejections.
Note that such generators MUST make sure that the target environment
can support the ereject action.
Example: Example:
require ["reject"]; require ["reject"];
if size :over 100K { if size :over 100K {
reject text: reject text:
Your message is to big. If you want to send me a big attachment, Your message is to big. If you want to send me a big attachment,
put it on a public web site and send me an URL. put it on a public web site and send me an URL.
. .
; ;
} }
(Pretend that the reason string above contains some non-ASCII text) (Pretend that the reason string above contains some non-ASCII text.)
2.2.1. Rejecting a message by sending an MDN 2.2.1. Rejecting a message by sending an MDN
The reject action resends the received message to the envelope sender The reject action resends the received message to the envelope sender
specified by the MAIL FROM (or Return-Path) address, wrapping it in a specified by the MAIL FROM (or Return-Path) address, wrapping it in a
"reject" form, explaining that it was rejected by the recipient. "reject" form, explaining that it was rejected by the recipient.
Note that according to [MDN], Message Disposition Notifications MUST Note that according to [MDN], Message Disposition Notifications MUST
NOT be generated if the MAIL FROM (or Return-Path) is empty. NOT be generated if the MAIL FROM (or Return-Path) is empty.
skipping to change at page 7, line 29 skipping to change at page 7, line 33
For this script, the first part of the MDN might appear as follows: For this script, the first part of the MDN might appear as follows:
------------------------------------------------------------ ------------------------------------------------------------
The message was refused by the recipient's mail filtering program. The message was refused by the recipient's mail filtering program.
The reason given was as follows: The reason given was as follows:
I am not taking mail from you, and I don't want your birdseed, I am not taking mail from you, and I don't want your birdseed,
either! either!
------------------------------------------------------------ ------------------------------------------------------------
2.3. Compatibility with other actions 2.3. Silent upgrade from reject to ereject
Implementations MUST NOT silently upgrade reject actions to ereject
actions, however user interfaces may change the specific action
underlying a descriptive representation, thereby effecting a silent
upgrade of sorts.
Script generators SHOULD ensure that a rejection action being
executed as a result of an anti-spam/anti-virus positive test be done
using the ereject action, as it is more suitable for such rejections.
Script generators MAY automatically upgrade scripts that previously
used the reject action for anti-spam/anti-virus related rejections.
Note that such generators MUST make sure that the target environment
can support the ereject action.
2.4. Compatibility with other actions
This section applies equally to "reject" and "ereject" actions. All This section applies equally to "reject" and "ereject" actions. All
references to the "reject" action in this section can be replaced references to the "reject" action in this section can be replaced
with the "ereject" action. with the "ereject" action.
A "reject" action cancels the implicit keep. A "reject" action cancels the implicit keep.
Implementations MUST prohibit the execution of more than one reject Implementations MUST prohibit the execution of more than one reject
in a Sieve script. in a Sieve script.
skipping to change at page 8, line 12 skipping to change at page 8, line 32
However, there are existing laws requiring certain organizations to However, there are existing laws requiring certain organizations to
archive all received messages, even the rejected ones. Also, it can archive all received messages, even the rejected ones. Also, it can
be quite useful to save copies of rejected messages for later be quite useful to save copies of rejected messages for later
analysis. analysis.
Any action that would modify the message body will not have an effect Any action that would modify the message body will not have an effect
on the body of any message refused by "reject" using an SMTP response on the body of any message refused by "reject" using an SMTP response
code and MUST NOT have any effect on the content of generated DSN/ code and MUST NOT have any effect on the content of generated DSN/
MDNs. MDNs.
2.4. Details of protocol level refusal 2.5. Details of protocol level refusal
If the "reason" string consists of multiple CRLF separated lines, If the "reason" string consists of multiple CRLF separated lines,
then the reason text MUST be returned as a multiline SMTP/LMTP then the reason text MUST be returned as a multiline SMTP/LMTP
response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the response, per [SMTP], Section 4.2.1. Any line MUST NOT exceed the
SMTP limit on the maximal line length. To make the reason string SMTP limit on the maximal line length. To make the reason string
conform to any such limits the server MAY insert CRLFs and turn the conform to any such limits the server MAY insert CRLFs and turn the
response into a multiline response. response into a multiline response.
In the following script (which assumes support for the spamtest In the following script (which assumes support for the spamtest
[SPAMTEST] and fileinto extensions), messages that test highly [SPAMTEST] and fileinto extensions), messages that test highly
skipping to change at page 11, line 13 skipping to change at page 11, line 44
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", Reporting of Mail System Administrative Messages",
RFC 3462, January 2003. RFC 3462, January 2003.
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language",
RFC 3028, January 2001. RFC 3028, January 2001.
[SIEVEBIS] [SIEVEBIS]
Showalter, T. and P. Guenther, "Sieve: An Email Filtering Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-13 (work in progress), Language", RFC 5228, January 2008.
October 2007.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[VACATION] [VACATION]
Showalter, T. and N. Freed, "Sieve Email Filtering: Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", draft-ietf-sieve-vacation-07 (work in Vacation Extension", RFC 5230, January 2008.
progress), March 2007.
6.2. Informative References 6.2. Informative References
[Joe-DoS] "Mail Non-Delivery Message DDoS Attacks", 4 2004. [Joe-DoS] "Mail Non-Delivery Message DDoS Attacks", 4 2004.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, August 2004. Electronic Mail", RFC 3834, August 2004.
[SPAMTEST] [SPAMTEST]
Daboo, C., "SIEVE Email Filtering: Spamtest and Virustest Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extensions", draft-ietf-sieve-spamtestbis-05 (work in Extensions", RFC 5235, January 2008.
progress), July 2006.
[UTF8-RESP] [UTF8-RESP]
Melnikov, A., "SMTP Language Extension", Melnikov, A., "SMTP Language Extension",
draft-melnikov-smtp-lang-07 (work in progress), June 2007. draft-melnikov-smtp-lang-07 (work in progress), June 2007.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner,
Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens
for comments and corrections. for comments and corrections.
skipping to change at page 13, line 7 skipping to change at page 14, line 7
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 27 change blocks. 
51 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/