idnits 2.17.1 draft-ietf-lemonade-imap-sieve-05.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 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 787. 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 (February 21, 2008) is 5909 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) ** Downref: Normative reference to an Experimental draft: draft-ietf-imapext-annotate (ref. 'Annotate') -- 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 (-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-martin-managesieve-07 == 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: 3 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 February 21, 2008 5 Expires: August 24, 2008 7 Support for Sieve in Internet Message Access Protocol (IMAP4) 8 draft-ietf-lemonade-imap-sieve-05 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 August 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 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 . . . . . . . . . . . . . . . . . . 8 73 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 8 74 2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8 75 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 9 76 2.3.1. Changes to Metadata . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 12 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) . . . . . . . . 14 95 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 5. Security Considerations . . . . . . . . . . . . . . . . . 16 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 100 6.1. Registration of imapsieve extension . . . . . . . . . . . 17 101 6.2. Registration of environment item: cause . . . . . . . . . 17 102 6.3. Registration of environment item: mailbox . . . . . . . . 17 103 6.4. Registration of environment item: changedflags . . . . . . 18 104 6.5. Registration of environment item: changedannotations . . . 18 105 6.6. Registration of IMAP METADATA mailbox entry name . . . . . 19 106 6.7. Registration of IMAP METADATA server entry name . . . . . 19 108 7. References . . . . . . . . . . . . . . . . . . . . . . . . 21 109 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 110 7.2. Non-Normative References . . . . . . . . . . . . . . . . . 21 112 Author's Address . . . . . . . . . . . . . . . . . . . . . 23 113 Intellectual Property and Copyright Statements . . . . . . 24 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. Support for IMAPSieve 132 requires support for [Metadata] as well, since the latter is used to 133 associate scripts with IMAP mailboxes. 135 1.2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 139 be interpreted as described in [Keywds]. 141 2. The IMAP "IMAPSieve" Extension 143 2.1. The "IMAPSieve" Capability String 145 An IMAP server advertises support for this extension through the 146 capability string "IMAPSieve" (the string is not case-sensitive, and 147 is shown here with this capitalization for readability). A server 148 that advertises IMAPSieve is claiming to be in compliance with this 149 specification in all aspects. 151 Implementations that support IMAPSieve MUST also support 152 [Environment], because the latter defines an important way for Sieve 153 scripts to test the conditions under which they have been invoked. 154 Notwithstanding this requirement, scripts that use IMAPSieve must 155 include BOTH capability strings in their required lists. 157 2.2. Existing IMAP Functions Affected by IMAPSieve 159 The subsections below describe in detail the IMAP commands and 160 situations on which IMAPSieve has an effect. Not all Sieve actions 161 make sense in the case of messages affected by IMAP commands. See 162 Section 3 for details. 164 It's important to note that since the base Sieve specification (see 165 [Sieve]) and its extensions define functions for scripts that are 166 invoked during initial mail delivery, those function definitions are 167 necessarily tailored to and limited by that context. This document 168 extends those function definitions for use during IMAP events. By 169 nature of that, Sieve functions, in this extended context, may behave 170 somewhat differently, though their extended behaviour will still be 171 consistent with the functions' goals. 173 If more than one message is affected at the same time, each message 174 triggers the execution of a Sieve script separately. The scripts MAY 175 be run in parallel. 177 2.2.1. The IMAP APPEND Command 179 A message may be added to a mailbox through the IMAP APPEND command. 180 In a server that advertises IMAPSieve, new messages added in this way 181 MUST trigger the execution of a Sieve script, subject to the settings 182 defined through Metadata (see Section 2.3.1). 184 2.2.2. The IMAP MULTIAPPEND Command 186 If the IMAP server supports the IMAP [MultiAppend] extension, 187 messages may be added to a mailbox through the IMAP MULTIAPPEND 188 command. In a server that advertises IMAPSieve, new messages added 189 in this way MUST trigger the execution of a Sieve script, as with the 190 APPEND command, also subject to the settings defined through 191 Metadata. 193 2.2.3. The IMAP COPY Command 195 One or more messages may be added to a mailbox through the IMAP COPY 196 command. In a server that advertises IMAPSieve, new messages added 197 in this way MUST trigger the execution of a Sieve script, subject to 198 the settings defined through Metadata. 200 2.2.4. Changes to IMAP Message Flags 202 One or more existing messages can have their flags changed in a 203 number of ways, including: 205 o The FETCH command (may cause the \Seen flag to be set). 207 o The STORE command (may cause the \Answered, \Deleted, \Draft, 208 \Flagged, and \Seen flags to be set or reset, and may cause 209 keywords to be set or reset). 211 o The invocation of a Sieve script on an existing message, where the 212 Sieve implementation supports the [IMAP4Flags] extension and the 213 script uses one of the actions defined in that extension. 215 In a server that advertises IMAPSieve, messages whose flags are 216 changed in any way (except as explained in the next sentence) MUST 217 trigger the execution of a Sieve script, subject to the settings 218 defined through Metadata. The exception is that in order to avoid 219 script loops, flag changes that are made as a result of a script that 220 was itself invoked because of flag changes SHOULD NOT result in 221 another script invocation. In any case, implementations MUST take 222 steps to avoid such loops. 224 For flag-change events, the Sieve script will see the message flags 225 as they are AFTER the changes. 227 2.2.5. New or Changed IMAP Message Annotations 229 If the IMAP server supports the [Annotate] extension, one or more 230 existing messages can have annotations added or changed through the 231 ANNOTATE command. In a server that advertises IMAPSieve, messages 232 getting new or changed annotations MUST trigger the execution of a 233 Sieve script, subject to the settings defined through Metadata. 235 For annotation-change events, the Sieve script will see the message 236 annotations as they are AFTER the changes. 238 2.3. New Functions Defined by IMAPSieve 240 2.3.1. Changes to Metadata 242 Support for IMAPSieve requires support for [Metadata] as well, since 243 the latter is used to associate scripts with IMAP mailboxes. 245 When an applicable event occurs on an IMAP mailbox, if there is an 246 IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that 247 entry is used. If there is not, but there is an IMAP metadata entry 248 named "/IMAPSieve/Script" for the server, that entry is used 249 (providing a way to define a global script for all mailboxes on a 250 server). If neither entry exists, then no script will be invoked. 252 If an "/IMAPSieve/Script" metadata entry was selected above, the 253 shared value of that metadata name (its "value.shared" attribute) 254 MUST be the name of the Sieve script that will be invoked in response 255 to the IMAP event OR the name of another metadata entry, the name 256 prefixed with "metadata:" (such as "metadata:/IMAPSieve/ 257 ScriptContents"), that contains the actual script in its value.shared 258 attribute. Note that only the value.shared attribute is used; any 259 value.priv attributes are ignored. 261 This specifies the mechanism for "activating" a script for a given 262 mailbox (or for all mailboxes), but does not specify a mechanism for 263 creating, storing, or validating the script. Implementations MAY use 264 [Manage] to acomplish this, using the PUTSCRIPT command to store the 265 script without using the SETACTIVE command to activate it. In any 266 case, the script name that is specified in the /IMAPSieve/Script 267 metadata entry is in a form that depends upon how the server handles 268 the storing of Sieve scripts. 270 Only one Sieve script may currently be defined per mailbox, 271 eliminating the complexity and possible ambiguity involved with 272 coordinating the results of multiple scripts. Any sub-filtering is 273 done in the Sieve script. For example, if it's only necessary to 274 deal with flag changes, but not with new messages appended or copied, 275 the Sieve script will still be invoked for all events, and the script 276 is responsible for checking the event type. 278 The possibility is open for an extensions to add support for multiple 279 scripts -- for example, per-client scripts on a multi-client user's 280 inbox, or per-user scripts on a mailbox that is shared among users. 282 Because this metadata name is associated with the mailbox, there can 283 (and it's expected that there will) be different scripts associated 284 with events for different mailboxes. Indeed, most mailboxes will 285 probably invoke no script at all. 287 3. Applicable Sieve Actions and Interactions 289 Since some Sieve actions relate specifically to the delivery of mail, 290 not all actions make sense when the messages are created by other 291 means or when changes are made to data associated with existing 292 messages. This section describes how actions in the base Sieve 293 specification, and those in extensions known at this writing, relate 294 to this specification. 296 In addition to what is specified here, interactions noted in the 297 individual specifications apply, and must be considered. 299 3.1. The Implicit Keep 301 For all cases that fall under IMAPSieve, the implicit keep means that 302 the message is treated as it would have been if no Sieve script were 303 run. For APPEND, MULTIAPPEND and COPY, the message is stored into 304 the target mailbox normally. For flag or annotation changes, the 305 message is left in the mailbox. 307 3.2. The Keep Action 309 The keep action is applicable in all cases that fall under IMAPSieve. 310 Its behaviour is as described for implicit keep, in Section 3.1. 312 3.3. The Fileinto Action 314 If the Sieve implementation supports the fileinto action, that action 315 is applicable in all cases that fall under IMAPSieve. If the [Copy] 316 extension is available and the :copy option is specified, the 317 implicit keep is retained; otherwise, fileinto cancels the implicit 318 keep, as specified in the base Sieve specification. 320 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 321 fileinto mailbox IN ADDITION TO the original target mailbox. For 322 flag or annotation changes, the message is COPIED into the fileinto 323 mailbox, without removing the original. 325 If a keep action is NOT also in effect, the original message is then 326 marked with the \Deleted flag (and a flag-change Sieve script is NOT 327 invoked). The implementation MAY then expunge the original message 328 (WITHOUT expunging other messages in the mailbox), or it MAY choose 329 to have expunges batched, or done by a user. If the server does the 330 expunge, the effect is as though a client had flagged the message and 331 done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. 332 Handling it this way allows clients to handle messages consistently, 333 and avoids hidden changes that might invalidate their message caches. 335 3.4. The Redirect Action 337 The redirect action is applicable in all cases that fall under 338 IMAPSieve. It causes the message to be sent, as specified in the 339 base Sieve specification, to the designated address. If the [Copy] 340 extension is available and the :copy option is specified, the 341 implicit keep is retained; otherwise, redirect cancels the implicit 342 keep, as specified in the base Sieve specification. 344 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 345 target mailbox in addition to being redirected. For flag or 346 annotation changes, the message remains in its original mailbox. 348 If a keep action is NOT also in effect, the original message is then 349 marked with the \Deleted flag (and a flag-change Sieve script is NOT 350 invoked). The implementation MAY then expunge the original message 351 (WITHOUT expunging other messages in the mailbox), or it MAY choose 352 to have expunges batched, or done by a user. If the server does the 353 expunge, the effect is as though a client had flagged the message and 354 done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. 355 Handling it this way allows clients to handle messages consistently, 356 and avoids hidden changes that might invalidate their message caches. 358 3.5. The Reject Action 360 The reject action is NOT applicable to any case that falls under 361 IMAPSieve. Its use MUST result in an error condition that will 362 terminate the Sieve script. 364 3.6. The Discard Action 366 The discard action is applicable in all cases that fall under 367 IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first 368 stored into the target mailbox. If an explicit keep action is also 369 in effect, the discard action now does nothing. Otherwise, the 370 original message is then marked with the \Deleted flag (and a flag- 371 change Sieve script is NOT invoked). The implementation MAY then 372 expunge the original message (WITHOUT expunging other messages in the 373 mailbox), or it MAY choose to have expunges batched, or done by a 374 user. If the server does the expunge, the effect is as though a 375 client had flagged the message and done a UID EXPUNGE (see [UIDPlus]) 376 on the affected message(s) only. Handling it this way allows clients 377 to handle messages consistently, and avoids hidden changes that might 378 invalidate their message caches. 380 3.7. The Notify Action 382 If the [Notify] extension is available, the notify action is 383 applicable in all cases that fall under IMAPSieve. The result is 384 that the requested notification is sent, and that the message is 385 otherwise handled as it would normally have been. 387 3.8. The Addheader and Deleteheader Actions 389 Even if the [EditHeader] extension is available, since messages in 390 IMAP mailboxes are immutable these actions are NOT applicable. Use 391 of these MUST result in an error condition that will terminate the 392 Sieve script. Explanation: Using them for flag or annotation changes 393 to existing messages would cause the message to be changed. Using 394 them for APPEND, MULTIAPPEND, and COPY would cause unexpected 395 differences in the stored copy as compared to what the client 396 expected, and would make the client's message cache invalid 397 unexpectedly. 399 3.9. The Setflag, Deleteflag, and Removeflag Actions 401 If the [IMAP4Flags] extension is available, the actions associated 402 with it are all applicable to any case that falls under IMAPSieve. 403 It is worth noting also that the "hasflag" test that is defined in 404 the IMAP4Flags extension might be particularly useful in scripts 405 triggered by flag changes ("hasflag" will see the new, changed 406 flags). The flag changes behave as though a client had made the 407 change. 409 As explained above, in order to avoid script loops flag changes that 410 are made as a result of a script that was itself invoked because of 411 flag changes SHOULD NOT result in another script invocation. In any 412 case, implementations MUST take steps to avoid such loops. 414 3.10. The Vacation Action 416 Even if the [Vacation] extension is available, the vacation action is 417 NOT applicable to any case that falls under IMAPSieve. Its use MUST 418 result in an error condition that will terminate the Sieve script. 420 3.11. New Sieve Environment Item: cause 422 Implementations MAY invoke different Sieve scripts for the different 423 conditions described in this document (append, copy, flag changes, 424 annotation changes). If the actions to be taken are common, and the 425 implementation supports the [Include] extension, the common script 426 code can be included as specified there. 428 It may be preferable, though, to use a single script for all these 429 conditions. To support that, the implementation MUST set the 430 [Environment] item "cause", which contains the name of the action 431 that caused the script to be invoked. Its value is one of the 432 following: 434 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 436 o COPY (for invocations resulting from COPY) 438 o FLAG (for invocations resulting from flag changes) 440 o ANNOTATE (for invocations resulting from new or changed 441 annotations) 443 3.12. New Sieve Environment Item: mailbox 445 The implementation MUST set the [Environment] item "mailbox" to the 446 name of the mailbox that the affected message is in, in the case of 447 existing messages, or is targeted to be stored into, in the case of 448 new messages. The value of this item is fixed when the script 449 begins, and, in particular, MUST NOT change as a result of any 450 action, such as "fileinto". 452 3.13. New Sieve Environment Item: changedflags 454 If the [IMAP4Flags] extension is available, AND the script was 455 invoked because of flag changes to an existing message, the 456 implementation MUST set the [Environment] item "changedflags" to the 457 name(s) of the flag(s) that have changed. If the script was not 458 invoked because of flag changes, the value of this item MUST be the 459 empty string. The script will not know from this item whether the 460 flags have been set or reset, but it can use the "hasflag" test to 461 determine the current value. See example 2 in Section 4 for an 462 example of how this might be used. 464 3.14. New Sieve Environment Item: changedannotations 466 If the [Annotate] extension is available, AND the script was invoked 467 because of annotation changes to an existing message, the 468 implementation MUST set the [Environment] item "changedannotations" 469 to the name(s) of the annotation(s) that have changed. If the script 470 was not invoked because of annotation changes, the value of this item 471 MUST be the empty string. 473 3.15. Interaction With Sieve Tests (Comparisons) 475 This extension does not affect the operation of any tests or 476 comparisons. 478 4. Examples 480 Example 1: 481 If a new message is added to the "ActionItems" mailbox, a copy is 482 sent to the address "actionitems@example.com". 484 require ["copy", "environment"]; 486 if anyof (environment :is "cause" "APPEND", 487 environment :is "cause" "COPY") { 488 if environment :is "mailbox" "ActionItems" { 489 redirect :copy "actionitems@example.com"; 490 } 491 } 493 Example 2: 494 If the script is called for any message with the \Flagged flag set 495 (tested through the [IMAP4Flags] extension), a notification is sent 496 using the [Notify] extension. No notification will be sent, though, 497 if we're called with an existing message that already had that flag 498 set. 500 require ["nofity", "imap4flags", "variables", "environment"]; 502 if environment :matches "mailbox" "*" { 503 set "mailbox" "${1}"; 504 } 506 if allof (hasflag "\\Flagged", 507 not environment :contains "changedflags" "\\Flagged") { 508 notify :message "Important message in ${mailbox}"; 509 } 511 5. Security Considerations 513 It is possible to introduce script processing loops by having a Sieve 514 script that is triggered by flag changes use the actions defined in 515 the [IMAP4Flags] extension. Implementations MUST take steps to 516 prevent such loops. One way to avoid this problem is that if a 517 script is invoked by flag changes, and that script further changes 518 the flags, those flag changes SHOULD NOT trigger a Sieve script 519 invocation. 521 Other security considerations are discussed in [IMAP], and [Sieve], 522 as well as in some of the other extension documents. 524 6. IANA Considerations 526 6.1. Registration of imapsieve extension 528 The following template specifies the IANA registration of the Sieve 529 extension specified in this document: 531 To: iana@iana.org 532 Subject: Registration of new Sieve extension 533 Capability name: imapsieve 534 Description: Add Sieve processing for IMAP events. 535 RFC number: this RFC 536 Contact address: Barry Leiba 538 This information should be added to the list of sieve extensions 539 given on http://www.iana.org/assignments/sieve-extensions. 541 6.2. Registration of environment item: cause 543 The following template specifies the IANA registration of a sieve 544 environment item specified in this document: 546 To: iana@iana.org 547 Subject: Registration of new Sieve environment item 548 Item name: cause 549 Description: The name of the action that caused the script to be 550 invoked. Its value is one of the following: 552 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 554 o COPY (for invocations resulting from COPY) 556 o FLAG (for invocations resulting from flag changes) 558 o ANNOTATE (for invocations resulting from new or changed 559 annotations) 561 RFC number: this RFC 562 Contact address: 563 Barry Leiba 565 This information should be added to the list of sieve environment 566 item names given in the [Environment] extension. 568 6.3. Registration of environment item: mailbox 570 The following template specifies the IANA registration of a sieve 571 environment item specified in this document: 573 To: iana@iana.org 574 Subject: Registration of new Sieve environment item 575 Item name: mailbox 576 Description: The name of the mailbox that the affected message is in, 577 in the case of existing messages, or is targeted to be stored into, 578 in the case of new messages. The value of this item is fixed when 579 the script begins, and, in particular, MUST NOT change as a result of 580 any action, such as "fileinto". 581 RFC number: this RFC 582 Contact address: 583 Barry Leiba 585 This information should be added to the list of sieve environment 586 item names given in the [Environment] extension. 588 6.4. Registration of environment item: changedflags 590 The following template specifies the IANA registration of a sieve 591 environment item specified in this document: 593 To: iana@iana.org 594 Subject: Registration of new Sieve environment item 595 Item name: changedflags 596 Description: If the script was invoked because of flag changes to an 597 existing message, this contains the name(s) of the flag(s) that have 598 changed. Otherwise, the value of this item MUST be the empty string. 599 RFC number: this RFC 600 Contact address: 601 Barry Leiba 603 This information should be added to the list of sieve environment 604 item names given in the [Environment] extension. 606 6.5. Registration of environment item: changedannotations 608 The following template specifies the IANA registration of a sieve 609 environment item specified in this document: 611 To: iana@iana.org 612 Subject: Registration of new Sieve environment item 613 Item name: changedannotations 614 Description: If the script was invoked because of annotation changes 615 to an existing message, this contains the name(s) of the 616 annotation(s) that have changed. Otherwise, the value of this item 617 MUST be the empty string. 618 RFC number: this RFC 619 Contact address: 620 Barry Leiba 622 This information should be added to the list of sieve environment 623 item names given in the [Environment] extension. 625 6.6. Registration of IMAP METADATA mailbox entry name 627 The following template specifies the IANA registration of an IMAP 628 METADATA entry name specified in this document: 630 To: iana@iana.org 631 Subject: IMAP METADATA Registration 632 Please register the following IMAP METADATA item: 633 [x] Entry [ ] Attribute 634 [x] Mailbox [ ] Server 635 Name: /IMAPSieve/Script 636 Description: This entry name is used to define mailbox metadata 637 associated with IMAPSieve events for the associated mailbox. 638 Specifically, this specifies the Sieve script that will be invoked 639 when IMAP events occur on the specified mailbox. 640 Content-type: text/plain; charset=utf-8 641 RFC number: this RFC 642 Contact person: Barry Leiba 643 Contact email: leiba@watson.ibm.com 645 This information should be added to the list of IMAP METADATA item 646 names given in the [Metadata] extension. 648 6.7. Registration of IMAP METADATA server entry name 650 The following template specifies the IANA registration of an IMAP 651 METADATA entry name specified in this document: 653 To: iana@iana.org 654 Subject: IMAP METADATA Registration 655 Please register the following IMAP METADATA item: 656 [x] Entry [ ] Attribute 657 [ ] Mailbox [x] Server 658 Name: /IMAPSieve/Script 659 Description: This entry name is used to define metadata associated 660 globally with IMAPSieve events for the associated server. 661 Specifically, this specifies the Sieve script that will be invoked 662 when IMAP events occur on any mailbox in the server that does not 663 have its own mailbox-level /IMAPSieve/Script entry. 664 Content-type: text/plain; charset=utf-8 665 RFC number: this RFC 666 Contact person: Barry Leiba 667 Contact email: leiba@watson.ibm.com 669 This information should be added to the list of IMAP METADATA item 670 names given in the [Metadata] extension. 672 7. References 674 7.1. Normative References 676 [Annotate] 677 Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", RFC 678 Editor Queue, draft-ietf-imapext-annotate-16, August 2006. 680 [Copy] Degener, J., "Sieve Extension: Copying Without Side 681 Effects", RFC 3894, October 2004. 683 [Environment] 684 Freed, N., "Sieve Email Filtering: Environment and Ihave 685 Extensions", work in 686 progress, draft-freed-sieve-environment-ihave-00, 687 November 2006. 689 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 690 4rev1", RFC 3501, March 2003. 692 [IMAP4Flags] 693 Melnikov, A., "Sieve Mail Filtering Language: IMAP flag 694 Extension", RFC Editor 695 Queue, draft-ietf-sieve-imapflags-05, May 2006. 697 [Keywds] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", RFC 2119, March 1997. 700 [Metadata] 701 Daboo, C., "IMAP METADATA Extension", work in 702 progress, draft-daboo-imap-annotatemore-11, February 2007. 704 [MultiAppend] 705 Crispin, M., "Internet Message Access Protocol (IMAP) - 706 MULTIAPPEND Extension", RFC 3502, March 2003. 708 [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 709 Filtering Language", IESG 710 Evaluation, draft-ietf-sieve-3028bis-12, February 2007. 712 7.2. Non-Normative References 714 [EditHeader] 715 Degener, J. and P. Guenther, "Sieve Email Filtering: 716 Editheader Extension", work in 717 progress, draft-ietf-sieve-editheader-07, November 2006. 719 [Include] Daboo, C., "SIEVE Email Filtering: Include Extension", 720 work in progress, draft-daboo-sieve-include-05, June 2006. 722 [Manage] Martin, T. and A. Melnikov, Ed., "A Protocol for Remotely 723 Managing Sieve Scripts", work in 724 progress, draft-martin-managesieve-07, November 2006. 726 [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 727 Martin, "Sieve Extension: Notifications", work in 728 progress, draft-ietf-sieve-notify-07, February 2007. 730 [UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - 731 UIDPLUS Extension", RFC 4315, December 2005. 733 [Vacation] 734 Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: 735 Vacation Extension", RFC Editor 736 Queue, draft-ietf-sieve-vacation-06, February 2006. 738 Author's Address 740 Barry Leiba 741 IBM T.J. Watson Research Center 742 19 Skyline Drive 743 Hawthorne, NY 10532 744 US 746 Phone: +1 914 784 7941 747 Email: leiba@watson.ibm.com 749 Full Copyright Statement 751 Copyright (C) The IETF Trust (2008). 753 This document is subject to the rights, licenses and restrictions 754 contained in BCP 78, and except as set forth therein, the authors 755 retain all their rights. 757 This document and the information contained herein are provided on an 758 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 759 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 760 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 761 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 762 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 763 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 765 Intellectual Property 767 The IETF takes no position regarding the validity or scope of any 768 Intellectual Property Rights or other rights that might be claimed to 769 pertain to the implementation or use of the technology described in 770 this document or the extent to which any license under such rights 771 might or might not be available; nor does it represent that it has 772 made any independent effort to identify any such rights. Information 773 on the procedures with respect to rights in RFC documents can be 774 found in BCP 78 and BCP 79. 776 Copies of IPR disclosures made to the IETF Secretariat and any 777 assurances of licenses to be made available, or the result of an 778 attempt made to obtain a general license or permission for the use of 779 such proprietary rights by implementers or users of this 780 specification can be obtained from the IETF on-line IPR repository at 781 http://www.ietf.org/ipr. 783 The IETF invites any interested party to bring to its attention any 784 copyrights, patents or patent applications, or other proprietary 785 rights that may cover technology that may be required to implement 786 this standard. Please address the information to the IETF at 787 ietf-ipr@ietf.org. 789 Acknowledgment 791 Funding for the RFC Editor function is provided by the IETF 792 Administrative Support Activity (IASA).