draft-ietf-sieve-spamtestbis-01.txt   draft-ietf-sieve-spamtestbis-02.txt 
SIEVE Email Filtering Working C. Daboo SIEVE Email Filtering Working C. Daboo
Group ISAMET, Inc. Group January 20, 2006
Internet-Draft
Expires: January 19, 2006 Expires: July 24, 2006
SIEVE Email Filtering: Spamtest and Virustest Extensions SIEVE Email Filtering: Spamtest and Virustest Extensions
draft-ietf-sieve-spamtestbis-01 draft-ietf-sieve-spamtestbis-02
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 34 skipping to change at page 1, line 34
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 January 19, 2006. This Internet-Draft will expire on July 24, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The SIEVE email filtering language "spamtest", "spamtestplus" and The SIEVE email filtering language "spamtest", "spamtestplus" and
"virustest" extensions permit users to use simple, portable commands "virustest" extensions permit users to use simple, portable commands
for spam and virus tests on email messages. Each extension provides for spam and virus tests on email messages. Each extension provides
a new test using matches against numeric 'scores'. It is the a new test using matches against numeric 'scores'. It is the
responsibility of the underlying SIEVE implementation to do the responsibility of the underlying SIEVE implementation to do the
actual checks that result in values returned by the tests. actual checks that result in values returned by the tests.
Change History (to be removed prior to publication as an RFC) Change History (to be removed prior to publication as an RFC)
Changes from -01:
1. Changed ACAP reference to i18n-comparators draft.
2. Changed MUST in security section for virus checker updates to
plain must.
3. Return string "untested" when :percent is used and no test has
been done.
4. Remove MUST NOT for having both spamtestplus and spamtest
capabilities present, and instead make it a SHOULD NOT.
5. Add text to state that implementations MUST return an error if
spamtestplus is not present when :percent is used.
6. Tweak first para of security considerations to better reflect
reality of testing.
7. Syntax -> Usage.
8. Updated references to 3028bis and 3431bis.
Changes from -00: Changes from -00:
1. Added description of how to check for untested when using 1. Added description of how to check for untested when using
:percent. :percent.
2. Changed requires item to 'spamtestplus'. 2. Changed requires item to 'spamtestplus'.
3. Changed text describing which requires item needs to be present. 3. Changed text describing which requires item needs to be present.
Changes from RFC3685: Changes from RFC3685:
1. Added ':percent' argument to spamtest. 1. Added ':percent' argument to spamtest.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. SIEVE Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3. SIEVE Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 General Considerations . . . . . . . . . . . . . . . . . . 4 3.1. General Considerations . . . . . . . . . . . . . . . . . . 5
3.2 Test spamtest . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Test spamtest . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 spamtest without :percent argument . . . . . . . . . . 4 3.2.1. spamtest without :percent argument . . . . . . . . . . 6
3.2.2 spamtest with :percent argument . . . . . . . . . . . 5 3.2.2. spamtest with :percent argument . . . . . . . . . . . 6
3.3 Test virustest . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Test virustest . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1 spamtestplus registration . . . . . . . . . . . . . . . . 8 5.1. spamtestplus registration . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction and Overview 1. Introduction and Overview
SIEVE scripts are frequently being used to do spam and virus SIEVE scripts are frequently being used to do spam and virus
filtering based on either implicit script tests (e.g. tests for filtering based on either implicit script tests (e.g. tests for
'black-listed' senders directly encoded in the SIEVE script), or via 'black-listed' senders directly encoded in the SIEVE script), or via
testing messages modified by some external spam or virus checker that testing messages modified by some external spam or virus checker that
handled the message prior to SIEVE. The use of third-party spam and handled the message prior to SIEVE. The use of third-party spam and
virus checker tools poses a problem since each tool has its own way virus checker tools poses a problem since each tool has its own way
of indicating the result of its checks. These usually take the form of indicating the result of its checks. These usually take the form
skipping to change at page 3, line 38 skipping to change at page 4, line 38
indication of whether the message has been tested for spam or not. indication of whether the message has been tested for spam or not.
The spam and virus checks themselves are handled by the underlying The spam and virus checks themselves are handled by the underlying
SIEVE implementation in whatever manner is appropriate, and the SIEVE implementation in whatever manner is appropriate, and the
implementation maps the results of these checks into the numeric implementation maps the results of these checks into the numeric
ranges defined by the new tests. Thus a SIEVE implementation can ranges defined by the new tests. Thus a SIEVE implementation can
have a spam test that implicitly checks for third-party spam tool have a spam test that implicitly checks for third-party spam tool
headers and determines how those map into the spamtest numeric range. headers and determines how those map into the spamtest numeric range.
In order to do numeric comparisons against the returned strings, In order to do numeric comparisons against the returned strings,
server implementations MUST also support the SIEVE relational server implementations MUST also support the SIEVE relational
[RFC3431] extension, in addition to the extensions described here. [I-D.ietf-sieve-3431bis] extension, in addition to the extensions
All examples below assume the relational extension is present. described here. All examples below assume the relational extension
is present.
2. Conventions Used in This Document 2. Conventions Used in This Document
Conventions for notations are as in [RFC3028] section 1.1, including Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
use of [RFC2119]. 1.1, including use of [RFC2119].
The term 'spam' is used in this document to refer to unsolicited or The term 'spam' is used in this document to refer to unsolicited or
unwanted email messages. This document does not attempt to define unwanted email messages. This document does not attempt to define
what exactly constitutes spam, or how it should be identified, or what exactly constitutes spam, or how it should be identified, or
what actions should be taken when detected. what actions should be taken when detected.
The term 'virus' is used in this document to refer to any type of The term 'virus' is used in this document to refer to any type of
message whose content can cause malicious damage. This document does message whose content can cause malicious damage. This document does
not attempt to define what exactly constitutes a virus, or how it not attempt to define what exactly constitutes a virus, or how it
should be identified, or what actions should be taken when detected. should be identified, or what actions should be taken when detected.
3. SIEVE Extensions 3. SIEVE Extensions
3.1 General Considerations 3.1. General Considerations
The "spamtest" and "virustest" tests described below both return a The "spamtest" and "virustest" tests described below can both return
string that starts with a numeric value, followed by an optional a string that starts with a numeric value, followed by an optional
space (%x20) character and optional arbitrary text. The numeric space (%x20) character and optional arbitrary text. The numeric
value can be compared to specific values using the SIEVE relational value can be compared to specific values using the SIEVE relational
[RFC3431] extension in conjunction with the "i;ascii-numeric" [I-D.ietf-sieve-3431bis] extension in conjunction with the "i;ascii-
comparator [RFC2244], which will test for the presence of a numeric numeric" comparator [I-D.newman-i18n-comparator], which will test for
value at the start of the string, ignoring any additional text in the the presence of a numeric value at the start of the string, ignoring
string. The additional text can be used to carry implementation any additional text in the string. The additional text can be used
specific details about the tests performed and descriptive comments to carry implementation specific details about the tests performed
about the result. Tests can be done using standard string and descriptive comments about the result. Tests can be done using
comparators against this text if it helps to refine behaviour, standard string comparators against this text if it helps to refine
however this will break portability of the script as the text will behaviour, however this will break portability of the script as the
likely be specific to a particular implementation. text will likely be specific to a particular implementation.
3.2 Test spamtest 3.2. Test spamtest
Syntax: spamtest [":percent"] [COMPARATOR] [MATCH-TYPE] Usage: spamtest [":percent"] [COMPARATOR] [MATCH-TYPE]
<value: string> <value: string>
SIEVE implementations that implement the "spamtest" test use an SIEVE implementations that implement the "spamtest" test use an
identifier of either "spamtest" or "spamtestplus" for use with the identifier of either "spamtest" or "spamtestplus" for use with the
capability mechanism. capability mechanism.
If the ":percent" argument is not used with any spamtest test, then If the ":percent" argument is not used with any spamtest test, then
one of either the "spamtest" or "spamtestplus" capability identifiers one of either the "spamtest" or "spamtestplus" capability identifiers
MUST be present, though both SHOULD NOT be present together. MUST be present.
If the ":percent" argument is used with any spamtest test, then the If the ":percent" argument is used with any spamtest test, then the
"spamtestplus" capability identifier MUST be present, and the "spamtestplus" capability identifier MUST be present. SIEVE
"spamtest" capability identitifer SHOULD NOT be present. implementations MUST return an error if the ":percent" argument is
used and "spamtestplus" is not specified.
In the interests of brevity and clarity, scripts SHOULD NOT specify
both "spamtestplus" and "spamtest" capability identifiers together.
The "spamtest" test evaluates to true if the spamtest result matches The "spamtest" test evaluates to true if the spamtest result matches
the value. The type of match is specified by the optional match the value. The type of match is specified by the optional match
argument, which defaults to ":is" if not specified. argument, which defaults to ":is" if not specified.
3.2.1 spamtest without :percent argument 3.2.1. spamtest without :percent argument
When the ":percent" argument is not present in the "spamtest" test, When the ":percent" argument is not present in the "spamtest" test,
the result of the test is a string starting with a numeric value in the result of the test is a string starting with a numeric value in
the range "0" (zero) through "10", with meanings summarised below: the range "0" (zero) through "10", with meanings summarised below:
spamtest interpretation spamtest interpretation
value value
0 message was not tested for spam 0 message was not tested for spam
1 message was tested and is clear of spam 1 message was tested and is clear of spam
skipping to change at page 5, line 36 skipping to change at page 6, line 43
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3" elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3"
{ {
fileinto "INBOX.spam-trap"; fileinto "INBOX.spam-trap";
} }
In this example, any message that has not passed through a spam check In this example, any message that has not passed through a spam check
tool will be filed into the mailbox "INBOX.unclassified". Any tool will be filed into the mailbox "INBOX.unclassified". Any
message with a spamtest value greater than or equal to "3" is filed message with a spamtest value greater than or equal to "3" is filed
into a mailbox called "INBOX.spam-trap" in the user's mailstore. into a mailbox called "INBOX.spam-trap" in the user's mailstore.
3.2.2 spamtest with :percent argument 3.2.2. spamtest with :percent argument
When the ":percent" argument is present in the "spamtest" test, the When the ":percent" argument is present in the "spamtest" test, the
result of the test is a string starting with a numeric value in the result of the test is a string starting with a numeric value in the
range "0" (zero) through "100", with meanings summarised below: range "0" (zero) through "100", with meanings summarised below, or
the string "untested" for the case where the message was not tested
for spam (corresponding to the "0" value returned when the ":percent"
argument is not used):
spamtest interpretation spamtest interpretation
value value
"untested" message was not tested for spam
0 message was tested and is clear of spam 0 message was tested and is clear of spam
1 - 99 message was tested and has a varying likelihood 1 - 99 message was tested and has a varying likelihood
of containing spam in increasing order of containing spam in increasing order
100 message was tested and definitely contains spam 100 message was tested and definitely contains spam
The underlying SIEVE implementation will map whatever spam check is The underlying SIEVE implementation will map whatever spam check is
done into this numeric range, as appropriate. done into the numeric range, as appropriate.
The range of tests for :percent does not include a value to determine To determine whether the message was tested for spam or not, the
whether the message was not tested for spam. Instead, a test without preferred solution is to use the test without the ":percent"
the :percent argument can be used to check for that situation, which argument, testing for the value "0" as described in Section 3.2.1.
is done by testing for the value "0" as described in Section 3.2.1.
Examples: Examples:
require ["spamtestplus", "fileinto", require ["spamtestplus", "fileinto",
"relational", "comparator-i;ascii-numeric"]; "relational", "comparator-i;ascii-numeric"];
if spamtest :value "eq" if spamtest :value "eq"
:comparator "i;ascii-numeric" "0" :comparator "i;ascii-numeric" "0"
{ {
fileinto "INBOX.unclassified"; fileinto "INBOX.unclassified";
} }
elsif spamtest :percent :value "ge" elsif spamtest :percent :value "ge"
:comparator "i;ascii-numeric" "30" :comparator "i;ascii-numeric" "30"
{ {
fileinto "INBOX.spam-trap"; fileinto "INBOX.spam-trap";
} }
In this example, any message that has not passed through a spam check In this example, any message that has not passed through a spam check
tool will be filed into the mailbox "INBOX.unclassified". Any tool will be filed into the mailbox "INBOX.unclassified". Any
message with a spamtest value greater than or equal to "30" is filed message with a spamtest percentage value greater than or equal to
into a mailbox called "INBOX.spam-trap" in the user's mailstore. "30" is filed into a mailbox called "INBOX.spam-trap" in the user's
mailstore.
3.3 Test virustest 3.3. Test virustest
Syntax: virustest [COMPARATOR] [MATCH-TYPE] Usage: virustest [COMPARATOR] [MATCH-TYPE]
<value: string> <value: string>
SIEVE implementations that implement the "virustest" test have an SIEVE implementations that implement the "virustest" test have an
identifier of "virustest" for use with the capability mechanism. identifier of "virustest" for use with the capability mechanism.
The "virustest" test evaluates to true if the virustest result The "virustest" test evaluates to true if the virustest result
matches the value. The type of match is specified by the optional matches the value. The type of match is specified by the optional
match argument, which defaults to ":is" if not specified. match argument, which defaults to ":is" if not specified.
The virustest result is a string starting with a numeric value in the The virustest result is a string starting with a numeric value in the
skipping to change at page 7, line 52 skipping to change at page 9, line 8
In this example, any message that has not passed through a virus In this example, any message that has not passed through a virus
check tool will be filed into the mailbox "INBOX.unclassified". Any check tool will be filed into the mailbox "INBOX.unclassified". Any
message with a virustest value equal to "4" is filed into a mailbox message with a virustest value equal to "4" is filed into a mailbox
called "INBOX.quarantine" in the user's mailstore. Any message with called "INBOX.quarantine" in the user's mailstore. Any message with
a virustest value equal to "5" is discarded (removed) and not a virustest value equal to "5" is discarded (removed) and not
delivered to the user's mailstore. delivered to the user's mailstore.
4. Security Considerations 4. Security Considerations
SIEVE implementations SHOULD ensure that "spamtest" and "virustest" SIEVE implementations SHOULD ensure that "spamtest" and "virustest"
tests can only occur for messages that have gone through a legitimate tests only report spam and virus test results for messages that
spam or virus check process. If such checks rely on the addition of actually have gone through a legitimate spam or virus check process.
special headers to messages, it is the responsibility of the In particular, if such checks rely on the addition and subsequent
checking of private header fields, it is the responsibility of the
implementation to ensure that such headers cannot be spoofed by the implementation to ensure that such headers cannot be spoofed by the
sender, to prevent the implementation from being tricked into sender or intermediary and thereby prevent the implementation from
returning the wrong result for the test. being tricked into returning the wrong result for the test.
Server administrators MUST ensure that the virus checking tools are Server administrators must ensure that the virus checking tools are
kept up to date, to provide reasonable protection for users using the kept up to date, to provide reasonable protection for users using the
"virustest" test. Users should be made aware of the fact that the "virustest" test. Users should be made aware of the fact that the
"virustest" test does not provide a 100% reliable way to remove all "virustest" test does not provide a 100% reliable way to remove all
viruses, and they should continue to exercise caution when dealing viruses, and they should continue to exercise caution when dealing
with messages of unknown content and origin. with messages of unknown content and origin.
Beyond that, the "spamtest" and "virustest" extensions do not raise Beyond that, the "spamtest" and "virustest" extensions do not raise
any security considerations that are not present in the base any security considerations that are not present in the base
[RFC3028] protocol, and these issues are discussed in [RFC3028]. [I-D.ietf-sieve-3028bis] protocol, and these issues are discussed in
[I-D.ietf-sieve-3028bis].
5. IANA Considerations 5. IANA Considerations
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
extensions specified in this document, that are not already extensions specified in this document, that are not already
registered in [RFC3685]: registered in [RFC3685]:
5.1 spamtestplus registration 5.1. spamtestplus registration
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: spamtestplus Capability name: spamtestplus
Capability keyword: spamtest Capability keyword: spamtest
Capability arguments: :percent Capability arguments: :percent
Standards Track/IESG-approved experimental RFC number: this RFC Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information: Person and email address to contact for further information:
Cyrus Daboo Cyrus Daboo
ISAMET, Inc.
5001 Baum Blvd., Suite 650,
Pittsburgh, PA 15213
U.S.A.
<mailto:daboo@isamet.com> <mailto:cyrus@daboo.name>
This information should be added to the list of sieve extensions This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
6. References 6. References
6.1 Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-sieve-3028bis]
Requirement Levels", BCP 14, RFC 2119, March 1997. Showalter, T. and P. Guenther, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-05 (work in progress),
November 2005.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", [I-D.ietf-sieve-3431bis]
RFC 3028, January 2001. Segmuller, W. and B. Leiba, "Sieve Extension: Relational
Tests", draft-ietf-sieve-3431bis-04 (work in progress),
December 2005.
[RFC3431] Segmuller, W., "Sieve Extension: Relational Tests", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 3431, December 2002. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest
Extensions", RFC 3685, February 2004. Extensions", RFC 3685, February 2004.
6.2 Informative References 6.2. Informative References
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [I-D.newman-i18n-comparator]
Configuration Access Protocol", RFC 2244, November 1997. Newman, C., "Internet Application Protocol Collation
Registry", draft-newman-i18n-comparator-05 (work in
progress), September 2005.
Author's Address Appendix A. Acknowledgments
Cyrus Daboo Thanks to Tony Hansen, Jutta Degener, Ned Freed, Ashish Gawarikar,
ISAMET, Inc. Alexey Melnikov and Nigel Swinson for comments and corrections.
5001 Baum Blvd.
Suite 650
Pittsburgh, PA 15213
US
Email: daboo@isamet.com Author's Address
Appendix A. Acknowledgments Cyrus Daboo
Thanks to Tony Hansen, Jutta Degener, Ned Freed, Ashish Gawarikar and Email: cyrus@daboo.name
Nigel Swinson for comments and corrections.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 10, line 41 skipping to change at page 12, line 41
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 43 change blocks. 
91 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/