idnits 2.17.1 draft-ietf-sieve-external-lists-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 21, 2011) is 4752 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) == Missing Reference: 'RFCXXXX' is mentioned on line 505, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4151 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: October 23, 2011 Huawei Technologies 6 April 21, 2011 8 Sieve Extension: Externally Stored Lists 9 draft-ietf-sieve-external-lists-07 11 Abstract 13 The Sieve scripting language can be used to implement whitelisting, 14 blacklisting, personal distribution lists, and other sorts of list 15 matching. Currently, this requires that all members of such lists be 16 hardcoded in the script itself. Whenever a member of a list is added 17 or deleted, the script needs to be updated and possibly uploaded to a 18 mail server. 20 This document defines a Sieve extension for accessing externally 21 stored lists -- lists whose members are stored externally to the 22 script, such as using LDAP (RFC 4510), ACAP (RFC 2244), CardDAV (work 23 in progress), or relational databases. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 23, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 62 2. Extlists Extension . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Capability Identifier . . . . . . . . . . . . . . . . . . 3 64 2.2. :list Match Type for Supported Tests . . . . . . . . . . . 3 65 2.3. :list Tagged Argument to the "redirect" Action . . . . . . 4 66 2.4. Other Uses for External Lists . . . . . . . . . . . . . . 5 67 2.5. Syntax of an Externally Stored List Name . . . . . . . . . 5 68 2.6. Test valid_ext_list . . . . . . . . . . . . . . . . . . . 6 69 2.7. Interaction with ManageSieve . . . . . . . . . . . . . . . 6 70 2.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.8.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.8.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 8 75 2.8.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3. Security Considerations . . . . . . . . . . . . . . . . . 9 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 80 4.1. Registration of Sieve Extension . . . . . . . . . . . . . 11 81 4.2. Registration of ManageSieve Capability . . . . . . . . . . 11 82 4.3. Registration of "ab" URI Scheme . . . . . . . . . . . . . 12 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 This document specifies an extension to the Sieve language [RFC5228] 95 for checking membership in an external list or for redirecting 96 messages to an external list of recipients. An "external list" is a 97 list whose members are stored externally to the Sieve script, such as 98 using LDAP [RFC4510], ACAP [RFC2244], CardDAV 99 [I-D.ietf-vcarddav-carddav], or relational databases. 101 This extension adds a new match type to apply to supported tests, and 102 a new tagged argument to the "redirect" action. 104 1.1. Conventions Used In This Document 106 Conventions for notations are as in [RFC5228] section 1.1, including 107 the use of [RFC5234]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Extlists Extension 115 2.1. Capability Identifier 117 The capability string associated with the extension defined in this 118 document is "extlists". 120 2.2. :list Match Type for Supported Tests 122 ABNF: 124 MATCH-TYPE =/ ":list" 125 ; only valid for supported tests 127 The new ":list" match type changes the interpretation of the "key- 128 list" parameter (the second parameter) in supported tests. When the 129 match type is ":list", the key-list becomes a list of names of 130 externally stored lists. The external lists are queried, perhaps 131 through a list-specific mechanism, and the test evaluates to "true" 132 if any of the specified values matches any member of one or more of 133 the lists. 135 Comparators are not allowed together with the ":list" match type, so 136 if both are specified in a test, that MUST result in an error. 137 Queries done through list-specific mechanisms might have the effect 138 of built-in comparators; for example, queries to certain lists might 139 be case-sensitive, while queries to other lists might be done without 140 regard to case. 142 Implementations MUST support the use of :list in "address", 143 "envelope" and "header" tests. Implementations that include the 144 Variables extension [RFC5229] MUST also support its use in "string" 145 tests. 147 Implementations MAY support other tests but MUST raise an error 148 (which SHOULD be a compile-time error, but MAY be a runtime error) 149 when a script uses :list with a test for which it is not supported. 150 To maintain interoperability, other tests that can be used with :list 151 SHOULD be documented in a specification that defines a capability 152 string that can be tested (in a "require" statement, or using ihave 153 [RFC5463]). 155 For example, testing 'header ["to", "cc"]' against a list would cause 156 each "to" and "cc" value, ignoring leading and trailing whitespace, 157 to be queried. If any value is found to belong to the list, the test 158 returns "true". If no value belongs to the list, the test returns 159 "false". Once a value is found in the list, there is no need for the 160 query mechanism to look further. 162 For some lists, the Sieve engine might directly retrieve the list and 163 make its own comparison. Other lists might not work that way -- they 164 might provide a way to ask if a value is in the list, but not permit 165 retrieval of the list itself. It is up to the Sieve implementation 166 to understand how to interact with any supported list. If the Sieve 167 engine is permanently unable to query the list (perhaps because the 168 list doesn't support the required operation), the test MUST result in 169 a runtime error in the Sieve script. 171 See Section 2.5 for the detailed description of syntax used for 172 naming externally stored lists. 174 The :list match type uses the concept of "match variables" as defined 175 in Section 3.2 of the Variables extension [RFC5229]. Implementations 176 that also support that extension MUST set the ${0} match variable to 177 the value in the list that matched the query. Other numbered match 178 variables (${1}, ${2}, and so on) MAY be set with list-specific 179 information that might be of use to the script. 181 2.3. :list Tagged Argument to the "redirect" Action 182 Usage: redirect :list 184 The "redirect" action with the ":list" argument is used to send the 185 message to the set of email addresses in the externally stored list 186 named by the ext-list-name string. This variant of the redirect 187 command can be used to implement a personal distribution list. 189 For this feature to work, one of the following conditions has to be 190 true: 192 1. The list resolves to a list of email addresses, and the Sieve 193 engine is able to enumerate those addresses. 195 2. The list handler is able to take care of the redirection on 196 behalf of the Sieve engine. 198 In cases where, for example, a list contains hashed email address 199 values or an email address pattern ("sz*@example.com", 200 "*+ietf@example.net"), the Sieve engine will not be able to redirect 201 to that list, and responsibility must pass to the list handler. 203 If neither the Sieve engine nor the list handler can enumerate (or 204 iterate) the list, or the list does not resolve to email addresses, 205 the situation MUST result in a runtime error in the Sieve script. 207 See Section 2.5 for the detailed description of syntax used for 208 naming externally stored lists. 210 2.4. Other Uses for External Lists 212 The uses for external lists specified here represent the useful cases 213 and situations at the time of this writing. Other uses for external 214 lists, using other Sieve features, might be devised in the future, 215 and such uses can be described in extensions to this document. 217 2.5. Syntax of an Externally Stored List Name 219 A name of an externally stored list is always an absolute URI 220 [RFC3986]. Implementations might find URIs such as LDAP [RFC4510], 221 CardDAV [I-D.ietf-vcarddav-carddav], or Tag [RFC4151] to be useful 222 for naming external lists. 224 The "tag" URI scheme [RFC4151] can be used to represent opaque, but 225 user friendlier identifiers. Resolution of such identifiers is going 226 to be implementation specific and it can help in hiding the 227 complexity of an implementation from end users. For example, an 228 implementation can provide a web interface for managing lists of 229 users stored in LDAP. Requiring users to know generic LDAP URI 230 syntax might not be very practical, due to its complexity. An 231 implementation can instead use a fixed tag URI prefix such as "tag: 232 example.com,:" (where can be, for example, a date 233 generated once on installation of the web interface and left 234 untouched upon upgrades) and the prefix doesn't even need to be shown 235 to end users. 237 The "ab" URI scheme (in particular, the URI "ab:default"), defined in 238 Section 4.3 MUST be supported. The mandatory-to-implement URI "ab: 239 default" gives access to the user's default address book (usually the 240 user's personal address book). 242 It's possible that a server will have no access to anything 243 resembling an address book (perhaps in an implementation where 244 address books are only client-side things), but the server can still 245 provide access to other sorts of lists -- consider the list of dates 246 in Example 2 (Section 2.8.2), or lists of important keywords and the 247 like. It might sometimes make sense to map "ab:default" into some 248 available list, but that might not always be reasonable. If there 249 really is no concept of an address book in a particular server 250 implementation, the server MAY support "ab:default" by having all 251 matches to it fail. Such an implementation SHOULD NOT be done except 252 as a last resort. 254 Queries against address books SHOULD be done without regard to case. 256 2.6. Test valid_ext_list 258 Usage: valid_ext_list 260 The "valid_ext_list" test is true if all of the external list names 261 in the ext-list-names argument are supported, and they are valid both 262 syntactically (including URI parameters) and semantically (including 263 implementation-specific semantic restrictions). Otherwise the test 264 returns false. 266 This test MUST perform exactly the same validation of an external 267 list name as would be performed by the "header :list" test. 269 2.7. Interaction with ManageSieve 271 This extension defines the following new capability for ManageSieve 272 (see [RFC5804] section 1.7): 274 EXTLISTS - A space-separated list of URI schema parts [RFC3986] for 275 supported externally stored list types. This capability MUST be 276 returned if the corresponding Sieve implementation supports the 277 "extlists" extension defined in this document. 279 This also extends the ManageSieve ABNF as follows: 281 single-capability =/ DQUOTE "EXTLISTS" DQUOTE SP ext-list-types CRLF 282 ; single-capability is defined in [RFC5804] 284 ext-list-types = string 285 ; space separated list of URI schema parts 286 ; for supported externally stored list types. 287 ; MUST NOT be empty. 289 2.8. Examples 291 2.8.1. Example 1 293 This example uses a personal address book, along with the Spamtest 294 [RFC5235] and Relational [RFC5231] extensions to give a different 295 level of spam tolerance to known senders. 297 require ["envelope", "extlists", "fileinto", "spamtest", 298 "relational", "comparator-i;ascii-numeric"]; 299 if envelope :list "from" "ab:default" 300 { /* Known: allow high spam score */ 301 if spamtest :value "ge" :comparator "i;ascii-numeric" "8" 302 { 303 fileinto "spam"; 304 } 305 } 306 elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3" 307 { /* Unknown: less tolerance in spam score */ 308 fileinto "spam"; 309 } 311 The same example can also be written another way, if the Variables 312 extension [RFC5229] is also supported: 314 require ["envelope", "extlists", "fileinto", "spamtest", 315 "variables", "relational", "comparator-i;ascii-numeric"]; 316 if envelope :list "from" "ab:default" { 317 set "lim" "8"; /* Known: allow high spam score */ 318 } else { 319 set "lim" "3"; /* Unknown: less tolerance in spam score */ 320 } 321 if spamtest :value "ge" :comparator "i;ascii-numeric" "${lim}" { 322 fileinto "spam"; 323 } 325 2.8.2. Example 2 327 This example uses the "currentdate" test [RFC5260] and a list 328 containing the dates of local holidays. If today is a holiday, the 329 script will notify [RFC5435] the user via XMPP [RFC5437] about the 330 message. 332 require ["extlists", "date", "enotify"]; 333 if currentdate :list "date" 334 "tag:example.com,2011-01-01:localHolidays" { 335 notify "xmpp:romeo@im.example.com"; 336 } 338 2.8.3. Example 3 340 This example also uses the "envelope" option [RFC5228] and the 341 Subaddress extension [RFC5233]. If mail is sent with the list name 342 as a subaddress of the recipient (to, say, "alexey+mylist"), and the 343 message comes from a member of the list, it will be redirected to all 344 members of the list. Variants of this technique might be useful for 345 creating private mailing lists. 347 require ["extlists", "envelope", "subaddress"]; 349 # Submission from list members is sent to all members 350 if allof (envelope :detail "to" "mylist", 351 header :list "from" 352 "tag:example.com,2010-05-28:mylist") { 353 redirect :list "tag:example.com,2010-05-28:mylist"; 354 } 356 2.8.4. Example 4 358 This example uses variable matching [RFC5229] to extract the IP 359 address from the last "Received" header field. It then checks that 360 against a "block list" of undesirable IP addresses, and rejects the 361 message if there's a match. 363 require ["variables", "extlists", "index", "reject"]; 364 if header :index 1 :matches "received" "*(* [*.*.*.*])*" { 365 set "ip" "${3}.${4}.${5}.${6}"; 366 if string :list "${ip}" 367 "tag:example.com,2011-04-10:DisallowedIPs" { 368 reject "Message not allowed from this IP address"; 369 } 370 } 372 2.8.5. Example 5 374 This example uses several features of the MIME parts extension 375 [RFC5703] to scan for unsafe attachment types. To make it easily 376 extensible, the unsafe types are kept in an external list, which 377 would be shared among all users and all scripts, avoiding the need to 378 change scripts when the list changes. 380 [Note that this is an illustrative example, and more rigorous malware 381 filtering is advisable. It is insufficient to base email security on 382 checks of filenames alone.] 384 require [ "extlists", "foreverypart", "mime", "enclose" ]; 386 foreverypart 387 { 388 if header :mime :param "filename" 389 :list ["Content-Type", "Content-Disposition"] 390 "tag:example.com,2011-04-10:BadFileNameExts" 391 { 392 # these attachment types are executable 393 enclose :subject "Warning" :text 394 WARNING! The enclosed message attachments that might be unsafe. 395 These attachment types may contain a computer virus program 396 that can infect your computer and potentially damage your data. 398 Before clicking on these message attachments, you should verify 399 with the sender that this message was sent intentionally, and 400 that the attachments are safe to open. 401 . 402 ; 403 break; 404 } 405 } 407 3. Security Considerations 409 Security considerations related to the "address"/"envelope"/"header" 410 tests and "redirect" action discussed in Sieve [RFC5228] also apply 411 to this document. 413 External list memberships ought to be treated as if they are an 414 integral part of the script, so a temporary failure to access an 415 external list SHOULD be handled in the same way as a temporary 416 failure to retrieve the Sieve script itself. 418 For example, if the Sieve script is stored in the Lightweight 419 Directory Access Protocol [RFC4510] and the script can't be retrieved 420 when a message is processed (perhaps the LDAP server is unavailable), 421 then the Sieve engine might delay message delivery until the script 422 can be retrieved successfully. Similarly, if an external list is 423 stored in LDAP and that LDAP server is unavailable, the Sieve engine 424 would take the same action -- delay message delivery and try again 425 later. 427 Protocols/APIs used to retrieve/verify external list membership MUST 428 provide an appropriate level of confidentiality and authentication. 429 Usually, that will be at least the same level of confidentiality as 430 protocols/APIs used to retrieve Sieve scripts, but only the 431 implementation (or deployment) will know what is appropriate. 432 There's a difference, for example, between making an LDAP request on 433 a closed LAN that's only used for trusted servers (it may be that 434 neither encryption nor authentication is needed), on a firewalled LAN 435 internal to a company (it might be OK to skip encryption, depending 436 upon policy), and on the open Internet (encryption and authentication 437 are probably both required). It also matters whether the list being 438 accessed is private or public (no encryption or authentication may be 439 needed for public data, even on the Internet). 441 Implementations of this extension should keep in mind that matching 442 values against an externally stored list can be IO and/or CPU 443 intensive. This can be used to deny service to the mailserver and/or 444 to servers providing access to externally stored mailing lists. A 445 naive implementation, such as the one that tries to retrieve content 446 of the whole list to perform matching can make this worse. 448 But note that many protocols that can be used for accessing 449 externally stored lists support flexible searching features that can 450 be used to minimize network traffic and load on the directory 451 service. For example, LDAP allows for search filters. 452 Implementations SHOULD use such features whenever they can. 454 Many organizations support external lists with thousands of 455 recipients. In order to avoid mailbombs when redirecting a message 456 to an externally stored list, implementations SHOULD enforce limits 457 on the number of recipients and/or on domains to which such 458 recipients belong. 460 Note in particular that it can be too easy for a script to use 461 redirect :list "ab:default"; 462 to send messages to "everyone in your address book", and one can 463 easily imagine both intentional and accidental abuse. The situation 464 can be even worse for, say, "ab:corporate". Warnings, as well as 465 enforced limits, are appropriate here. 467 4. IANA Considerations 469 4.1. Registration of Sieve Extension 471 The following template specifies the IANA registration of the Sieve 472 extension specified in this document. This information should be 473 added to the list of sieve extensions given on 474 http://www.iana.org/assignments/sieve-extensions. 476 To: iana@iana.org 478 Subject: Registration of new Sieve extension 480 Capability name: extlists 482 Description: Adds the ":list" match type to certain Sieve tests, and 483 the ":list" argument to the "redirect" action. The ":list" match 484 type changes tests to match values against values stored in one 485 or more externally stored lists. The ":list" argument to the 486 redirect action changes the redirect action to forward the 487 message to email addresses stored in the externally stored list. 489 RFC number: this RFC 491 Contact address: Sieve mailing list 493 4.2. Registration of ManageSieve Capability 495 The following requests IANA to register a new ManageSieve Capability 496 according to the IANA registration template specified in [RFC5804]: 498 To: iana@iana.org 500 Subject: ManageSieve Capability Registration 502 Capability name: extlists 504 Description: This capability is returned if the server supports the 505 "extlists" [RFCXXXX] Sieve extension. 507 Relevant publications: this RFC, Section 2.7 509 Person & email address to contact for further information: Sieve 510 mailing list 512 Author/Change controller: IESG 514 4.3. Registration of "ab" URI Scheme 516 The following requests IANA to register a new URI scheme according to 517 the IANA registration template specified in [RFC4395]: 519 URI scheme name: ab 521 Status: Permanent 523 URI scheme syntax: 524 paburi = "ab:" addrbook [ "?" extensions ] 525 addrbook = segment 526 ; defined in [RFC3986] 527 extensions = query 528 ; defined in [RFC3986] 530 URI scheme semantics: "ab" URIs are used for designating references 531 to address books. An address book is an internal concept used by 532 different applications (such as Sieve interpreters) for 533 describing a list of named entries, and may be translated into 534 other types of address books, such as LDAP Groups. Address books 535 may be private or shared; they may be personal, organizational, 536 or perhaps even "crowdsourced". 538 Encoding considerations: Percent-encoding is allowed in "segment" 539 and "query" components. Internationalization is handled by IRI 540 processing. 542 Intended usage: An "ab" URI is designed to be used internally by 543 applications for referencing address books. Each URI is intended 544 to represent a grouping of addresses that can be logically 545 thought of as one "book". Any given address can belong to more 546 than one book -- that is, can be referred to by more than one 547 URI. 549 The URI "ab:default" is a reserved name that MUST be implemented, 550 representing a default grouping (book) of addresses. Other 551 names, representing the same or other groupings MAY be 552 implemented. For example, an implementation might have the 553 following URIs: 555 * ab:personal -- a book representing the user's personal 556 address book. 558 * ab:friends -- a subset of ab:personal, defined by the user. 560 * ab:family -- a subset of ab:personal, defined by the user. 562 * ab:company -- a book representing user's company's address 563 book. 565 * ab:department -- a subset of ab:company, defined by the 566 company. 568 * ab:co-workers -- a subset of ab:company, defined by the user. 570 * ab:default -- the default address book, a reference to ab: 571 personal. 573 Applications and/or protocols that use this URI scheme name: 574 Currently only the Sieve External List extension is using this 575 URI scheme. Email clients that use URIs internally might find 576 this URI scheme to be useful as well. 578 Interoperability considerations: Applications are only REQUIRED to 579 support "ab:default". 581 Security considerations: Applications SHOULD ensure appropriate 582 restrictions are in place to protect sensitive information that 583 might be revealed by "ab" URIs from access or modification by 584 untrusted sources. 586 Relevant publications: this RFC 588 Contact: Sieve mailing list 590 Author/Change controller: IETF/IESG 592 5. Acknowledgements 594 Thanks to Alexandros Vellis, Nigel Swinson, Ned Freed, Kjetil Torgrim 595 Homme, Dave Cridland, Cyrus Daboo, Pete Resnick, and Robert Burrell 596 Donkin for ideas, comments and suggestions. Kristin Hubner also 597 helped greatly with the examples. 599 6. References 601 6.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 607 Resource Identifier (URI): Generic Syntax", STD 66, 608 RFC 3986, January 2005. 610 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 611 RFC 4151, October 2005. 613 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 614 Registration Procedures for New URI Schemes", BCP 35, 615 RFC 4395, February 2006. 617 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 618 Language", RFC 5228, January 2008. 620 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 621 Specifications: ABNF", STD 68, RFC 5234, January 2008. 623 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 624 Managing Sieve Scripts", RFC 5804, July 2010. 626 6.2. Informative References 628 [I-D.ietf-vcarddav-carddav] 629 Daboo, C., "vCard Extensions to WebDAV (CardDAV)", 630 draft-ietf-vcarddav-carddav-10 (work in progress), 631 November 2009. 633 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 634 Configuration Access Protocol", RFC 2244, November 1997. 636 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 637 (LDAP): Technical Specification Road Map", RFC 4510, 638 June 2006. 640 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 641 RFC 5229, January 2008. 643 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 644 Relational Extension", RFC 5231, January 2008. 646 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 647 Extension", RFC 5233, January 2008. 649 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 650 Extensions", RFC 5235, January 2008. 652 [RFC5260] Freed, N., "Sieve Email Filtering: Date and Index 653 Extensions", RFC 5260, July 2008. 655 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 656 "Sieve Email Filtering: Extension for Notifications", 657 RFC 5435, January 2009. 659 [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification 660 Mechanism: Extensible Messaging and Presence Protocol 661 (XMPP)", RFC 5437, January 2009. 663 [RFC5463] Freed, N., "Sieve Email Filtering: Ihave Extension", 664 RFC 5463, March 2009. 666 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 667 Tests, Iteration, Extraction, Replacement, and Enclosure", 668 RFC 5703, October 2009. 670 Authors' Addresses 672 Alexey Melnikov 673 Isode Limited 674 5 Castle Business Village 675 36 Station Road 676 Hampton, Middlesex TW12 2BX 677 UK 679 Email: Alexey.Melnikov@isode.com 681 Barry Leiba 682 Huawei Technologies 684 Phone: +1 646 827 0648 685 Email: barryleiba@computer.org 686 URI: http://internetmessagingtechnology.org/