idnits 2.17.1 draft-ietf-sieve-external-lists-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2009) is 5354 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track B. Leiba 5 Expires: March 1, 2010 Huawei Technologies 6 August 28, 2009 8 Sieve Extension: Externally Stored Lists 9 draft-ietf-sieve-external-lists-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 1, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Sieve scripting language can be used to implement whitelisting, 48 blacklisting, and personal distribution lists. Currently, this 49 requires that all members of such lists be hardcoded in the script 50 itself. Whenever a member of a list is added or deleted, the script 51 needs to be updated and possibly uploaded to a mail server. 53 This document defines a Sieve extension for accessing externally 54 stored lists -- lists whose members are stored externally to the 55 script, such as using LDAP (RFC 4510), ACAP (RFC 2244), or relational 56 databases. 58 ToDo 60 o Need a way to advertise supported URI schemas in ManageSieve and 61 ihave. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Conventions used in this document . . . . . . . . . . . . . . 3 68 2. Extlists extension . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3 70 2.2. :list match type for "address", "envelope", and "header" 71 tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.3. :list tagged argument to the "redirect" action . . . . . . . 4 73 2.4. Syntax of an externally stored list name . . . . . . . . . . 5 74 2.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 84 6.2. Informative References . . . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction 90 This document specifies an extension to the Sieve language [Sieve] 91 for checking membership in an external list or for redirecting 92 messages to an external list of recipients. An "external list" is a 93 list whose members are stored externally to the Sieve script, such as 94 using LDAP [LDAP], ACAP [ACAP], or relational databases. 96 This extension adds a new match type to the "address", "envelope", 97 and "header" tests, and a new tagged argument to the "redirect" 98 action. 100 1.1. Conventions used in this document 102 Conventions for notations are as in [Sieve] section 1.1, including 103 the use of [ABNF]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [Kwds]. 109 2. Extlists extension 111 2.1. Capability Identifier 113 The capability string associated with the extension defined in this 114 document is "extlists". 116 2.2. :list match type for "address", "envelope", and "header" tests 118 ABNF: 120 MATCH-TYPE =/ ":list" 122 The new ":list" match type changes the interpretation of the "key- 123 list" parameter (the second parameter) to the 124 "address"/"envelope"/"header" test. [[anchor4: This is not quite 125 right. Ned convinced me that this new match type can apply to other 126 tests as well.]] When the match type is ":list", the key-list 127 becomes a list of names of externally stored lists. The external 128 lists are queried, perhaps through a list-specific mechanism, and the 129 test evaluates to "true" if any of the specified values matches any 130 member of one or more of the lists. 132 For example, testing ':header ["to", "cc"]' against a list would 133 cause each "to" and "cc" value, ignoring leading and trailing 134 whitespace, to be queried. When any value is found to belong to the 135 list, the queries may stop and the test returns "true". If no value 136 belongs to the list, the test returns "false". 138 For some lists, the Sieve engine might directly retrieve the list and 139 make its own comparison. Other lists might not work that way -- they 140 might provide a way to ask if a value is in the list, but not permit 141 retrieval of the list itself. It is up to the Sieve implementation 142 to understand how to interact with any supported list. If the Sieve 143 engine is permanently unable to query the list (perhaps because the 144 list doesn't support the required operation), the test MUST result in 145 a runtime error in the Sieve script. 147 See Section 2.4 for the detailed description of syntax used for 148 naming externally stored lists. 150 2.3. :list tagged argument to the "redirect" action 152 Usage: redirect :list 154 The "redirect" action with the ":list" argument is used to send the 155 message to one or more email addresses stored in the externally 156 stored list 'ext-list-name'. This variant of the redirect command 157 can be used to implement a personal distribution list. 159 Use of this feature requires that the list resolve to a list of email 160 addresses, and that the Sieve engine be able to enumerate those 161 addresses. [[anchor6: Alexey would like the option of allowing the 162 list handler to enumerate the addresses and do the redirect there. 163 (Ned seems to agree that this should be allowed.) Barry thinks 164 that's contrary to Sieve, which expects to queue the redirect action 165 for processing at a later stage, and that it would be a bad idea to 166 have the redirect happen in the list handler. The WG needs to 167 resolve this issue.]] In cases where, for example, a list contains 168 hashed email address values or an email address pattern ("sz*@ 169 example.com", "*+ietf@example.net"), it will not be possible to 170 redirect to that list. 172 If the Sieve engine [[anchor7: or list handler?]] is permanently 173 unable to enumerate the list or the list does not resolve to email 174 addresses, the situation MUST result in a runtime error in the Sieve 175 script. 177 See Section 2.4 for the detailed description of syntax used for 178 naming externally stored lists. 180 2.4. Syntax of an externally stored list name 182 A name of an externally stored list is always an absolute URI [URI]. 183 Implementations might find URLs such as [LDAP], [CardDAV], or 184 [TAG-URI] to be useful for naming external lists. 186 The "tag" URI scheme [TAG-URI] can be used to represent opaque, but 187 user friendlier identifiers. Resolution of such identifiers is going 188 to be implementation specific and it can help in hiding the 189 complexity of an implementation from end users. For example, an 190 implementation can provide a web interface for managing lists of 191 users stored in LDAP. Requiring users to know generic LDAP URL 192 syntax might not be very practical, due to its complexity. An 193 implementation can instead use a fixed tag URI prefix such as "tag: 194 example.com,:" (where can be, for example, a date 195 generated once on installation of the web interface and left 196 untouched upon upgrades) and the prefix doesn't even need to be shown 197 to end users. 199 2.5. Examples 201 [[anchor8: Barry: This example looks wrong: the "envelope" test is 202 probably not right. Should it really be using the :list test? It's 203 testing :detail, so I think it should just be a simple test, maybe ' 204 :is "mylist" ' or some such. No? Alexey: I think this test is 205 correct. This is checking for known plus addresses (parts).]] 207 Example 1 uses the "envelope" option [Sieve] and the "subaddress" 208 extension [Subaddress]: 210 require ["extlists", "envelope", "subaddress"]; 212 # Submission from list members is sent to all members 213 if allof (envelope :detail :list "to" 214 "tag:example.com,2009-05-28:mylist", 215 header :list "from" 216 "tag:example.com,2009-05-28:mylist") { 217 redirect :list "tag:example.com,2009-05-28:mylist"; 218 } 220 3. Security Considerations 222 Security considerations related to the "address"/"envelope"/"header" 223 tests and "redirect" action discussed in [Sieve] also apply to this 224 document. 226 A failure to retrieve data due to the server storing the external 227 list membership being down or otherwise inaccessible may alter the 228 result of Sieve processing. Implementations SHOULD treat a temporary 229 failure to retrieve or verify external list membership in the same 230 manner as a temporary failure to retrieve a Sieve script. For 231 example, if the Sieve script is stored in the Lightweight Directory 232 Access Protocol [LDAP] and the script can't be retrieved when a 233 message is processed, then the agent performing Sieve processing can 234 either assume that the script doesn't exist or delay message delivery 235 until the script can be retrieved successfully. External list 236 memberships should be treated as if they are a part of the script 237 itself, so a temporary failure to retrieve or query them should be 238 handled in the same way as a temporary failure to retrieve the Sieve 239 script itself. 241 Protocols/APIs used to retrieve/verify external list membership MUST 242 provide an appropriate level of confidentiality and authentication. 243 Usually, that will be at least the same level of confidentiality as 244 protocols/APIs used to retrieve Sieve scripts, but only the 245 implementation (or deployment) will know what is appropriate. 246 There's a difference, for example, between making an LDAP request on 247 a closed LAN that's only used for trusted servers (it may be that 248 neither encryption nor authentication is needed), on a firewalled LAN 249 internal to a company (it might be OK to skip encryption, depending 250 upon policy), and on the open Internet (encryption and authentication 251 are probably both required). It also matters whether the list being 252 accessed is private or public (no encryption or authentication may be 253 needed for public data, even on the Internet). 255 Implementations of this extensions should keep in mind that matching 256 values against an externally stored list can be IO and/or CPU 257 intensive. This can be used to deny service to the mailserver and/or 258 to servers providing access to externally stored mailing lists. A 259 naive implementation, such as the one that tries to retrieve content 260 of the whole list to perform matching can make this worse. But note 261 that many protocols that can be used for accessing externally stored 262 lists support flexible searching features that can be used to 263 minimize network traffic and load on the directory service. For 264 example, LDAP allows for search filters. Implementations SHOULD use 265 such features whenever they can. 267 Many organizations support external lists with thousands of 268 recipients. In order to avoid mailbombs when redirecting a message 269 to an externally stored list, implementations SHOULD enforce limits 270 on the number of recipients and/or on domains to which such 271 recipients belong. 273 4. IANA Considerations 275 The following template specifies the IANA registration of the notify 276 Sieve extension specified in this document: 278 To: iana@iana.org 279 Subject: Registration of new Sieve extension 280 Capability name: extlists 281 Description: adds the ':list' tagged argument to 'address', 'header' 282 and 'envelope' tests, and to the 'redirect' action. The ':list' 283 argument changes address/header/envelope test to match values against 284 values stored in one or more externally stored list. The ':list' 285 argument to the redirect action changes the redirect action to 286 forward the message to email addresses stored in the externally 287 stored list. 288 RFC number: this RFC 289 Contact address: 290 The Sieve discussion list 292 This information should be added to the list of sieve extensions 293 given on http://www.iana.org/assignments/sieve-extensions. 295 5. Acknowledgements 297 Thanks to Alexandros Vellis, Barry Leiba, Nigel Swinson, Kjetil 298 Torgrim Homme, Dave Cridland, Cyrus Daboo, Pete Resnick for ideas, 299 comments and suggestions. 301 6. References 303 6.1. Normative References 305 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 306 Specifications: ABNF", RFC 5234, January 2008. 308 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", RFC 2119, March 1997. 311 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 312 Language", RFC 5228, January 2008. 314 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 315 Resource Identifier (URI): Generic Syntax", STD 66, 316 RFC 3986, January 2005. 318 6.2. Informative References 320 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 321 Configuration Access Protocol", RFC 2244, November 1997. 323 [CardDAV] Daboo, C., "vCard Extensions to WebDAV (CardDAV)", work in 324 progress, draft-ietf-vcarddav-carddav, July 2009. 326 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 327 (LDAP): Technical Specification Road Map", RFC 4510, 328 June 2006. 330 [Subaddress] 331 Murchison, K., "Sieve Email Filtering: Subaddress 332 Extension", RFC 5233, January 2008. 334 [TAG-URI] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 335 RFC 4151, October 2005. 337 Authors' Addresses 339 Alexey Melnikov 340 Isode Limited 341 5 Castle Business Village 342 36 Station Road 343 Hampton, Middlesex TW12 2BX 344 UK 346 Email: Alexey.Melnikov@isode.com 348 Barry Leiba 349 Huawei Technologies 350 USA 352 Phone: +1 646 827 0648 353 Email: barryleiba@computer.org 354 URI: http://internetmessagingtechnology.org/