idnits 2.17.1 draft-ietf-lemonade-imap-sieve-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2006) is 6625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade Working Group B. Leiba 3 Internet-Draft IBM T.J. Watson Research Center 4 Expires: September 7, 2006 March 6, 2006 6 Support for Sieve in Internet Message Access Protocol (IMAP4) 7 draft-ietf-lemonade-imap-sieve-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of 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 September 7, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Sieve defines an email filtering language that can, in principle, 41 plug into any point in the processing of an email message. As 42 defined in the base specification, it plugs into mail delivery. This 43 document defines how Sieve can plug into points in the IMAP protocol 44 where messages are created or changed, adding the option of user- 45 defined or installation-defined filtering (or, with Sieve extensions, 46 features such as notifications). 48 Note 49 While this document defines extensions to IMAP and Sieve, it is the 50 work of the Lemonade Working Group (Enhancements to Internet email to 51 support diverse service environments), and discussion of it is on the 52 lemonade mailing list at mailto:lemonade@ietf.org. Subscription 53 requests can be sent to 54 mailto:lemonade-request@ietf.org?body=subscribe (send an email 55 message with the word "subscribe" in the body). A WWW archive of 56 back messages is available at 57 http://www.ietf.org/mail-archive/web/lemonade/index.html 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.2. Conventions used in this document . . . . . . . . . . . . 5 65 2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 6 66 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 6 67 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 6 68 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 6 69 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 6 70 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 6 71 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 6 72 2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 7 73 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 7 74 2.3.1. Changes to Manage Sieve . . . . . . . . . . . . . . . . . 7 76 3. Applicable Sieve Actions and Interactions . . . . . . . . 8 77 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 8 78 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 8 79 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 8 80 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 9 81 3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 9 82 3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 9 83 3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 9 84 3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 10 85 3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 10 86 3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 10 87 3.11. New Sieve Variable: IMAPSieve.cause . . . . . . . . . . . 10 88 3.12. New Sieve Variable: IMAPSieve.mailbox . . . . . . . . . . 11 89 3.13. New Sieve Variable: IMAPSieve.changed.flags . . . . . . . 11 90 3.14. New Sieve Variable: IMAPSieve.changed.annotations . . . . 11 91 3.15. Interaction With Sieve Tests (Comparisons) . . . . . . . . 12 93 4. Open Issues With This Document . . . . . . . . . . . . . . 13 95 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 15 99 7. Security Considerations . . . . . . . . . . . . . . . . . 16 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . 18 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 105 9.2. Non-Normative References . . . . . . . . . . . . . . . . . 18 106 Author's Address . . . . . . . . . . . . . . . . . . . . . 20 107 Intellectual Property and Copyright Statements . . . . . . 21 109 1. Introduction 111 1.1. Overview 113 Some applications have a need to apply [Sieve] filters in situations 114 other than initial mail delivery. This is especially true in diverse 115 service environments, such as when the client is sporadically 116 connected, is connected through a high-latency or high-cost channel, 117 or is on a limited-function device. For such clients, it may be very 118 important, for higher performance and reliability, to take advantage 119 of server capabilities, including those provided by Sieve filtering 120 (and Sieve extensions, such as [Notify]). 122 This specification defines extensions to [IMAP] to support the 123 invocation of Sieve scripts at times when the IMAP server creates new 124 messages, or modifies existing ones. It also defines how Sieve 125 scripts will process these invocations. 127 1.2. Conventions used in this document 129 In examples, "C:" and "S:" indicate lines sent by the client and 130 server respectively. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 134 be interpreted as described in [Keywds]. 136 2. The IMAP "IMAPSieve" Extension 138 2.1. The "IMAPSieve" Capability String 140 An IMAP server advertises support for this extension through the 141 capability string "IMAPSieve" (the string is not case-sensitive, and 142 is shown here with this capitalization for readability). A server 143 that advertises IMAPSieve is claiming to be in compliance with this 144 specification in all aspects. 146 2.2. Existing IMAP Functions Affected by IMAPSieve 148 The subsections below describe in detail the IMAP commands and 149 situations on which IMAPSieve has an effect. Not all Sieve actions 150 make sense in the case of messages affected by IMAP commands. See 151 Section 3 for details. 153 If more than one message is affected at the same time, each message 154 triggers the execution of a Sieve script separately. The scripts MAY 155 be run in parallel. 157 2.2.1. The IMAP APPEND Command 159 A message may be added to a mailbox through the IMAP APPEND command. 160 In a server that advertises IMAPSieve, new messages added in this way 161 MUST trigger the execution of a Sieve script, subject to the settings 162 defined through Manage Sieve (see Section 2.3.1). 164 2.2.2. The IMAP MULTIAPPEND Command 166 If the IMAP server supports the IMAP [MultiAppend] extension, 167 messages may be added to a mailbox through the IMAP MULTIAPPEND 168 command. In a server that advertises IMAPSieve, new messages added 169 in this way MUST trigger the execution of a Sieve script, as with the 170 APPEND command, also subject to the settings defined through Manage 171 Sieve. 173 2.2.3. The IMAP COPY Command 175 One or more messages may be added to a mailbox through the IMAP COPY 176 command. In a server that advertises IMAPSieve, new messages added 177 in this way MUST trigger the execution of a Sieve script, subject to 178 the settings defined through Manage Sieve. 180 2.2.4. Changes to IMAP Message Flags 182 One or more existing messages can have their flags changed in a 183 number of ways, including: 185 o The FETCH command (may cause the \Seen flag to be set). 187 o The STORE command (may cause the \Answered, \Deleted, \Draft, 188 \Flagged, and \Seen flags to be set or reset, and may cause 189 keywords to be set or reset). 191 o The invocation of a Sieve script on an existing message, where the 192 Sieve implementation supports the [IMAP4Flags] extension and the 193 script uses one of the actions defined in that extension. 195 In a server that advertises IMAPSieve, messages whose flags are 196 changed in any way (except as explained in the next sentence) MUST 197 trigger the execution of a Sieve script, subject to the settings 198 defined through Manage Sieve. The exception is that in order to 199 avoid script loops, flag changes that are made as a result of a 200 script that was itself invoked because of flag changes SHOULD NOT 201 result in another script invocation. In any case, implementations 202 MUST take steps to avoid such loops. 204 2.2.5. New or Changed IMAP Message Annotations 206 [[Annotate?: Do we want this to apply to annotate too? If so, does 207 that make annotate a normative reference?]] 209 If the IMAP server supports the [Annotate] extension, one or more 210 existing messages can have annotations added or changed through the 211 ANNOTATE command. In a server that advertises IMAPSieve, messages 212 getting new or changed annotations MUST trigger the execution of a 213 Sieve script, subject to the settings defined through Manage Sieve. 215 2.3. New Functions Defined by IMAPSieve 217 2.3.1. Changes to Manage Sieve 219 [[Manage Sieve placeholder: This section is a placeholder right now, 220 for changes to the Manage Sieve protocol. We'll fill in more detail 221 on the next iteration of this draft.]] 223 Manage Sieve [Manage] is a protocol for managing Sieve scripts. We 224 define here an extension to that protocol to support multiple active 225 scripts, each serving a different function. The extension here will 226 allow us to tell the IMAP server which script to use for which 227 mailbox(es) for the conditions described in this document. No Sieve 228 script is invoked for an IMAP condition unless Manage Sieve has 229 defined a script for it, and has "turned on" filtering for a 230 particular mailbox or set of mailboxes. 232 3. Applicable Sieve Actions and Interactions 234 Since some Sieve actions relate specifically to the delivery of mail, 235 not all actions make sense when the messages are created by other 236 means, or when changes are made to data associated with existing 237 messages. This section describes how actions in the base Sieve 238 specification, and those in extensions known at this writing, relate 239 to this specification. 241 In addition to what is specified here, interactions noted in the 242 individual specifications apply, and must be considered. 244 3.1. The Implicit Keep 246 For all cases that fall under IMAPSieve, the implicit keep means that 247 the message is treated as it would have been if no Sieve script were 248 run. For APPEND, MULTIAPPEND and COPY, the message is stored into 249 the target mailbox normally. For flag or annotation changes, the 250 message is left in the mailbox. 252 3.2. The Keep Action 254 The keep action is applicable in all cases that fall under IMAPSieve. 255 Its behaviour is as described for implicit keep, in Section 3.1. 257 3.3. The Fileinto Action 259 If the Sieve implementation supports the fileinto action, that action 260 is applicable in all cases that fall under IMAPSieve. If the [Copy] 261 extension is available and the :copy option is specified, the 262 implicit keep is retained; otherwise, fileinto cancels the implicit 263 keep, as specified in the base Sieve specification. 265 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 266 fileinto mailbox IN ADDITION TO the original target mailbox. For 267 flag or annotation changes, the message is COPIED into the fileinto 268 mailbox, without removing the original. 270 If a keep action is NOT also in effect, the original message is then 271 marked with the \Deleted flag (and a flag-change Sieve script is NOT 272 invoked). The implementation MAY then expunge the original message 273 (WITHOUT expunging other messages in the mailbox), or it MAY choose 274 to have expunges batched, or done by a user. The effect is as though 275 a client had flagged the message and done a UID EXPUNGE (see 276 [UIDPlus]). Handling it this way allows clients to handle messages 277 consistently, and avoids hidden changes that might invalidate their 278 message caches. 280 3.4. The Redirect Action 282 The redirect action is applicable in all cases that fall under 283 IMAPSieve. It causes the message to be sent, as specified in the 284 base Sieve specification, to the designated address. If the [Copy] 285 extension is available and the :copy option is specified, the 286 implicit keep is retained; otherwise, redirect cancels the implicit 287 keep, as specified in the base Sieve specification. 289 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 290 target mailbox in addition to being redirected. For flag or 291 annotation changes, the message remains in its original mailbox. 293 If a keep action is NOT also in effect, the original message is then 294 marked with the \Deleted flag (and a flag-change Sieve script is NOT 295 invoked). The implementation MAY then expunge the original message 296 (WITHOUT expunging other messages in the mailbox), or it MAY choose 297 to have expunges batched, or done by a user. The effect is as though 298 a client had flagged the message and done a UID EXPUNGE (see 299 [UIDPlus]). Handling it this way allows clients to handle messages 300 consistently, and avoids hidden changes that might invalidate their 301 message caches. 303 3.5. The Reject Action 305 The reject action is NOT applicable to any case that falls under 306 IMAPSieve. Its use MUST result in an error condition that will 307 terminate the Sieve script. 309 3.6. The Discard Action 311 The discard action is applicable in all cases that fall under 312 IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first 313 stored into the target mailbox. If a keep action, implicit or 314 explicit, is also in effect, the discard action now does nothing. 315 Otherwise, the original message is then marked with the \Deleted flag 316 (and a flag-change Sieve script is NOT invoked). The implementation 317 MAY then expunge the original message (WITHOUT expunging other 318 messages in the mailbox), or it MAY choose to have expunges batched, 319 or done by a user. The effect is as though a client had flagged the 320 message and done a UID EXPUNGE (see [UIDPlus]). Handling it this way 321 allows clients to handle messages consistently, and avoids hidden 322 changes that might invalidate their message caches. 324 3.7. The Notify Action 326 If the [Notify] extension is available, the notify action is 327 applicable in all cases that fall under IMAPSieve. The result is 328 that the requested notification is sent, and that the message is 329 otherwise handled as it would normally have been. 331 3.8. The Addheader and Deleteheader Actions 333 Even if the [EditHeader] extension is available, since messages in 334 IMAP mailboxes are immutable these actions are NOT applicable. Using 335 them for flag or annotation changes to existing messages would cause 336 the message to be changed. Using them for APPEND, MULTIAPPEND, and 337 COPY would cause unexpected differences in the stored copy as 338 compared to what the client expected, and would make the client's 339 message cache invalid unexpectedly. Use of these MUST result in an 340 error condition that will terminate the Sieve script. 342 3.9. The Setflag, Deleteflag, and Removeflag Actions 344 If the [IMAP4Flags] extension is available, the actions associated 345 with it are all applicable to any case that falls under IMAPSieve. 346 It is worth noting also that the "hasflag" test that is defined in 347 the IMAP4Flags extension might be particularly useful in scripts 348 triggered by flag changes. The flag changes behave as though a 349 client had made the change. 351 As explained above, in order to avoid script loops flag changes that 352 are made as a result of a script that was itself invoked because of 353 flag changes SHOULD NOT result in another script invocation. In any 354 case, implementations MUST take steps to avoid such loops. 356 3.10. The Vacation Action 358 Even if the [Vacation] extension is available, the vacation action is 359 NOT applicable to any case that falls under IMAPSieve. Its use MUST 360 result in an error condition that will terminate the Sieve script. 362 3.11. New Sieve Variable: IMAPSieve.cause 364 [[var1: This will be replaced in the next draft iteration; we won't 365 make them variables.]] 367 Implementations MAY invoke different Sieve scripts for the different 368 conditions described in this document (append, copy, flag changes, 369 annotation changes). If the actions to be taken are common, and the 370 implementation supports the [Include] extension, the common script 371 code can be included as specified there. 373 It may be preferable, though, to use a single script for all these 374 conditions. To support that, if the [Variables] extension is 375 available, the implementation MUST set the reserved variable 376 "${IMAPSieve.cause}", which contains the name of the action that 377 caused the script to be invoked. Its value is one of the following: 379 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 381 o COPY (for invocations resulting from COPY) 383 o FLAG (for invocations resulting from flag changes) 385 o ANNOTATE (for invocations resulting from new or changed 386 annotations) 388 3.12. New Sieve Variable: IMAPSieve.mailbox 390 [[var2: This will be replaced in the next draft iteration; we won't 391 make them variables.]] 393 If the [Variables] extension is available, the implementation MUST 394 set the reserved variable "${IMAPSieve.mailbox}" to the name of the 395 mailbox that the affected message is in, in the case of existing 396 messages, or is targeted to be stored into, in the case of new 397 messages. The value of this variable is fixed when the script 398 begins, and, in particular, MUST NOT change as a result of any 399 action, such as "fileinto". 401 3.13. New Sieve Variable: IMAPSieve.changed.flags 403 [[var3: This will be replaced in the next draft iteration; we won't 404 make them variables.]] 406 If the [Variables] extension is available, the [IMAP4Flags] extension 407 is available, AND the script was invoked because of flag changes to 408 an existing message, the implementation MUST set the reserved 409 variable "${IMAPSieve.changed.flags}" to the name(s) of the flag(s) 410 that have changed. If the script was not invoked because of flag 411 changes, this variable MUST be unknown (and, thus, its value MUST be 412 the empty string). The script will not know from this variable 413 whether the flags have been set or reset, but it can use the 414 "hasflag" test to determine the current value. See example 2 in 415 Section 5 for an example of how this might be used. 417 3.14. New Sieve Variable: IMAPSieve.changed.annotations 419 [[var4: This will be replaced in the next draft iteration; we won't 420 make them variables.]] 422 If the [Variables] extension is available, the [Annotate] extension 423 is available, AND the script was invoked because of annotation 424 changes to an existing message, the implementation MUST set the 425 reserved variable "${IMAPSieve.changed.annotations}" to the name(s) 426 of the annotation(s) that have changed. If the script was not 427 invoked because of annotation changes, this variable MUST be unknown 428 (and, thus, its value MUST be the empty string). 430 3.15. Interaction With Sieve Tests (Comparisons) 432 This extension does not affect the operation of any tests or 433 comparisons. 435 4. Open Issues With This Document 437 When this section is empty, I guess we're done.... 439 1. The Manage Sieve changes need to be specified. 441 2. The stuff with "new sieve variables" has to be changed, as was 442 extensively discussed on the mailing list. Next iteration.... 444 3. All of the extensions that we describe how to work with: are they 445 normative, or non-normative references? 447 4. Can anyone come up with some examples that use only features from 448 the base Sieve spec? 450 5. Examples 452 Example 1: 453 If a new message is added to the "ActionItems" mailbox, a copy is 454 sent to the address "actionitems@example.com". 456 require ["copy", "variables"]; 458 if anyof (${IMAPSieve.cause} :is "APPEND", 459 ${IMAPSieve.cause} :is "COPY") { 460 if ${IMAPSieve.mailbox} :is "ActionItems" { 461 redirect :copy "actionitems@example.com"; 462 } 463 } 465 Example 2: 466 If the script is called for any message with the \Flagged flag set 467 (tested through the [IMAP4Flags] extension), a notification is sent 468 using the [Notify] extension. No notification will be sent, though, 469 if we're called with an existing message that already had that flag 470 set. 472 require ["nofity", "imap4flags", "variables"]; 474 if allof (hasflag "\\Flagged", 475 not ${IMAPSieve.changed.flags} :contains "\\Flagged") { 476 notify :message "Important message in ${IMAPSieve.mailbox}"; 477 } 479 Example 3: 480 [[More examples?: Can anyone come up with some examples that use only 481 features from the base Sieve spec?]] 483 6. Formal Syntax 485 The following syntax specification uses the augmented Backus-Naur 486 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced 487 but not defined below are as defined by [IMAP]. 489 [[Maybe...: If we decide we need this command, the syntax goes 490 here.]] 492 command_auth =/ sievefilter 493 ; Valid only in Authenticated or Selected state 495 sievefilter = "SIEVEFILTER" to be defined 497 7. Security Considerations 499 It is possible to introduce script processing loops by having a Sieve 500 script that is triggered by flag changes use the actions defined in 501 the [IMAP4Flags] extension. Implementations MUST take steps to 502 prevent such loops. One way to avoid this problem is that if a 503 script is invoked by flag changes, and that script further changes 504 the flags, those flag changes SHOULD NOT trigger a Sieve script 505 invocation. 507 Other security considerations are discussed in [IMAP], and [Sieve], 508 as well as in some of the other extension documents. 510 8. IANA Considerations 512 [[IANA?: Do we need this, since there's not actually a Sieve 513 capability defined here?]] 514 The following template specifies the IANA registration of the Sieve 515 extension specified in this document: 517 To: iana@iana.org 518 Subject: Registration of new Sieve extension 519 Capability name: imapsieve 520 Capability keyword: imapsieve 521 Capability arguments: N/A 522 Standards Track/IESG-approved experimental RFC number: this RFC 523 Person and email address to contact for further information: 524 Barry Leiba 526 This information should be added to the list of sieve extensions 527 given on http://www.iana.org/assignments/sieve-extensions. 529 9. References 531 9.1. Normative References 533 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 534 Specifications: ABNF", RFC 4234, October 2005. 536 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 537 4rev1", RFC 3501, March 2003. 539 [Keywds] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", RFC 2119, March 1997. 542 [Manage] Martin, T. and A. Melnikov, Ed., "A Protocol for Remotely 543 Managing Sieve Scripts", work in 544 progress, draft-martin-managesieve, February 2006. 546 [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 547 Filtering Language", work in 548 progress, draft-ietf-sieve-3028bis, November 2005. 550 9.2. Non-Normative References 552 [Annotate] 553 Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", work 554 in progress, draft-ietf-imapext-annotate, November 2005. 556 [Copy] Degener, J., "Sieve Extension: Copying Without Side 557 Effects", RFC 3894, October 2004. 559 [EditHeader] 560 Degener, J. and P. Guenther, "Sieve Email Filtering: 561 Editheader Extension", work in 562 progress, draft-ietf-sieve-editheader, October 2005. 564 [IMAP4Flags] 565 Melnikov, A., "Sieve Mail Filtering Language: IMAP flag 566 Extension", work in progress, draft-ietf-sieve-imapflags, 567 October 2005. 569 [Include] Daboo, C., "SIEVE Email Filtering: Include Extension", 570 work in progress, draft-daboo-sieve-include, August 2005. 572 [MultiAppend] 573 Crispin, M., "Internet Message Access Protocol (IMAP) - 574 MULTIAPPEND Extension", RFC 3502, March 2003. 576 [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 578 Martin, "Sieve Extension: Notifications", work in 579 progress, draft-ietf-sieve-notify, December 2005. 581 [UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - 582 UIDPLUS Extension", RFC 4315, December 2005. 584 [Vacation] 585 Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: 586 Vacation Extension", work in 587 progress, draft-ietf-sieve-vacation, October 2005. 589 [Variables] 590 Homme, K., "Sieve Extension: Variables", work in 591 progress, draft-ietf-sieve-variables, October 2005. 593 Author's Address 595 Barry Leiba 596 IBM T.J. Watson Research Center 597 19 Skyline Drive 598 Hawthorne, NY 10532 599 US 601 Phone: +1 914 784 7941 602 Email: leiba@watson.ibm.com 604 Full Copyright Statement 606 Copyright (C) The Internet Society (2006). 608 This document is subject to the rights, licenses and restrictions 609 contained in BCP 78, and except as set forth therein, the authors 610 retain all their rights. 612 This document and the information contained herein are provided on an 613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 615 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 616 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 617 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Intellectual Property 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org. 644 Acknowledgment 646 Funding for the RFC Editor function is currently provided by the 647 Internet Society.