draft-ietf-sieve-refuse-reject-07.txt   draft-ietf-sieve-refuse-reject-08.txt 
Sieve Working Group A. Stone, Ed. Sieve Working Group A. Stone, Ed.
Internet-Draft Hydric Acid Internet-Draft Serendipity
Updates: 3028 (if approved) Obsoletes: 3028 (if approved)
Intended status: Standards Track May 26, 2008 Updates: 5228 (if approved) November 17, 2008
Expires: November 27, 2008 Intended status: Standards Track
Expires: May 21, 2009
Sieve Email Filtering: Reject and Extended Reject Extensions Sieve Email Filtering: Reject and Extended Reject Extensions
draft-ietf-sieve-refuse-reject-07 draft-ietf-sieve-refuse-reject-08
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 36
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 November 27, 2008. This Internet-Draft will expire on May 21, 2009.
Copyright Notice
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, if possible. 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. The "ereject" action is similar to "reject", but
will always favor protocol level message rejection.
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 . . . . . . . . . . . 4
2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 4
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 . 5
2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5 2.1.2. Rejecting a message by sending a DSN . . . . . . . . . 5
2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Rejecting a message by sending an MDN . . . . . . . . 6 2.2.1. Rejecting a message by sending an MDN . . . . . . . . 7
2.3. Silent upgrade from reject to ereject . . . . . . . . . . 7 2.3. Silent upgrade from reject to ereject . . . . . . . . . . 8
2.4. Compatibility with other actions . . . . . . . . . . . . . 7 2.4. Compatibility with other actions . . . . . . . . . . . . . 8
2.5. Details of protocol level refusal . . . . . . . . . . . . 8 2.5. Details of protocol level refusal . . . . . . . . . . . . 9
3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 10 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. reject extension registration . . . . . . . . . . . . . . 10 5.1. reject extension registration . . . . . . . . . . . . . . 11
5.2. ereject extension registration . . . . . . . . . . . . . . 10 5.2. ereject extension registration . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The Sieve mail filtering language [SIEVEBIS], as originally defined The Sieve mail filtering language, as originally defined in RFC 3028
in RFC 3028 [SIEVE], specified that the "reject" action shall discard [SIEVE], specified that the "reject" action shall discard a message
a message and send a Message Disposition Notification [MDN] to the and send a Message Disposition Notification [MDN] to the envelope
envelope sender along with an explanatory message. RFC 5228 sender along with an explanatory message. The Sieve mail filtering
[SIEVEBIS] does not define any reject action, hence the purpose of language, as updated in RFC 5228 [SIEVEBIS], does not define any
this document. 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, if possible. during the SMTP transaction, if possible.
An important goal of this document is to reduce the risk of Sieve
scripts being used to perpetrate "Joe-job" spam runs, where the MDN
sent notifying the sender of a message of its non-delivery is in fact
sent to an innocent third-party. The original Sieve "reject" action
defined in RFC 3028 required use of MDNs for rejecting messages, thus
contributing to the flood of Joe-job spam to victims of Joe-jobs. By
rejecting the message at the protocol level, it is less likely that
an MDN will be needed, and so less likely that an MDN will be
misdirected at an innocent third-party.
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.
This document also specifies the use of a Delivery Status
Notification [DSN] instead of an MDN when appropriate. In general,
an MDN is generated by [[[arnt's text]]] while a DSN is generated by
[[[arnt's text]]].
This document also describes how to use reject/ereject at varying
points in the email stack: Mail Transfer Agent (MTA), Mail Delivery
Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a
comprehensive discussion of these environments.
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 5228 [SIEVEBIS] 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. Implementors are advised to follow best practices and keep detected. Implementors are advised to follow best practices and 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.
The "ereject" action cancels the implicit keep and refuses delivery The "ereject" action cancels the implicit keep and refuses delivery
of a message. The reason string is a UTF-8 [UTF-8] string specifying of a message. The reason string is a UTF-8 [UTF-8] string specifying
the reason for refusal. How a message is refused depends on the the reason for refusal. How a message is refused depends on the
capabilities of the mail component (MDA or MTA) executing the Sieve capabilities of the mail component (MDA or MTA) executing the Sieve
script. The Sieve interpreter MUST carry out one of the following script. The Sieve interpreter MUST carry out one of the following
actions (listed in order from most to least preferred), SHOULD carry actions (listed in order from most to least preferred), MUST carry
out the most preferable action, and SHOULD fall back to lesser out the most preferable action possible, and MUST fall back to lesser
actions if a preferred action fails. actions if a preferred action fails.
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. Send a non-delivery report to the envelope sender ([REPORT]
indicates that the message has a forged return-path. [DSN]), unless the envelope sender address is determined to be a
forged or otherwise invalid address.
3. Send a non-delivery report to the envelope sender ([REPORT] Note that determination of whether or not an envelope sender is a
[DSN]). See Section 2.1.2 for more details. forgery may be performed by site-specific and implementation-specific
heuristic techniques, such as "return-path verification", details of
which are outside the scope of this document. Implementations SHOULD
log instances when a non-delivery report is not sent and the reason
for not sending the report (e.g. content was spam, return-path
invalid, etc.).
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, and MUST be available support protocol level rejection, e.g. an MUA, and MUST be available
in all other environments that support the reject action. in all other environments that support the reject action.
Example: Example:
require ["ereject"]; require ["ereject"];
if address "from" "someone@example.com" { if address "from" "someone@example.com" {
ereject "I no longer accept mail from this address"; 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.
The risk that these actions will generate blowback spam are minimized
but cannot be eliminated completely even in the case of ereject, so
caution is advised when using these actions to deal with messages
determined to be spam.
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
response text. If non-ASCII characters appear in the "reason" response text. If non-ASCII characters appear in the "reason"
string, they can be sent at the protocol level if and only if the string, they can be sent at the protocol level if and only if the
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.
skipping to change at page 5, line 17 skipping to change at page 5, line 52
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. (However, the LMTP client may then have no choice recipient basis. (However, the LMTP client may then have no choice
but to generate a DSN to report the error, which may result in but to generate a DSN to report the error, which may result in
blowback.) blowback spam.)
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
report might appear as follows: report might appear as follows:
skipping to change at page 6, line 7 skipping to change at page 6, line 40
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.5), if and only if all of the SMTP/LMTP protocol (as detailed in Section 2.5), if and only if all
following conditions are true: of the 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 has a single recipient SMTP protocol is used and the message has a single recipient
or or
SMTP protocol is used, the message has multiple recipients, and SMTP protocol is used, the message has multiple recipients, and
all of them refused message delivery (whether using Sieve or all of them refused message delivery (whether using Sieve or
not). not).
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 too 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
skipping to change at page 11, line 40 skipping to change at page 12, line 40
[LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, [LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996. October 1996.
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition
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",
RFC 3028, January 2001.
[SIEVEBIS] [SIEVEBIS]
Guenther, P. and T. Showalter, "Sieve: An Email Filtering Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[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.
skipping to change at page 12, line 7 skipping to change at page 13, line 4
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[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", RFC 5230, January 2008. Vacation Extension", RFC 5230, January 2008.
6.2. Informative References 6.2. Informative References
[Joe-DoS] "Mail Non-Delivery Message DDoS Attacks", 4 2004. [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-11 (work in progress),
October 2008.
[Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery
Message DDoS Attacks", April 2004, <http://
www.techzoom.net/papers/
mail_non_delivery_notice_attacks_2004.pdf>.
[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.
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language",
RFC 3028, January 2001.
[SPAMTEST] [SPAMTEST]
Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extensions", RFC 5235, January 2008. Extensions", RFC 5235, January 2008.
[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
skipping to change at page 12, line 37 skipping to change at page 14, line 8
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.
The authors gratefully acknowledge the extensive work of Tim The authors gratefully acknowledge the extensive work of Tim
Showalter as the author of the RFC 3028, which originally defined the Showalter as the author of the RFC 3028, which originally defined the
"reject" action. "reject" action.
Authors' Addresses Authors' Addresses
Aaron Stone (editor) Aaron Stone (editor)
Hydric Acid Serendipity
260 El Verano Ave 260 El Verano Ave
Palo Alto, CA 94306 Palo Alto, CA 94306
USA USA
Email: aaron@serendipity.palo-alto.ca.us Email: aaron@serendipity.palo-alto.ca.us
Matthew Elvey Matthew Elvey
The Elvey Partnership, LLC The Elvey Partnership, LLC
1819 Polk Street, Suite 133 1819 Polk Street, Suite 133
San Francisco, CA 94109 San Francisco, CA 94109
USA USA
Email: sieve3@matthew.elvey.com Email: sieve3@matthew.elvey.com
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
skipping to change at page 14, line 44 skipping to change at line 636
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 24 change blocks. 
53 lines changed or deleted 91 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/