draft-ietf-sieve-external-lists-08.txt   draft-ietf-sieve-external-lists-09.txt 
Sieve Working Group A. Melnikov Sieve Working Group A. Melnikov
Internet-Draft Isode Limited Internet-Draft Isode Limited
Intended status: Standards Track B. Leiba Intended status: Standards Track B. Leiba
Expires: November 10, 2011 Huawei Technologies Expires: November 19, 2011 Huawei Technologies
May 9, 2011 May 18, 2011
Sieve Extension: Externally Stored Lists Sieve Extension: Externally Stored Lists
draft-ietf-sieve-external-lists-08 draft-ietf-sieve-external-lists-09
Abstract Abstract
The Sieve scripting language can be used to implement whitelisting, The Sieve scripting language can be used to implement whitelisting,
blacklisting, personal distribution lists, and other sorts of list blacklisting, personal distribution lists, and other sorts of list
matching. Currently, this requires that all members of such lists be matching. Currently, this requires that all members of such lists be
hardcoded in the script itself. Whenever a member of a list is added hardcoded in the script itself. Whenever a member of a list is added
or deleted, the script needs to be updated and possibly uploaded to a or deleted, the script needs to be updated and possibly uploaded to a
mail server. mail server.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 10, 2011. This Internet-Draft will expire on November 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 14, line 5 skipping to change at page 14, line 5
Note in particular that it can be too easy for a script to use Note in particular that it can be too easy for a script to use
redirect :list ":addrbook:default"; redirect :list ":addrbook:default";
to send messages to "everyone in your address book", and one can to send messages to "everyone in your address book", and one can
easily imagine both intentional and accidental abuse. The situation easily imagine both intentional and accidental abuse. The situation
can be even worse for, say, ":addrbook:corporate". Warnings, as well can be even worse for, say, ":addrbook:corporate". Warnings, as well
as enforced limits, are appropriate here. as enforced limits, are appropriate here.
Applications SHOULD ensure appropriate restrictions are in place to Applications SHOULD ensure appropriate restrictions are in place to
protect sensitive information that might be revealed by "addrbook" protect sensitive information that might be revealed by "addrbook"
URIs from access or modification by untrusted sources. URNs from access or modification by untrusted sources.
4. IANA Considerations 4. IANA Considerations
4.1. Registration of Sieve Extension 4.1. Registration of Sieve Extension
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
extension specified in this document. This information should be extension specified in this document. This information should be
added to the list of sieve extensions given on added to the list of sieve extensions given on
http://www.iana.org/assignments/sieve-extensions. http://www.iana.org/assignments/sieve-extensions.
skipping to change at page 14, line 29 skipping to change at page 14, line 29
Capability name: extlists Capability name: extlists
Description: Adds the ":list" match type to certain Sieve tests, and Description: Adds the ":list" match type to certain Sieve tests, and
the ":list" argument to the "redirect" action. The ":list" match the ":list" argument to the "redirect" action. The ":list" match
type changes tests to match values against values stored in one type changes tests to match values against values stored in one
or more externally stored lists. The ":list" argument to the or more externally stored lists. The ":list" argument to the
redirect action changes the redirect action to forward the redirect action changes the redirect action to forward the
message to email addresses stored in the externally stored list. message to email addresses stored in the externally stored list.
RFC number: this RFC RFC number: [[this RFC]]
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
4.2. Registration of ManageSieve Capability 4.2. Registration of ManageSieve Capability
The following requests IANA to register a new ManageSieve Capability The following requests IANA to register a new ManageSieve Capability
according to the IANA registration template specified in [RFC5804]: according to the IANA registration template specified in [RFC5804]:
To: iana@iana.org To: iana@iana.org
Subject: ManageSieve Capability Registration Subject: ManageSieve Capability Registration
Capability name: extlists Capability name: extlists
Description: This capability is returned if the server supports the Description: This capability is returned if the server supports the
"extlists" [RFCXXXX] Sieve extension. "extlists" [[this RFC]] Sieve extension.
Relevant publications: this RFC, Section 2.8 Relevant publications: [[this RFC]], Section 2.8
Person & email address to contact for further information: Sieve Person & email address to contact for further information: Sieve
mailing list <sieve@ietf.org> mailing list <sieve@ietf.org>
Author/Change controller: IESG Author/Change controller: IESG
4.3. Creation of Sieve URN Parameters registry 4.3. Creation of Sieve URN Parameters registry
The following requests IANA to create a new registry under "Sieve The following requests IANA to create a new registry under "Sieve
Extensions" for Sieve URN Parameters. Extensions" for Sieve URN Parameters. Registration into this
registry is according to the "Specification Required" policy
[RFC5226].
URN parameter name: The name of the URN parameter. If the name is URN parameter name: The name of the URN parameter. If the name is
"paramname", the resulting top-level URN will be "paramname", the resulting top-level URN will be
"urn:ietf:params:sieve:paramname". "urn:ietf:params:sieve:paramname".
Reference: The document and section where the definition of the Reference: The document and section where the definition of the
parameter can be found. The documentation MUST include the parameter can be found. The documentation MUST include the
following information (see Section 2.6 for an example): following information (see Section 2.6 for an example):
URN parameter name: The name of the URN parameter. URN parameter name: The name of the URN parameter.
skipping to change at page 15, line 48 skipping to change at page 16, line 7
Contact: Contact information, in case there are questions. Contact: Contact information, in case there are questions.
4.4. Registration of the "addrbook" URN parameter 4.4. Registration of the "addrbook" URN parameter
The following requests IANA to register a new Sieve URN parameter in The following requests IANA to register a new Sieve URN parameter in
the registry defined in Section 4.3. the registry defined in Section 4.3.
URN parameter name: addrbook URN parameter name: addrbook
Reference: [This RFC], Section 2.6 Reference: [[this RFC]], Section 2.6
4.5. Registration of "sieve" URN sub-namespace 4.5. Registration of "sieve" URN sub-namespace
The following requests IANA to register a new URN sub-namespace The following requests IANA to register a new URN sub-namespace
within the IETF URN Sub-namespace for Registered Protocol Parameter within the IETF URN Sub-namespace for Registered Protocol Parameter
Identifiers defined in [RFC3553]. Identifiers defined in [RFC3553].
Registry name: sieve Registry name: sieve
Specification: [this RFC] Specification: [[this RFC]]
Repository: [the registry created in Section 4.3] Repository: [[the registry created in Section 4.3]]
Index value: Sub-parameters MUST be specified in UTF-8, using Index value: Sub-parameters MUST be specified in UTF-8, using
standard URI encoding where necessary. standard URI encoding where necessary.
5. Acknowledgements 5. Acknowledgements
Thanks to Alexandros Vellis, Nigel Swinson, Ned Freed, Kjetil Torgrim Thanks to Alexandros Vellis, Nigel Swinson, Ned Freed, Kjetil Torgrim
Homme, Dave Cridland, Cyrus Daboo, Pete Resnick, and Robert Burrell Homme, Dave Cridland, Cyrus Daboo, Pete Resnick, and Robert Burrell
Donkin for ideas, comments and suggestions. Kristin Hubner also Donkin for ideas, comments and suggestions. Kristin Hubner also
helped greatly with the examples. helped greatly with the examples.
skipping to change at page 16, line 41 skipping to change at page 16, line 45
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, October 2005. RFC 4151, October 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, July 2010. Managing Sieve Scripts", RFC 5804, July 2010.
6.2. Informative References 6.2. Informative References
 End of changes. 12 change blocks. 
12 lines changed or deleted 18 lines changed or added

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