draft-ietf-sieve-external-lists-10.txt   rfc6134.txt 
Sieve Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Limited Request for Comments: 6134 Isode Limited
Intended status: Standards Track B. Leiba Category: Standards Track B. Leiba
Expires: December 11, 2011 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
June 9, 2011 July 2011
Sieve Extension: Externally Stored Lists Sieve Extension: Externally Stored Lists
draft-ietf-sieve-external-lists-10
Abstract Abstract
The Sieve email filtering language can be used to implement email The Sieve email filtering language can be used to implement email
whitelisting, blacklisting, personal distribution lists, and other whitelisting, blacklisting, personal distribution lists, and other
sorts of list matching. Currently, this requires that all members of sorts of list matching. Currently, this requires that all members of
such lists be hardcoded in the script itself. Whenever a member of a such lists be hard-coded in the script itself. Whenever a member of
list is added or deleted, the script needs to be updated and possibly a list is added or deleted, the script needs to be updated and
uploaded to a mail server. possibly uploaded to a mail server.
This document defines a Sieve extension for accessing externally This document defines a Sieve extension for accessing externally
stored lists -- lists whose members are stored externally to the stored lists -- lists whose members are stored externally to the
script, such as using LDAP (RFC 4510), ACAP (RFC 2244), CardDAV (work script, such as using the Lightweight Directory Access Protocol
in progress), or relational databases. (LDAP), the Application Configuration Access Protocol (ACAP), vCard
Extensions to WebDAV (CardDAV), or relational databases.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 11, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6134.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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. Extlists Extension . . . . . . . . . . . . . . . . . . . . . . 3
2. Extlists Extension . . . . . . . . . . . . . . . . . . . . 3 2.1. Capability Identifier . . . . . . . . . . . . . . . . . . 3
2.1. Capability Identifier . . . . . . . . . . . . . . . . . . 3 2.2. :list Match Type for Supported Tests . . . . . . . . . . . 3
2.2. :list Match Type for Supported Tests . . . . . . . . . . . 3 2.3. :list Tagged Argument to the "redirect" Action . . . . . . 5
2.3. :list Tagged Argument to the "redirect" Action . . . . . . 4 2.4. Other Uses for External Lists . . . . . . . . . . . . . . 5
2.4. Other Uses for External Lists . . . . . . . . . . . . . . 5 2.5. Syntax of an Externally Stored List Name . . . . . . . . . 5
2.5. Syntax of an Externally Stored List Name . . . . . . . . . 5 2.6. Definition of "addrbook" URN Parameter . . . . . . . . . . 7
2.6. Definition of "addrbook" URN Parameter . . . . . . . . . . 7 2.7. Test valid_ext_list . . . . . . . . . . . . . . . . . . . 9
2.7. Test valid_ext_list . . . . . . . . . . . . . . . . . . . 9 2.8. Interaction with ManageSieve . . . . . . . . . . . . . . . 9
2.8. Interaction with ManageSieve . . . . . . . . . . . . . . . 9 2.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 10
2.9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 9 2.9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 10
2.9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 2.9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 11
2.9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 10 2.9.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 11
2.9.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 11 2.9.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . 11
2.9.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
3. Security Considerations . . . . . . . . . . . . . . . . . 12 4.1. Registration of Sieve Extension . . . . . . . . . . . . . 14
4.2. Registration of ManageSieve Capability . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 4.3. Creation of Sieve URN Parameters Registry . . . . . . . . 15
4.1. Registration of Sieve Extension . . . . . . . . . . . . . 14 4.4. Registration of the "addrbook" URN parameter . . . . . . . 16
4.2. Registration of ManageSieve Capability . . . . . . . . . . 14 4.5. Registration of "sieve" URN sub-namespace . . . . . . . . 16
4.3. Creation of Sieve URN Parameters registry . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Registration of the "addrbook" URN parameter . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Registration of "sieve" URN sub-namespace . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document specifies an extension to the Sieve language [RFC5228] This document specifies an extension to the Sieve language [RFC5228]
for checking membership in an external list or for redirecting for checking membership in an external list or for redirecting
messages to an external list of recipients. An "external list" is a messages to an external list of recipients. An "external list" is a
list whose members are stored externally to the Sieve script, such as list whose members are stored externally to the Sieve script, such as
using LDAP [RFC4510], ACAP [RFC2244], CardDAV using LDAP [RFC4510], ACAP [RFC2244], CardDAV [CardDAV], or
[I-D.ietf-vcarddav-carddav], or relational databases. relational databases.
This extension adds a new match type to apply to supported tests, and This extension adds a new match type to apply to supported tests and
a new tagged argument to the "redirect" action. a new tagged argument to the "redirect" action.
1.1. Conventions Used In This Document 1.1. Conventions Used in This Document
Conventions for notations are as in [RFC5228] section 1.1, including Conventions for notations are as in [RFC5228], Section 1.1, including
the use of ABNF [RFC5234]. the use of ABNF [RFC5234].
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Extlists Extension 2. Extlists Extension
2.1. Capability Identifier 2.1. Capability Identifier
The capability string associated with the extension defined in this The capability string associated with the extension defined in this
document is "extlists". document is "extlists".
2.2. :list Match Type for Supported Tests 2.2. :list Match Type for Supported Tests
ABNF: ABNF:
MATCH-TYPE =/ ":list" MATCH-TYPE =/ ":list"
; only valid for supported tests ; only valid for supported tests
The new ":list" match type changes the interpretation of the "key- The new ":list" match type changes the interpretation of the "key-
list" parameter (the second parameter) in supported tests. When the list" parameter (the second parameter) in supported tests. When the
match type is ":list", the key-list becomes a list of names of match type is ":list", the key-list becomes a list of names of
externally stored lists. The external lists are queried, perhaps externally stored lists. The external lists are queried, perhaps
through a list-specific mechanism, and the test evaluates to "true" through a list-specific mechanism, and the test evaluates to "true"
if any of the specified values matches any member of one or more of if any of the specified values matches any member of one or more of
the lists. the lists.
Comparators are not allowed together with the ":list" match type, so Comparators are not allowed together with the ":list" match type, so
if both are specified in a test, that MUST result in an error. if both are specified in a test, that MUST result in an error.
Queries done through list-specific mechanisms might have the effect Queries done through list-specific mechanisms might have the effect
of built-in comparators; for example, queries to certain lists might of built-in comparators; for example, queries to certain lists might
be case-sensitive, while queries to other lists might be done without be case-sensitive, while queries to other lists might be done without
regard to case. regard to case.
Implementations MUST support the use of ":list" in "address", Implementations MUST support the use of ":list" in "address",
"envelope" and "header" tests. Implementations that include the "envelope", and "header" tests. Implementations that include the
Variables extension [RFC5229] MUST also support its use in "string" Variables extension [RFC5229] MUST also support its use in "string"
tests. tests.
Implementations MAY support other tests than the ones in this Implementations MAY support other tests than the ones in this
document. Implementations MUST report an error when a script uses document. Implementations MUST report an error when a script uses
":list" with a test that does not support ":list". This error SHOULD ":list" with a test that does not support ":list". This error SHOULD
be reported at compile-time, but MAY be reported at run-time. To be reported at compile-time but MAY be reported at run-time. To
maintain interoperability, other tests that can be used with ":list" maintain interoperability, other tests that can be used with ":list"
SHOULD be documented in a specification that defines a capability SHOULD be documented in a specification that defines a capability
string that can be tested (in a "require" statement or using ihave string that can be tested (in a "require" statement or using "ihave"
[RFC5463]). [RFC5463]).
For example, testing 'header ["to", "cc"]' against a list would cause For example, testing 'header ["to", "cc"]' against a list would cause
each "to" and "cc" value, ignoring leading and trailing whitespace, each "to" and "cc" value, ignoring leading and trailing whitespace,
to be queried. If any value is found to belong to the list, the test to be queried. If any value is found to belong to the list, the test
returns "true". If no value belongs to the list, the test returns returns "true". If no value belongs to the list, the test returns
"false". Once a value is found in the list, there is no need for the "false". Once a value is found in the list, there is no need for the
query mechanism to look further. query mechanism to look further.
For some lists, the Sieve engine might directly retrieve the list and For some lists, the Sieve engine might directly retrieve the list and
skipping to change at page 5, line 34 skipping to change at page 5, line 37
If neither the Sieve engine nor the list handler can enumerate (or If neither the Sieve engine nor the list handler can enumerate (or
iterate) the list, or the list does not resolve to email addresses, iterate) the list, or the list does not resolve to email addresses,
the situation MUST result in a runtime error in the Sieve script. the situation MUST result in a runtime error in the Sieve script.
See Section 2.5 for the detailed description of syntax used for See Section 2.5 for the detailed description of syntax used for
naming externally stored lists. naming externally stored lists.
2.4. Other Uses for External Lists 2.4. Other Uses for External Lists
The uses for external lists specified here represent the useful cases The uses for external lists specified here represent known cases and
and situations at the time of this writing. Other uses for external situations at the time of this writing. Other uses for external
lists, using other Sieve features, might be devised in the future, lists, employing other Sieve features, might be devised in the
and such uses can be described in extensions to this document. future, and such uses can be described in extensions to this
document.
2.5. Syntax of an Externally Stored List Name 2.5. Syntax of an Externally Stored List Name
A name of an externally stored list is always an absolute URI A name of an externally stored list is always an absolute URI
[RFC3986]. Implementations might find URIs such as LDAP [RFC4510], [RFC3986]. Implementations might find URIs such as LDAP [RFC4510],
CardDAV [I-D.ietf-vcarddav-carddav], or Tag [RFC4151] to be useful CardDAV [CardDAV], or "tag" [RFC4151] to be useful for naming
for naming external lists. external lists.
The "tag" URI scheme [RFC4151] can be used to represent opaque, but The "tag" URI scheme [RFC4151] can be used to represent opaque, but
user friendlier identifiers. Resolution of such identifiers is going more user-friendly identifiers. Resolution of such identifiers is
to be implementation specific and it can help in hiding the going to be implementation specific and it can help in hiding the
complexity of an implementation from end users. For example, an complexity of an implementation from end users. For example, an
implementation can provide a web interface for managing lists of implementation can provide a web interface for managing lists of
users stored in LDAP. Requiring users to know generic LDAP URI users stored in LDAP. Requiring users to know generic LDAP URI
syntax might not be very practical, due to its complexity. An syntax might not be very practical, due to its complexity. An
implementation can instead use a fixed tag URI prefix such as "tag: implementation can instead use a fixed tag URI prefix such as "tag:
example.com,<date>:" (where <date> can be, for example, a date example.com,<date>:" (where <date> can be, for example, a date
generated once on installation of the web interface and left generated once on installation of the web interface and left
untouched upon upgrades) and the prefix doesn't even need to be shown untouched upon upgrades), and the prefix doesn't even need to be
to end users. shown to end users.
The "addrbook" URNs defined in Section 2.6 (in particular, the The "addrbook" URNs defined in Section 2.6 (in particular, the
reserved URI "urn:ietf:params:sieve:addrbook:default") MUST be reserved URI "urn:ietf:params:sieve:addrbook:default") MUST be
supported. To make it easier to use registered Sieve URN parameters, supported. To make it easier to use registered Sieve URN parameters,
we define a shorthand way to specify them in a Sieve script: a list we define a shorthand way to specify them in a Sieve script: a list
name that begins with ":" is taken as referencing a Sieve URN name that begins with ":" is taken as referencing a Sieve URN
parameter, with the initial ":" expanding to parameter, with the initial ":" expanding to
"urn:ietf:params:sieve:". So we have the following equivalences: "urn:ietf:params:sieve:". So we have the following equivalences:
:addrbook:default == urn:ietf:params:sieve:addrbook:default :addrbook:default == urn:ietf:params:sieve:addrbook:default
:addrbook:personal == urn:ietf:params:sieve:addrbook:personal :addrbook:personal == urn:ietf:params:sieve:addrbook:personal
...and so on. and so on.
The mandatory-to-implement URI The mandatory-to-implement URI
urn:ietf:params:sieve:addrbook:default urn:ietf:params:sieve:addrbook:default
gives access to the user's default address book (usually the user's gives access to the user's default address book (usually the user's
personal address book). Note that these are URIs, subject to normal personal address book). Note that these are URIs, subject to normal
URI encoding rules, including percent-encoding. The reserved name URI encoding rules, including percent-encoding. The reserved name
"default" MUST be considered case-insensitive after decoding. That "default" MUST be considered case-insensitive after decoding. That
means that the following URIs are all equivalent: means that the following URIs are all equivalent:
skipping to change at page 7, line 24 skipping to change at page 7, line 30
This section gives the details of the "addrbook" Sieve URN parameter This section gives the details of the "addrbook" Sieve URN parameter
that's registered in Section 4.4. URIs that use this parameter begin that's registered in Section 4.4. URIs that use this parameter begin
with "urn:ietf:params:sieve:addrbook:". with "urn:ietf:params:sieve:addrbook:".
URN parameter name: addrbook URN parameter name: addrbook
URN parameter syntax: The "addrbook" parameter is defined by the URN parameter syntax: The "addrbook" parameter is defined by the
<addrbook-urn> rule, defined using ABNF [RFC5234]: <addrbook-urn> rule, defined using ABNF [RFC5234]:
addrbook-urn = "addrbook:" addrbook [ "?" extensions ] addrbook-urn = "addrbook:" addrbook [ "?" extensions ]
addrbook = segment addrbook = segment
; <segment> defined in [RFC3986] ; <segment> defined in [RFC3986]
extensions = query extensions = query
; <query> defined in [RFC3986] ; <query> defined in [RFC3986]
Intended usage: "addrbook" URNs are used for designating references Intended usage: "addrbook" URNs are used for designating references
to address books. An address book is a concept used by different to address books. An address book is a concept used by different
applications (such as Sieve interpreters) for describing a list applications (such as Sieve interpreters) for describing a list of
of named entries, and may be translated into other types of named entries, and may be translated into other types of address
address books, such as LDAP Groups. Address books may be private books, such as LDAP groups. Address books may be private or shared;
or shared; they may be personal, organizational, or perhaps even they may be personal, organizational, or perhaps even "crowdsourced".
"crowdsourced".
The address book name (the "addrbook" element in the ABNF above) The address book name (the "addrbook" element in the ABNF above)
refers to a specifically named address book, as defined by the refers to a specifically named address book, as defined by the
implementation. A user might, for example, have access to a implementation. A user might, for example, have access to a number
number of different address books, such as a personal one, a of different address books, such as a personal one, a family one, a
family one, a company one, and one for the town where the user company one, and one for the town where the user lives.
lives.
The extension information (the "extensions" element in the ABNF The extension information (the "extensions" element in the ABNF
above) is available for use in future extensions. It might allow above) is available for use in future extensions. It might allow for
for things such as dynamic subsets of an address book -- for things such as dynamic subsets of an address book -- for example,
example, something such as this might be defined in the future: something such as this might be defined in the future:
urn:ietf:params:sieve:addrbook:personal?name.contains=fred urn:ietf:params:sieve:addrbook:personal?name.contains=fred
There are no extensions defined at this time. There are no extensions defined at this time.
An "addrbook" URN is designed to be used by applications for An "addrbook" URN is designed to be used by applications for
referencing address books. Each URN is intended to represent a referencing address books. Each URN is intended to represent a
grouping of addresses that can be logically thought of as one grouping of addresses that can be logically thought of as one
"book". Any given address can belong to more than one book -- "book". Any given address can belong to more than one book --
that is, can be referred to by more than one URN. that is, can be referred to by more than one URN.
The URI "urn:ietf:params:sieve:addrbook" has no meaning in The URI "urn:ietf:params:sieve:addrbook" has no meaning in
skipping to change at page 8, line 36 skipping to change at page 8, line 36
* personal -- a book representing the user's personal address * personal -- a book representing the user's personal address
book. book.
* friends -- a subset of * friends -- a subset of
urn:ietf:params:sieve:addrbook:personal, defined by the user. urn:ietf:params:sieve:addrbook:personal, defined by the user.
* family -- a subset of * family -- a subset of
urn:ietf:params:sieve:addrbook:personal, defined by the user. urn:ietf:params:sieve:addrbook:personal, defined by the user.
* company -- a book representing user's company's address book. * company -- a book representing the user's company's address
book.
* department -- a subset of * department -- a subset of
urn:ietf:params:sieve:addrbook:company, defined by the urn:ietf:params:sieve:addrbook:company, defined by the
company. company.
* co-workers -- a subset of * co-workers -- a subset of
urn:ietf:params:sieve:addrbook:company, defined by the user. urn:ietf:params:sieve:addrbook:company, defined by the user.
* default -- the default address book, a reference to * default -- the default address book, a reference to
urn:ietf:params:sieve:addrbook:personal. urn:ietf:params:sieve:addrbook:personal.
skipping to change at page 9, line 20 skipping to change at page 9, line 21
Contact: Sieve mailing list <sieve@ietf.org> Contact: Sieve mailing list <sieve@ietf.org>
2.7. Test valid_ext_list 2.7. Test valid_ext_list
Usage: valid_ext_list <ext-list-names: string-list> Usage: valid_ext_list <ext-list-names: string-list>
The "valid_ext_list" test is true if all of the external list names The "valid_ext_list" test is true if all of the external list names
in the ext-list-names argument are supported, and they are valid both in the ext-list-names argument are supported, and they are valid both
syntactically (including URI parameters) and semantically (including syntactically (including URI parameters) and semantically (including
implementation-specific semantic restrictions). Otherwise the test implementation-specific semantic restrictions). Otherwise, the test
returns false. returns false.
This test MUST perform exactly the same validation of an external This test MUST perform exactly the same validation of an external
list name as would be performed by the "header :list" test. list name as would be performed by the "header :list" test.
2.8. Interaction with ManageSieve 2.8. Interaction with ManageSieve
This extension defines the following new capability for ManageSieve This extension defines the following new capability for ManageSieve
(see [RFC5804] section 1.7): (see [RFC5804], Section 1.7):
EXTLISTS - A space-separated list of URI schema parts [RFC3986] for EXTLISTS - A space-separated list of URI schema parts [RFC3986] for
supported externally stored list types. This capability MUST be supported externally stored list types. This capability MUST be
returned if the corresponding Sieve implementation supports the returned if the corresponding Sieve implementation supports the
"extlists" extension defined in this document. "extlists" extension defined in this document.
This also extends the ManageSieve ABNF as follows: This also extends the ManageSieve ABNF as follows:
single-capability =/ DQUOTE "EXTLISTS" DQUOTE SP ext-list-types CRLF single-capability =/ DQUOTE "EXTLISTS" DQUOTE SP ext-list-types CRLF
; single-capability is defined in [RFC5804] ; single-capability is defined in [RFC5804]
skipping to change at page 10, line 38 skipping to change at page 10, line 45
set "lim" "3"; /* Unknown: less tolerance in spam score */ set "lim" "3"; /* Unknown: less tolerance in spam score */
} }
if spamtest :value "ge" :comparator "i;ascii-numeric" "${lim}" { if spamtest :value "ge" :comparator "i;ascii-numeric" "${lim}" {
fileinto "spam"; fileinto "spam";
} }
2.9.2. Example 2 2.9.2. Example 2
This example uses the "currentdate" test [RFC5260] and a list This example uses the "currentdate" test [RFC5260] and a list
containing the dates of local holidays. If today is a holiday, the containing the dates of local holidays. If today is a holiday, the
script will notify [RFC5435] the user via XMPP [RFC5437] about the script will notify (as described in [RFC5435]) the user via the
Extensible Messaging and Presence Protocol (XMPP) [RFC5437] about the
message. message.
require ["extlists", "date", "enotify"]; require ["extlists", "date", "enotify"];
if currentdate :list "date" if currentdate :list "date"
"tag:example.com,2011-01-01:localHolidays" { "tag:example.com,2011-01-01:localHolidays" {
notify "xmpp:romeo@im.example.com"; notify "xmpp:romeo@im.example.com";
} }
2.9.3. Example 3 2.9.3. Example 3
skipping to change at page 12, line 14 skipping to change at page 12, line 19
require [ "extlists", "foreverypart", "mime", "enclose" ]; require [ "extlists", "foreverypart", "mime", "enclose" ];
foreverypart foreverypart
{ {
if header :mime :param "filename" if header :mime :param "filename"
:list ["Content-Type", "Content-Disposition"] :list ["Content-Type", "Content-Disposition"]
"tag:example.com,2011-04-10:BadFileNameExts" "tag:example.com,2011-04-10:BadFileNameExts"
{ {
# these attachment types are executable # these attachment types are executable
enclose :subject "Warning" :text enclose :subject "Warning" :text
WARNING! The enclosed message attachments that might be unsafe. WARNING! The enclosed message has attachments that might be unsafe.
These attachment types may contain a computer virus program These attachment types may contain a computer virus program
that can infect your computer and potentially damage your data. that can infect your computer and potentially damage your data.
Before clicking on these message attachments, you should verify Before clicking on these message attachments, you should verify
with the sender that this message was sent intentionally, and with the sender that this message was sent intentionally, and
that the attachments are safe to open. that the attachments are safe to open.
. .
; ;
break; break;
} }
skipping to change at page 13, line 26 skipping to change at page 13, line 31
external data to have unusual, and perhaps unauthorized, control of external data to have unusual, and perhaps unauthorized, control of
the script -- and, consequently, of the disposition of the user's the script -- and, consequently, of the disposition of the user's
email. A user using such a list for spam control, for example, might email. A user using such a list for spam control, for example, might
find important mail being discarded because of tampering with the find important mail being discarded because of tampering with the
list. Someone using redirect to an external list could have her list. Someone using redirect to an external list could have her
email redirected to the wrong eyes because of such tampering. email redirected to the wrong eyes because of such tampering.
Security and integrity protection of external lists is as important Security and integrity protection of external lists is as important
as protection of the Sieve script itself. as protection of the Sieve script itself.
Implementations of this extension should keep in mind that matching Implementations of this extension should keep in mind that matching
values against an externally stored list can be IO and/or CPU values against an externally stored list can be I/O and/or CPU
intensive. This can be used to deny service to the mailserver and/or intensive. This can be used to deny service to the mail server
to servers providing access to externally stored mailing lists. A and/or to servers providing access to externally stored mailing
naive implementation, such as the one that tries to retrieve content lists. A naive implementation, such as the one that tries to
of the whole list to perform matching can make this worse. retrieve content of the whole list to perform matching, can make this
worse.
But note that many protocols that can be used for accessing But note that many protocols that can be used for accessing
externally stored lists support flexible searching features that can externally stored lists support flexible searching features that can
be used to minimize network traffic and load on the directory be used to minimize network traffic and load on the directory
service. For example, LDAP allows for search filters. service. For example, LDAP allows for search filters.
Implementations SHOULD use such features whenever they can. Implementations SHOULD use such features whenever they can.
Many organizations support external lists with thousands of Many organizations support external lists with thousands of
recipients. In order to avoid mailbombs when redirecting a message recipients. In order to avoid mailbombs when redirecting a message
to an externally stored list, implementations SHOULD enforce limits to an externally stored list, implementations SHOULD enforce limits
on the number of recipients and/or on domains to which such on the number of recipients and/or on domains to which such
recipients belong. recipients belong.
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"
URNs 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 has been
added to the list of sieve extensions given on added to the Sieve Extensions registry on http://www.iana.org.
http://www.iana.org/assignments/sieve-extensions.
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
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: RFC 6134
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 IANA has registered a new ManageSieve Capability according to the
according to the IANA registration template specified in [RFC5804]: 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" [[this RFC]] Sieve extension. "extlists" RFC 6134 Sieve extension.
Relevant publications: [[this RFC]], Section 2.8 Relevant publications: RFC 6134, Section 2.8
Person & email address to contact for further information: Sieve Person & email address to contact for further information:
mailing list <sieve@ietf.org> Sieve 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 IANA has created a new registry under "Sieve Extensions" for Sieve
Extensions" for Sieve URN Parameters. Registration into this URN Parameters. Registration into this registry is according to the
registry is according to the "Specification Required" policy "Specification Required" policy [RFC5226].
[RFC5226].
The registry will contain the following two items: The registry contains the following two items:
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. Be sure to include the section number as parameter can be found. Be sure to include the section number as
well as the document reference, so the documentation is easy to well as the document reference, so the documentation is easy to
find. find.
skipping to change at page 16, line 9 skipping to change at page 16, line 7
interoperability issues. This is where to put mandatory-to- interoperability issues. This is where to put mandatory-to-
implement sub-parameters and the like. implement sub-parameters and the like.
Security considerations: Any notes specific to security and Security considerations: Any notes specific to security and
privacy issues. privacy issues.
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 IANA has registered a new Sieve URN parameter in the registry defined
the registry defined in Section 4.3. in Section 4.3.
URN parameter name: addrbook URN parameter name: addrbook
Reference: [[this RFC]], Section 2.6 Reference: RFC 6134, 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 IANA has registered a new URN sub-namespace within the IETF URN Sub-
within the IETF URN Sub-namespace for Registered Protocol Parameter namespace for Registered Protocol Parameter Identifiers defined in
Identifiers defined in [RFC3553]. [RFC3553].
Registry name: sieve Registry name: sieve
Specification: [[this RFC]] Specification: RFC 6134
Repository: [[the registry created in Section 4.3]] Repository: Sieve URN Parameters registry (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.
6. References 6. References
6.1. Normative References 6.1. Normative References
[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
skipping to change at page 17, line 20 skipping to change at page 17, line 16
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
[I-D.ietf-vcarddav-carddav] [CardDAV] Daboo, C., "vCard Extensions to WebDAV (CardDAV)", Work
Daboo, C., "vCard Extensions to WebDAV (CardDAV)", in Progress, November 2009.
draft-ietf-vcarddav-carddav-10 (work in progress),
November 2009.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003. Parameters", BCP 73, RFC 3553, June 2003.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
skipping to change at page 18, line 26 skipping to change at page 18, line 21
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
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
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
 End of changes. 51 change blocks. 
144 lines changed or deleted 132 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/