idnits 2.17.1 draft-ietf-lemonade-imap-sieve-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 708. 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 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 7, 2007) is 6260 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) -- Possible downref: Normative reference to a draft: ref. 'Environment' ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: A later version (-12) exists of draft-martin-managesieve-07 == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-11 == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 == Outdated reference: A later version (-11) exists of draft-ietf-sieve-editheader-07 == Outdated reference: A later version (-06) exists of draft-daboo-sieve-include-05 == Outdated reference: A later version (-12) exists of draft-ietf-sieve-notify-07 == Outdated reference: A later version (-07) exists of draft-ietf-sieve-vacation-06 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 8 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 Intended status: Standards Track March 7, 2007 5 Expires: September 8, 2007 7 Support for Sieve in Internet Message Access Protocol (IMAP4) 8 draft-ietf-lemonade-imap-sieve-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 8, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Sieve defines an email filtering language that can, in principle, 42 plug into any point in the processing of an email message. As 43 defined in the base specification, it plugs into mail delivery. This 44 document defines how Sieve can plug into points in the IMAP protocol 45 where messages are created or changed, adding the option of user- 46 defined or installation-defined filtering (or, with Sieve extensions, 47 features such as notifications). 49 Note 51 While this document defines extensions to IMAP and Sieve, it is the 52 work of the Lemonade Working Group (Enhancements to Internet email to 53 support diverse service environments), and discussion of it is on the 54 lemonade mailing list at mailto:lemonade@ietf.org. Subscription 55 requests can be sent to 56 mailto:lemonade-request@ietf.org?body=subscribe (send an email 57 message with the word "subscribe" in the body). A WWW archive of 58 back messages is available at 59 http://www.ietf.org/mail-archive/web/lemonade/index.html 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1.2. Conventions used in this document . . . . . . . . . . . . 6 67 2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 7 68 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 7 69 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 7 70 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 71 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7 72 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7 73 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7 74 2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8 75 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 8 76 2.3.1. Changes to Manage Sieve or Metadata . . . . . . . . . . . 8 78 3. Applicable Sieve Actions and Interactions . . . . . . . . 10 79 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10 80 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10 81 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10 82 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11 83 3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 11 84 3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 11 85 3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 11 86 3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 12 87 3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 88 3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 12 89 3.11. New Sieve Environment Item: cause . . . . . . . . . . . . 12 90 3.12. New Sieve Environment Item: mailbox . . . . . . . . . . . 13 91 3.13. New Sieve Environment Item: changedflags . . . . . . . . . 13 92 3.14. New Sieve Environment Item: changedannotations . . . . . . 13 93 3.15. Interaction With Sieve Tests (Comparisons) . . . . . . . . 13 95 4. Open Issues With This Document . . . . . . . . . . . . . . 14 97 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 6. Security Considerations . . . . . . . . . . . . . . . . . 16 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 102 7.1. Registration of imapsieve extension . . . . . . . . . . . 17 103 7.2. Registration of environment item: cause . . . . . . . . . 17 104 7.3. Registration of environment item: mailbox . . . . . . . . 18 105 7.4. Registration of environment item: changedflags . . . . . . 18 106 7.5. Registration of environment item: changedannotations . . . 18 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . 20 109 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 110 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 20 112 Author's Address . . . . . . . . . . . . . . . . . . . . . 22 113 Intellectual Property and Copyright Statements . . . . . . 23 115 1. Introduction 117 1.1. Overview 119 Some applications have a need to apply [Sieve] filters in situations 120 other than initial mail delivery. This is especially true in diverse 121 service environments, such as when the client is sporadically 122 connected, is connected through a high-latency or high-cost channel, 123 or is on a limited-function device. For such clients, it may be very 124 important, for higher performance and reliability, to take advantage 125 of server capabilities, including those provided by Sieve filtering 126 (and Sieve extensions, such as [Notify]). 128 This specification defines extensions to [IMAP] to support the 129 invocation of Sieve scripts at times when the IMAP server creates new 130 messages, or modifies existing ones. It also defines how Sieve 131 scripts will process these invocations. 133 1.2. Conventions used in this document 135 In examples, "C:" and "S:" indicate lines sent by the client and 136 server respectively. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 140 be interpreted as described in [Keywds]. 142 2. The IMAP "IMAPSieve" Extension 144 2.1. The "IMAPSieve" Capability String 146 An IMAP server advertises support for this extension through the 147 capability string "IMAPSieve" (the string is not case-sensitive, and 148 is shown here with this capitalization for readability). A server 149 that advertises IMAPSieve is claiming to be in compliance with this 150 specification in all aspects. 152 2.2. Existing IMAP Functions Affected by IMAPSieve 154 The subsections below describe in detail the IMAP commands and 155 situations on which IMAPSieve has an effect. Not all Sieve actions 156 make sense in the case of messages affected by IMAP commands. See 157 Section 3 for details. 159 If more than one message is affected at the same time, each message 160 triggers the execution of a Sieve script separately. The scripts MAY 161 be run in parallel. 163 2.2.1. The IMAP APPEND Command 165 A message may be added to a mailbox through the IMAP APPEND command. 166 In a server that advertises IMAPSieve, new messages added in this way 167 MUST trigger the execution of a Sieve script, subject to the settings 168 defined through Manage Sieve or Metadata (see Section 2.3.1). 170 2.2.2. The IMAP MULTIAPPEND Command 172 If the IMAP server supports the IMAP [MultiAppend] extension, 173 messages may be added to a mailbox through the IMAP MULTIAPPEND 174 command. In a server that advertises IMAPSieve, new messages added 175 in this way MUST trigger the execution of a Sieve script, as with the 176 APPEND command, also subject to the settings defined through Manage 177 Sieve or Metadata. 179 2.2.3. The IMAP COPY Command 181 One or more messages may be added to a mailbox through the IMAP COPY 182 command. In a server that advertises IMAPSieve, new messages added 183 in this way MUST trigger the execution of a Sieve script, subject to 184 the settings defined through Manage Sieve or Metadata. 186 2.2.4. Changes to IMAP Message Flags 188 One or more existing messages can have their flags changed in a 189 number of ways, including: 191 o The FETCH command (may cause the \Seen flag to be set). 193 o The STORE command (may cause the \Answered, \Deleted, \Draft, 194 \Flagged, and \Seen flags to be set or reset, and may cause 195 keywords to be set or reset). 197 o The invocation of a Sieve script on an existing message, where the 198 Sieve implementation supports the [IMAP4Flags] extension and the 199 script uses one of the actions defined in that extension. 201 In a server that advertises IMAPSieve, messages whose flags are 202 changed in any way (except as explained in the next sentence) MUST 203 trigger the execution of a Sieve script, subject to the settings 204 defined through Manage Sieve or Metadata. The exception is that in 205 order to avoid script loops, flag changes that are made as a result 206 of a script that was itself invoked because of flag changes SHOULD 207 NOT result in another script invocation. In any case, 208 implementations MUST take steps to avoid such loops. 210 2.2.5. New or Changed IMAP Message Annotations 212 If the IMAP server supports the [Annotate] extension, one or more 213 existing messages can have annotations added or changed through the 214 ANNOTATE command. In a server that advertises IMAPSieve, messages 215 getting new or changed annotations MUST trigger the execution of a 216 Sieve script, subject to the settings defined through Manage Sieve or 217 Metadata. 219 2.3. New Functions Defined by IMAPSieve 221 2.3.1. Changes to Manage Sieve or Metadata 223 [[Manage Sieve/Metadata placeholder: This section is a placeholder 224 right now, for changes to the Manage Sieve protocol or the Metadata 225 extension. We'll fill in more detail on the next iteration of this 226 draft.]] 228 Manage Sieve ([Manage]) is a protocol for managing Sieve scripts. We 229 define here an extension to that protocol to support multiple active 230 scripts, each serving a different function. The extension here will 231 allow us to tell the IMAP server which script to use for which 232 mailbox(es) for the conditions described in this document. No Sieve 233 script is invoked for an IMAP condition unless Manage Sieve has 234 defined a script for it, and has "turned on" filtering for a 235 particular mailbox or set of mailboxes. 237 ...or... 239 Metadata ([Metadata]) is a protocol for including extra information 240 about IMAP servers and mailboxes. We define here an extension to 241 that protocol to add specific information about sieve scripts. 243 3. Applicable Sieve Actions and Interactions 245 Since some Sieve actions relate specifically to the delivery of mail, 246 not all actions make sense when the messages are created by other 247 means, or when changes are made to data associated with existing 248 messages. This section describes how actions in the base Sieve 249 specification, and those in extensions known at this writing, relate 250 to this specification. 252 In addition to what is specified here, interactions noted in the 253 individual specifications apply, and must be considered. 255 3.1. The Implicit Keep 257 For all cases that fall under IMAPSieve, the implicit keep means that 258 the message is treated as it would have been if no Sieve script were 259 run. For APPEND, MULTIAPPEND and COPY, the message is stored into 260 the target mailbox normally. For flag or annotation changes, the 261 message is left in the mailbox. 263 3.2. The Keep Action 265 The keep action is applicable in all cases that fall under IMAPSieve. 266 Its behaviour is as described for implicit keep, in Section 3.1. 268 3.3. The Fileinto Action 270 If the Sieve implementation supports the fileinto action, that action 271 is applicable in all cases that fall under IMAPSieve. If the [Copy] 272 extension is available and the :copy option is specified, the 273 implicit keep is retained; otherwise, fileinto cancels the implicit 274 keep, as specified in the base Sieve specification. 276 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 277 fileinto mailbox IN ADDITION TO the original target mailbox. For 278 flag or annotation changes, the message is COPIED into the fileinto 279 mailbox, without removing the original. 281 If a keep action is NOT also in effect, the original message is then 282 marked with the \Deleted flag (and a flag-change Sieve script is NOT 283 invoked). The implementation MAY then expunge the original message 284 (WITHOUT expunging other messages in the mailbox), or it MAY choose 285 to have expunges batched, or done by a user. The effect is as though 286 a client had flagged the message and done a UID EXPUNGE (see 287 [UIDPlus]). Handling it this way allows clients to handle messages 288 consistently, and avoids hidden changes that might invalidate their 289 message caches. 291 3.4. The Redirect Action 293 The redirect action is applicable in all cases that fall under 294 IMAPSieve. It causes the message to be sent, as specified in the 295 base Sieve specification, to the designated address. If the [Copy] 296 extension is available and the :copy option is specified, the 297 implicit keep is retained; otherwise, redirect cancels the implicit 298 keep, as specified in the base Sieve specification. 300 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 301 target mailbox in addition to being redirected. For flag or 302 annotation changes, the message remains in its original mailbox. 304 If a keep action is NOT also in effect, the original message is then 305 marked with the \Deleted flag (and a flag-change Sieve script is NOT 306 invoked). The implementation MAY then expunge the original message 307 (WITHOUT expunging other messages in the mailbox), or it MAY choose 308 to have expunges batched, or done by a user. The effect is as though 309 a client had flagged the message and done a UID EXPUNGE (see 310 [UIDPlus]). Handling it this way allows clients to handle messages 311 consistently, and avoids hidden changes that might invalidate their 312 message caches. 314 3.5. The Reject Action 316 The reject action is NOT applicable to any case that falls under 317 IMAPSieve. Its use MUST result in an error condition that will 318 terminate the Sieve script. 320 3.6. The Discard Action 322 The discard action is applicable in all cases that fall under 323 IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first 324 stored into the target mailbox. If a keep action, implicit or 325 explicit, is also in effect, the discard action now does nothing. 326 Otherwise, the original message is then marked with the \Deleted flag 327 (and a flag-change Sieve script is NOT invoked). The implementation 328 MAY then expunge the original message (WITHOUT expunging other 329 messages in the mailbox), or it MAY choose to have expunges batched, 330 or done by a user. The effect is as though a client had flagged the 331 message and done a UID EXPUNGE (see [UIDPlus]). Handling it this way 332 allows clients to handle messages consistently, and avoids hidden 333 changes that might invalidate their message caches. 335 3.7. The Notify Action 337 If the [Notify] extension is available, the notify action is 338 applicable in all cases that fall under IMAPSieve. The result is 339 that the requested notification is sent, and that the message is 340 otherwise handled as it would normally have been. 342 3.8. The Addheader and Deleteheader Actions 344 Even if the [EditHeader] extension is available, since messages in 345 IMAP mailboxes are immutable these actions are NOT applicable. Using 346 them for flag or annotation changes to existing messages would cause 347 the message to be changed. Using them for APPEND, MULTIAPPEND, and 348 COPY would cause unexpected differences in the stored copy as 349 compared to what the client expected, and would make the client's 350 message cache invalid unexpectedly. Use of these MUST result in an 351 error condition that will terminate the Sieve script. 353 3.9. The Setflag, Deleteflag, and Removeflag Actions 355 If the [IMAP4Flags] extension is available, the actions associated 356 with it are all applicable to any case that falls under IMAPSieve. 357 It is worth noting also that the "hasflag" test that is defined in 358 the IMAP4Flags extension might be particularly useful in scripts 359 triggered by flag changes. The flag changes behave as though a 360 client had made the change. 362 As explained above, in order to avoid script loops flag changes that 363 are made as a result of a script that was itself invoked because of 364 flag changes SHOULD NOT result in another script invocation. In any 365 case, implementations MUST take steps to avoid such loops. 367 3.10. The Vacation Action 369 Even if the [Vacation] extension is available, the vacation action is 370 NOT applicable to any case that falls under IMAPSieve. Its use MUST 371 result in an error condition that will terminate the Sieve script. 373 3.11. New Sieve Environment Item: cause 375 Implementations MAY invoke different Sieve scripts for the different 376 conditions described in this document (append, copy, flag changes, 377 annotation changes). If the actions to be taken are common, and the 378 implementation supports the [Include] extension, the common script 379 code can be included as specified there. 381 It may be preferable, though, to use a single script for all these 382 conditions. To support that, if the [Environment] extension is 383 available, the implementation MUST set the environment item "cause", 384 which contains the name of the action that caused the script to be 385 invoked. Its value is one of the following: 387 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 389 o COPY (for invocations resulting from COPY) 391 o FLAG (for invocations resulting from flag changes) 393 o ANNOTATE (for invocations resulting from new or changed 394 annotations) 396 3.12. New Sieve Environment Item: mailbox 398 If the [Environment] extension is available, the implementation MUST 399 set the environment item "mailbox" to the name of the mailbox that 400 the affected message is in, in the case of existing messages, or is 401 targeted to be stored into, in the case of new messages. The value 402 of this item is fixed when the script begins, and, in particular, 403 MUST NOT change as a result of any action, such as "fileinto". 405 3.13. New Sieve Environment Item: changedflags 407 If the [Environment] extension is available, the [IMAP4Flags] 408 extension is available, AND the script was invoked because of flag 409 changes to an existing message, the implementation MUST set the 410 environment item "changedflags" to the name(s) of the flag(s) that 411 have changed. If the script was not invoked because of flag changes, 412 the value of this item MUST be the empty string. The script will not 413 know from this item whether the flags have been set or reset, but it 414 can use the "hasflag" test to determine the current value. See 415 example 2 in Section 5 for an example of how this might be used. 417 3.14. New Sieve Environment Item: changedannotations 419 If the [Environment] extension is available, the [Annotate] extension 420 is available, AND the script was invoked because of annotation 421 changes to an existing message, the implementation MUST set the 422 environment item "changedannotations" to the name(s) of the 423 annotation(s) that have changed. If the script was not invoked 424 because of annotation changes, the value of this item MUST be the 425 empty string. 427 3.15. Interaction With Sieve Tests (Comparisons) 429 This extension does not affect the operation of any tests or 430 comparisons. 432 4. Open Issues With This Document 434 When this section is empty, I guess we're done.... 436 1. The Manage Sieve/Metadata changes need to be specified. 438 2. All of the extensions that we describe how to work with: are they 439 normative, or non-normative references? 441 3. Can anyone come up with some examples that use only features from 442 the base Sieve spec? 444 5. Examples 446 Example 1: 447 If a new message is added to the "ActionItems" mailbox, a copy is 448 sent to the address "actionitems@example.com". 450 require ["copy", "variables"]; 452 if anyof (environment :is "cause" "APPEND", 453 environment :is "cause" "COPY") { 454 if environment :is "mailbox" "ActionItems" { 455 redirect :copy "actionitems@example.com"; 456 } 457 } 459 Example 2: 460 If the script is called for any message with the \Flagged flag set 461 (tested through the [IMAP4Flags] extension), a notification is sent 462 using the [Notify] extension. No notification will be sent, though, 463 if we're called with an existing message that already had that flag 464 set. 466 require ["nofity", "imap4flags", "variables"]; 468 if allof (hasflag "\\Flagged", 469 not environment :contains "changedflags" "\\Flagged") { 470 notify :message "Important message in ${IMAPSieve.mailbox}"; 471 } 473 Example 3: 474 [[More examples?: Can anyone come up with some examples that use only 475 features from the base Sieve spec?]] 477 6. Security Considerations 479 It is possible to introduce script processing loops by having a Sieve 480 script that is triggered by flag changes use the actions defined in 481 the [IMAP4Flags] extension. Implementations MUST take steps to 482 prevent such loops. One way to avoid this problem is that if a 483 script is invoked by flag changes, and that script further changes 484 the flags, those flag changes SHOULD NOT trigger a Sieve script 485 invocation. 487 Other security considerations are discussed in [IMAP], and [Sieve], 488 as well as in some of the other extension documents. 490 7. IANA Considerations 492 7.1. Registration of imapsieve extension 494 The following template specifies the IANA registration of the Sieve 495 extension specified in this document: 497 To: iana@iana.org 498 Subject: Registration of new Sieve extension 499 Capability name: imapsieve 500 Capability keyword: imapsieve 501 Capability arguments: N/A 502 Standards Track/IESG-approved experimental RFC number: this RFC 503 Person and email address to contact for further information: 504 Barry Leiba 506 This information should be added to the list of sieve extensions 507 given on http://www.iana.org/assignments/sieve-extensions. 509 7.2. Registration of environment item: cause 511 The following template specifies the IANA registration of a sieve 512 environment item specified in this document: 514 To: iana@iana.org 515 Subject: Registration of new Sieve environment item 516 Item name: cause 517 Description: The name of the action that caused the script to be 518 invoked. Its value is one of the following: 520 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 522 o COPY (for invocations resulting from COPY) 524 o FLAG (for invocations resulting from flag changes) 526 o ANNOTATE (for invocations resulting from new or changed 527 annotations) 529 RFC number: this RFC 530 Contact address: 531 Barry Leiba 533 This information should be added to the list of sieve environment 534 item names given in the [Environment] extension. 536 7.3. Registration of environment item: mailbox 538 The following template specifies the IANA registration of a sieve 539 environment item specified in this document: 541 To: iana@iana.org 542 Subject: Registration of new Sieve environment item 543 Item name: mailbox 544 Description: The name of the mailbox that the affected message is in, 545 in the case of existing messages, or is targeted to be stored into, 546 in the case of new messages. The value of this item is fixed when 547 the script begins, and, in particular, MUST NOT change as a result of 548 any action, such as "fileinto". 549 RFC number: this RFC 550 Contact address: 551 Barry Leiba 553 This information should be added to the list of sieve environment 554 item names given in the [Environment] extension. 556 7.4. Registration of environment item: changedflags 558 The following template specifies the IANA registration of a sieve 559 environment item specified in this document: 561 To: iana@iana.org 562 Subject: Registration of new Sieve environment item 563 Item name: changedflags 564 Description: If the script was invoked because of flag changes to an 565 existing message, this contains the name(s) of the flag(s) that have 566 changed. Otherwise, the value of this item MUST be the empty string. 567 RFC number: this RFC 568 Contact address: 569 Barry Leiba 571 This information should be added to the list of sieve environment 572 item names given in the [Environment] extension. 574 7.5. Registration of environment item: changedannotations 576 The following template specifies the IANA registration of a sieve 577 environment item specified in this document: 579 To: iana@iana.org 580 Subject: Registration of new Sieve environment item 581 Item name: changedannotations 582 Description: If the script was invoked because of annotation changes 583 to an existing message, this contains the name(s) of the 584 annotation(s) that have changed. Otherwise, the value of this item 585 MUST be the empty string. 586 RFC number: this RFC 587 Contact address: 588 Barry Leiba 590 This information should be added to the list of sieve environment 591 item names given in the [Environment] extension. 593 8. References 595 8.1. Normative References 597 [Environment] 598 Freed, N., "Sieve Email Filtering: Environment and Ihave 599 Extensions", work in 600 progress, draft-freed-sieve-environment-ihave-00, 601 November 2006. 603 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 604 4rev1", RFC 3501, March 2003. 606 [Keywds] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", RFC 2119, March 1997. 609 [Manage] Martin, T. and A. Melnikov, Ed., "A Protocol for Remotely 610 Managing Sieve Scripts", work in 611 progress, draft-martin-managesieve-07, November 2006. 613 [Metadata] 614 Daboo, C., "IMAP METADATA Extension", work in 615 progress, draft-daboo-imap-annotatemore-11, February 2007. 617 [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 618 Filtering Language", IESG 619 Evaluation, draft-ietf-sieve-3028bis-12, February 2007. 621 8.2. Non-Normative References 623 [Annotate] 624 Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", RFC 625 Editor Queue, draft-ietf-imapext-annotate-16, August 2006. 627 [Copy] Degener, J., "Sieve Extension: Copying Without Side 628 Effects", RFC 3894, October 2004. 630 [EditHeader] 631 Degener, J. and P. Guenther, "Sieve Email Filtering: 632 Editheader Extension", work in 633 progress, draft-ietf-sieve-editheader-07, November 2006. 635 [IMAP4Flags] 636 Melnikov, A., "Sieve Mail Filtering Language: IMAP flag 637 Extension", RFC Editor 638 Queue, draft-ietf-sieve-imapflags-05, May 2006. 640 [Include] Daboo, C., "SIEVE Email Filtering: Include Extension", 641 work in progress, draft-daboo-sieve-include-05, June 2006. 643 [MultiAppend] 644 Crispin, M., "Internet Message Access Protocol (IMAP) - 645 MULTIAPPEND Extension", RFC 3502, March 2003. 647 [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 648 Martin, "Sieve Extension: Notifications", work in 649 progress, draft-ietf-sieve-notify-07, February 2007. 651 [UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - 652 UIDPLUS Extension", RFC 4315, December 2005. 654 [Vacation] 655 Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: 656 Vacation Extension", RFC Editor 657 Queue, draft-ietf-sieve-vacation-06, February 2006. 659 Author's Address 661 Barry Leiba 662 IBM T.J. Watson Research Center 663 19 Skyline Drive 664 Hawthorne, NY 10532 665 US 667 Phone: +1 914 784 7941 668 Email: leiba@watson.ibm.com 670 Full Copyright Statement 672 Copyright (C) The IETF Trust (2007). 674 This document is subject to the rights, licenses and restrictions 675 contained in BCP 78, and except as set forth therein, the authors 676 retain all their rights. 678 This document and the information contained herein are provided on an 679 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 680 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 681 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 682 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 683 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 684 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 686 Intellectual Property 688 The IETF takes no position regarding the validity or scope of any 689 Intellectual Property Rights or other rights that might be claimed to 690 pertain to the implementation or use of the technology described in 691 this document or the extent to which any license under such rights 692 might or might not be available; nor does it represent that it has 693 made any independent effort to identify any such rights. Information 694 on the procedures with respect to rights in RFC documents can be 695 found in BCP 78 and BCP 79. 697 Copies of IPR disclosures made to the IETF Secretariat and any 698 assurances of licenses to be made available, or the result of an 699 attempt made to obtain a general license or permission for the use of 700 such proprietary rights by implementers or users of this 701 specification can be obtained from the IETF on-line IPR repository at 702 http://www.ietf.org/ipr. 704 The IETF invites any interested party to bring to its attention any 705 copyrights, patents or patent applications, or other proprietary 706 rights that may cover technology that may be required to implement 707 this standard. Please address the information to the IETF at 708 ietf-ipr@ietf.org. 710 Acknowledgment 712 Funding for the RFC Editor function is provided by the IETF 713 Administrative Support Activity (IASA).