idnits 2.17.1 draft-ietf-sieve-imap-sieve-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 date (January 26, 2010) is 5202 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 RFC: RFC 5257 (ref. 'Annotate') ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track January 26, 2010 5 Expires: July 30, 2010 7 Support for Sieve in Internet Message Access Protocol (IMAP4) 8 draft-ietf-sieve-imap-sieve-00 10 Abstract 12 Sieve defines an email filtering language that can, in principle, 13 plug into any point in the processing of an email message. As 14 defined in the base specification, it plugs into mail delivery. This 15 document defines how Sieve can plug into points in the IMAP protocol 16 where messages are created or changed, adding the option of user- 17 defined or installation-defined filtering (or, with Sieve extensions, 18 features such as notifications). 20 Note 22 This document defines extensions to IMAP and Sieve. It is the work 23 of the Sieve Working Group, but had previously been in the lemonade 24 mailing list, as draft-ietf-lemonade-imap-sieve. 26 1. Discussion of this document should be taken to the Sieve mailing 27 list at mailto:sieve@ietf.org 29 2. Subscription requests can be sent to 30 mailto:sieve@ietf.org?body=subscribe (send an email message with 31 the word "subscribe" in the body). 33 3. A WWW archive of back messages is available at 34 http://www.ietf.org/mail-archive/web/sieve/index.html 36 4. Older messages, which were posted to the lemonade mailing list, 37 are archived at 38 http://www.ietf.org/mail-archive/web/lemonade/index.html 40 Status of this Memo 42 This Internet-Draft is submitted to IETF in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as Internet- 48 Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt. 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html. 61 This Internet-Draft will expire on July 30, 2010. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 1.2. Conventions used in this document . . . . . . . . . . . . 6 84 2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 7 85 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 7 86 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 7 87 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 88 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7 89 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 8 90 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 8 91 2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8 92 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 9 93 2.3.1. Changes to Metadata . . . . . . . . . . . . . . . . . . . 9 95 3. Applicable Sieve Actions and Interactions . . . . . . . . 11 96 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 11 97 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 11 98 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 11 99 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 12 100 3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 12 101 3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 12 102 3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 13 103 3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 13 104 3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13 105 3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 14 106 3.11. Spamtest . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 3.12. New Sieve Environment Item: cause . . . . . . . . . . . . 14 108 3.13. New Sieve Environment Item: mailbox . . . . . . . . . . . 14 109 3.14. New Sieve Environment Item: changedflags . . . . . . . . . 15 110 3.15. New Sieve Environment Item: changedannotations . . . . . . 15 111 3.16. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15 113 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 115 5. Security Considerations . . . . . . . . . . . . . . . . . 17 117 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 118 6.1. Registration of imapsieve extension . . . . . . . . . . . 18 119 6.2. Registration of environment item: cause . . . . . . . . . 18 120 6.3. Registration of environment item: mailbox . . . . . . . . 18 121 6.4. Registration of environment item: changedflags . . . . . . 19 122 6.5. Registration of environment item: changedannotations . . . 19 123 6.6. Registration of IMAP METADATA mailbox entry name . . . . . 20 124 6.7. Registration of IMAP METADATA server entry name . . . . . 20 125 7. References . . . . . . . . . . . . . . . . . . . . . . . . 22 126 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 127 7.2. Non-Normative References . . . . . . . . . . . . . . . . . 22 129 Author's Address . . . . . . . . . . . . . . . . . . . . . 24 131 1. Introduction 133 1.1. Overview 135 Some applications have a need to apply [Sieve] filters in situations 136 other than initial mail delivery. This is especially true in diverse 137 service environments, such as when the client is sporadically 138 connected, is connected through a high-latency or high-cost channel, 139 or is on a limited-function device. For such clients, it may be very 140 important, for higher performance and reliability, to take advantage 141 of server capabilities, including those provided by Sieve filtering 142 (and Sieve extensions, such as [Notify]). 144 This specification defines extensions to [IMAP] to support the 145 invocation of Sieve scripts at times when the IMAP server creates new 146 messages, or modifies existing ones. It also defines how Sieve 147 scripts will process these invocations. Support for IMAPSieve 148 requires support for [Metadata] as well, since the latter is used to 149 associate scripts with IMAP mailboxes. 151 [[anchor1: General note: Sieve was designed to work at final 152 delivery, and makes many assumptions about the context. Will those 153 assumptions break this environment without our realizing it fully?]] 155 [[anchor2: Note about identity: We might want to use Sieve to impose 156 fine-grained access controls. In final delivery, there's no identity 157 for the "filer". Here, there is: the logged-in IMAP user. How do we 158 get at that identity?]] 160 1.2. Conventions used in this document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 164 be interpreted as described in [Keywds]. 166 2. The IMAP "IMAPSieve" Extension 168 2.1. The "IMAPSieve" Capability String 170 An IMAP server advertises support for this extension through the 171 capability string "IMAPSieve" (the string is not case-sensitive, and 172 is shown here with this capitalization for readability). A server 173 that advertises IMAPSieve is claiming to be in compliance with this 174 specification in all aspects. 176 Implementations that support IMAPSieve MUST also support 177 [Environment], because the latter defines an important way for Sieve 178 scripts to test the conditions under which they have been invoked. 179 Notwithstanding this requirement, scripts that use IMAPSieve must 180 include BOTH capability strings in their required lists. 182 2.2. Existing IMAP Functions Affected by IMAPSieve 184 The subsections below describe in detail the IMAP commands and 185 situations on which IMAPSieve has an effect. Not all Sieve actions 186 make sense in the case of messages affected by IMAP commands. See 187 Section 3 for details. 189 It's important to note that since the base Sieve specification (see 190 [Sieve]) and its extensions define functions for scripts that are 191 invoked during initial mail delivery, those function definitions are 192 necessarily tailored to and limited by that context. This document 193 extends those function definitions for use during IMAP events. By 194 nature of that, Sieve functions, in this extended context, may behave 195 somewhat differently, though their extended behaviour will still be 196 consistent with the functions' goals. 198 If more than one message is affected at the same time, each message 199 triggers the execution of a Sieve script separately. The scripts MAY 200 be run in parallel. 202 2.2.1. The IMAP APPEND Command 204 A message may be added to a mailbox through the IMAP APPEND command. 205 In a server that advertises IMAPSieve, new messages added in this way 206 MUST trigger the execution of a Sieve script, subject to the settings 207 defined through Metadata (see Section 2.3.1). 209 2.2.2. The IMAP MULTIAPPEND Command 211 If the IMAP server supports the IMAP [MultiAppend] extension, 212 messages may be added to a mailbox through the IMAP MULTIAPPEND 213 command. In a server that advertises IMAPSieve, new messages added 214 in this way MUST trigger the execution of a Sieve script, as with the 215 APPEND command, also subject to the settings defined through 216 Metadata. 218 2.2.3. The IMAP COPY Command 220 One or more messages may be added to a mailbox through the IMAP COPY 221 command. In a server that advertises IMAPSieve, new messages added 222 in this way MUST trigger the execution of a Sieve script, subject to 223 the settings defined through Metadata. 225 2.2.4. Changes to IMAP Message Flags 227 One or more existing messages can have their flags changed in a 228 number of ways, including: 230 o The FETCH command (may cause the \Seen flag to be set). 232 o The STORE command (may cause the \Answered, \Deleted, \Draft, 233 \Flagged, and \Seen flags to be set or reset, and may cause 234 keywords to be set or reset). 236 o The invocation of a Sieve script on an existing message, where the 237 Sieve implementation supports the [IMAP4Flags] extension and the 238 script uses one of the actions defined in that extension. 240 In a server that advertises IMAPSieve, messages whose flags are 241 changed in any way (except as explained in the next sentence) MUST 242 trigger the execution of a Sieve script, subject to the settings 243 defined through Metadata. The exception is that in order to avoid 244 script loops, flag changes that are made as a result of a script that 245 was itself invoked because of flag changes SHOULD NOT result in 246 another script invocation. In any case, implementations MUST take 247 steps to avoid such loops. 249 For flag-change events, the Sieve script will see the message flags 250 as they are AFTER the changes. 252 2.2.5. New or Changed IMAP Message Annotations 254 [[anchor3: Sieve has no way to get the annotations, so is there 255 really value in being told about annotation changes here? Maybe push 256 that into a sieve-annotations extension later.]] 258 If the IMAP server supports the [Annotate] extension, one or more 259 existing messages can have annotations added or changed through the 260 ANNOTATE command. In a server that advertises IMAPSieve, messages 261 getting new or changed annotations MUST trigger the execution of a 262 Sieve script, subject to the settings defined through Metadata. 264 For annotation-change events, the Sieve script will see the message 265 annotations as they are AFTER the changes. 267 2.3. New Functions Defined by IMAPSieve 269 2.3.1. Changes to Metadata 271 Support for IMAPSieve requires support for [Metadata] as well, since 272 the latter is used to associate scripts with IMAP mailboxes. 274 When an applicable event occurs on an IMAP mailbox, if there is an 275 IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that 276 entry is used. If there is not, but there is an IMAP metadata entry 277 named "/IMAPSieve/Script" for the server, that entry is used 278 (providing a way to define a global script for all mailboxes on a 279 server). If neither entry exists, then no script will be invoked. 281 If an "/IMAPSieve/Script" metadata entry was selected above, the 282 shared value of that metadata name (its "value.shared" attribute) 283 MUST be the name of the Sieve script that will be invoked in response 284 to the IMAP event OR the name of another metadata entry, the name 285 prefixed with "metadata:" (such as "metadata:/IMAPSieve/ 286 ScriptContents"), that contains the actual script in its value.shared 287 attribute. Note that only the value.shared attribute is used; any 288 value.priv attributes are ignored. 290 This specifies the mechanism for "activating" a script for a given 291 mailbox (or for all mailboxes), but does not specify a mechanism for 292 creating, storing, or validating the script. Implementations MAY use 293 [Manage] to acomplish this, using the PUTSCRIPT command to store the 294 script without using the SETACTIVE command to activate it. In any 295 case, the script name that is specified in the /IMAPSieve/Script 296 metadata entry is in a form that depends upon how the server handles 297 the storing of Sieve scripts. 299 Only one Sieve script may currently be defined per mailbox, 300 eliminating the complexity and possible ambiguity involved with 301 coordinating the results of multiple scripts. Any sub-filtering is 302 done in the Sieve script. For example, if it's only necessary to 303 deal with flag changes, but not with new messages appended or copied, 304 the Sieve script will still be invoked for all events, and the script 305 is responsible for checking the event type. 307 The possibility is open for an extensions to add support for multiple 308 scripts -- for example, per-client scripts on a multi-client user's 309 inbox, or per-user scripts on a mailbox that is shared among users. 311 Because this metadata name is associated with the mailbox, there can 312 (and it's expected that there will) be different scripts associated 313 with events for different mailboxes. Indeed, most mailboxes will 314 probably invoke no script at all. 316 3. Applicable Sieve Actions and Interactions 318 Since some Sieve actions relate specifically to the delivery of mail, 319 not all actions make sense when the messages are created by other 320 means or when changes are made to data associated with existing 321 messages. This section describes how actions in the base Sieve 322 specification, and those in extensions known at this writing, relate 323 to this specification. 325 In addition to what is specified here, interactions noted in the 326 individual specifications apply, and must be considered. 328 3.1. The Implicit Keep 330 For all cases that fall under IMAPSieve, the implicit keep means that 331 the message is treated as it would have been if no Sieve script were 332 run. For APPEND, MULTIAPPEND and COPY, the message is stored into 333 the target mailbox normally. For flag or annotation changes, the 334 message is left in the mailbox. 336 3.2. The Keep Action 338 The keep action is applicable in all cases that fall under IMAPSieve. 339 Its behaviour is as described for implicit keep, in Section 3.1. 341 3.3. The Fileinto Action 343 If the Sieve implementation supports the fileinto action, that action 344 is applicable in all cases that fall under IMAPSieve. If the [Copy] 345 extension is available and the :copy option is specified, the 346 implicit keep is retained; otherwise, fileinto cancels the implicit 347 keep, as specified in the base Sieve specification. 349 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 350 fileinto mailbox IN ADDITION TO the original target mailbox. For 351 flag or annotation changes, the message is COPIED into the fileinto 352 mailbox, without removing the original. 354 If a keep action is NOT also in effect, the original message is then 355 marked with the \Deleted flag (and a flag-change Sieve script is NOT 356 invoked). The implementation MAY then expunge the original message 357 (WITHOUT expunging other messages in the mailbox), or it MAY choose 358 to have expunges batched, or done by a user. If the server does the 359 expunge, the effect is as though a client had flagged the message and 360 done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. 361 Handling it this way allows clients to handle messages consistently, 362 and avoids hidden changes that might invalidate their message caches. 364 3.4. The Redirect Action 366 [[anchor4: Redirect assumes message can be submitted as is - not a 367 valid assumption in this context. What do we do if the decision is 368 "redirect" and there's not enough information to do it? Also, some 369 have been concerned about, say, a flag change that has the Sieve 370 effect of forwarding the message somewhere. Perhaps we should just 371 forbid redirect.]] 373 The redirect action is applicable in all cases that fall under 374 IMAPSieve. It causes the message to be sent, as specified in the 375 base Sieve specification, to the designated address. If the [Copy] 376 extension is available and the :copy option is specified, the 377 implicit keep is retained; otherwise, redirect cancels the implicit 378 keep, as specified in the base Sieve specification. 380 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 381 target mailbox in addition to being redirected. For flag or 382 annotation changes, the message remains in its original mailbox. 384 If a keep action is NOT also in effect, the original message is then 385 marked with the \Deleted flag (and a flag-change Sieve script is NOT 386 invoked). The implementation MAY then expunge the original message 387 (WITHOUT expunging other messages in the mailbox), or it MAY choose 388 to have expunges batched, or done by a user. If the server does the 389 expunge, the effect is as though a client had flagged the message and 390 done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. 391 Handling it this way allows clients to handle messages consistently, 392 and avoids hidden changes that might invalidate their message caches. 394 3.5. The Reject Action 396 The reject action is NOT applicable to any case that falls under 397 IMAPSieve. Its use MUST result in an error condition that will 398 terminate the Sieve script. 400 3.6. The Discard Action 402 The discard action is applicable in all cases that fall under 403 IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first 404 stored into the target mailbox. If an explicit keep action is also 405 in effect, the discard action now does nothing. Otherwise, the 406 original message is then marked with the \Deleted flag (and a flag- 407 change Sieve script is NOT invoked). The implementation MAY then 408 expunge the original message (WITHOUT expunging other messages in the 409 mailbox), or it MAY choose to have expunges batched, or done by a 410 user. If the server does the expunge, the effect is as though a 411 client had flagged the message and done a UID EXPUNGE (see [UIDPlus]) 412 on the affected message(s) only. Handling it this way allows clients 413 to handle messages consistently, and avoids hidden changes that might 414 invalidate their message caches. 416 3.7. The Notify Action 418 If the [Notify] extension is available, the notify action is 419 applicable in all cases that fall under IMAPSieve. The result is 420 that the requested notification is sent, and that the message is 421 otherwise handled as it would normally have been. 423 3.8. The Addheader and Deleteheader Actions 425 [[anchor5: Should editheader be allowed to change header fields that 426 aren't saved in place, such as for redirect or fileinto? Editheader 427 would still have to be banned for "keep", but not otherwise.]] 429 Even if the [EditHeader] extension is available, since messages in 430 IMAP mailboxes are immutable these actions are NOT applicable. Use 431 of these MUST result in an error condition that will terminate the 432 Sieve script. Explanation: Using them for flag or annotation changes 433 to existing messages would cause the message to be changed. Using 434 them for APPEND, MULTIAPPEND, and COPY would cause unexpected 435 differences in the stored copy as compared to what the client 436 expected, and would make the client's message cache invalid 437 unexpectedly. 439 3.9. The Setflag, Deleteflag, and Removeflag Actions 441 [[anchor6: Should this just require imap4flags? Some implementors 442 have said they wouldn't bother with it without the ability to 443 manipulate flags. And what values of flags does it see -- before or 444 after the change? If it changes them, can it see the originals? Can 445 it reset changes?]] 447 If the [IMAP4Flags] extension is available, the actions associated 448 with it are all applicable to any case that falls under IMAPSieve. 449 It is worth noting also that the "hasflag" test that is defined in 450 the IMAP4Flags extension might be particularly useful in scripts 451 triggered by flag changes ("hasflag" will see the new, changed 452 flags). The flag changes behave as though a client had made the 453 change. 455 As explained above, in order to avoid script loops flag changes that 456 are made as a result of a script that was itself invoked because of 457 flag changes SHOULD NOT result in another script invocation. In any 458 case, implementations MUST take steps to avoid such loops. 460 3.10. The Vacation Action 462 Even if the [Vacation] extension is available, the vacation action is 463 NOT applicable to any case that falls under IMAPSieve. Its use MUST 464 result in an error condition that will terminate the Sieve script. 466 3.11. Spamtest 468 [Spamtest] [[anchor7: We need to say something about the spamtest/ 469 virustest extension. We need to be able to scan appended messages. 470 And we can't use headers to communicate spam status, because the 471 message is immutable. What should we say here?]] 473 3.12. New Sieve Environment Item: cause 475 Implementations MAY invoke different Sieve scripts for the different 476 conditions described in this document (append, copy, flag changes, 477 annotation changes). If the actions to be taken are common, and the 478 implementation supports the [Include] extension, the common script 479 code can be included as specified there. 481 It may be preferable, though, to use a single script for all these 482 conditions. To support that, the implementation MUST set the 483 [Environment] item "cause", which contains the name of the action 484 that caused the script to be invoked. Its value is one of the 485 following: 487 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 489 o COPY (for invocations resulting from COPY) 491 o FLAG (for invocations resulting from flag changes) 493 o ANNOTATE (for invocations resulting from new or changed 494 annotations) 496 3.13. New Sieve Environment Item: mailbox 498 The implementation MUST set the [Environment] item "mailbox" to the 499 name of the mailbox that the affected message is in, in the case of 500 existing messages, or is targeted to be stored into, in the case of 501 new messages. The value of this item is fixed when the script 502 begins, and, in particular, MUST NOT change as a result of any 503 action, such as "fileinto". 505 3.14. New Sieve Environment Item: changedflags 507 If the [IMAP4Flags] extension is available, AND the script was 508 invoked because of flag changes to an existing message, the 509 implementation MUST set the [Environment] item "changedflags" to the 510 name(s) of the flag(s) that have changed. If the script was not 511 invoked because of flag changes, the value of this item MUST be the 512 empty string. The script will not know from this item whether the 513 flags have been set or reset, but it can use the "hasflag" test to 514 determine the current value. See example 2 in Section 4 for an 515 example of how this might be used. 517 3.15. New Sieve Environment Item: changedannotations 519 If the [Annotate] extension is available, AND the script was invoked 520 because of annotation changes to an existing message, the 521 implementation MUST set the [Environment] item "changedannotations" 522 to the name(s) of the annotation(s) that have changed. If the script 523 was not invoked because of annotation changes, the value of this item 524 MUST be the empty string. 526 3.16. Interaction With Sieve Tests (Comparisons) 528 This extension does not affect the operation of any tests or 529 comparisons. 531 4. Examples 533 Example 1: 534 If a new message is added to the "ActionItems" mailbox, a copy is 535 sent to the address "actionitems@example.com". 537 require ["copy", "environment"]; 539 if anyof (environment :is "cause" "APPEND", 540 environment :is "cause" "COPY") { 541 if environment :is "mailbox" "ActionItems" { 542 redirect :copy "actionitems@example.com"; 543 } 544 } 546 Example 2: 547 If the script is called for any message with the \Flagged flag set 548 (tested through the [IMAP4Flags] extension), a notification is sent 549 using the [Notify] extension. No notification will be sent, though, 550 if we're called with an existing message that already had that flag 551 set. 553 require ["notify", "imap4flags", "variables", "environment"]; 555 if environment :matches "mailbox" "*" { 556 set "mailbox" "${1}"; 557 } 559 if allof (hasflag "\\Flagged", 560 not environment :contains "changedflags" "\\Flagged") { 561 notify :message "Important message in ${mailbox}"; 562 } 564 5. Security Considerations 566 It is possible to introduce script processing loops by having a Sieve 567 script that is triggered by flag changes use the actions defined in 568 the [IMAP4Flags] extension. Implementations MUST take steps to 569 prevent such loops. One way to avoid this problem is that if a 570 script is invoked by flag changes, and that script further changes 571 the flags, those flag changes SHOULD NOT trigger a Sieve script 572 invocation. 574 Other security considerations are discussed in [IMAP], and [Sieve], 575 as well as in some of the other extension documents. 577 6. IANA Considerations 579 6.1. Registration of imapsieve extension 581 The following template specifies the IANA registration of the Sieve 582 extension specified in this document: 584 To: iana@iana.org 585 Subject: Registration of new Sieve extension 586 Capability name: imapsieve 587 Description: Add Sieve processing for IMAP events. 588 RFC number: this RFC 589 Contact address: Barry Leiba 591 This information should be added to the list of sieve extensions 592 given on http://www.iana.org/assignments/sieve-extensions. 594 6.2. Registration of environment item: cause 596 The following template specifies the IANA registration of a sieve 597 environment item specified in this document: 599 To: iana@iana.org 600 Subject: Registration of new Sieve environment item 601 Item name: cause 602 Description: The name of the action that caused the script to be 603 invoked. Its value is one of the following: 605 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 607 o COPY (for invocations resulting from COPY) 609 o FLAG (for invocations resulting from flag changes) 611 o ANNOTATE (for invocations resulting from new or changed 612 annotations) 614 RFC number: this RFC 615 Contact address: 616 Barry Leiba 618 This information should be added to the list of sieve environment 619 item names given in the [Environment] extension. 621 6.3. Registration of environment item: mailbox 623 The following template specifies the IANA registration of a sieve 624 environment item specified in this document: 626 To: iana@iana.org 627 Subject: Registration of new Sieve environment item 628 Item name: mailbox 629 Description: The name of the mailbox that the affected message is in, 630 in the case of existing messages, or is targeted to be stored into, 631 in the case of new messages. The value of this item is fixed when 632 the script begins, and, in particular, MUST NOT change as a result of 633 any action, such as "fileinto". 634 RFC number: this RFC 635 Contact address: 636 Barry Leiba 638 This information should be added to the list of sieve environment 639 item names given in the [Environment] extension. 641 6.4. Registration of environment item: changedflags 643 The following template specifies the IANA registration of a sieve 644 environment item specified in this document: 646 To: iana@iana.org 647 Subject: Registration of new Sieve environment item 648 Item name: changedflags 649 Description: If the script was invoked because of flag changes to an 650 existing message, this contains the name(s) of the flag(s) that have 651 changed. Otherwise, the value of this item MUST be the empty string. 652 RFC number: this RFC 653 Contact address: 654 Barry Leiba 656 This information should be added to the list of sieve environment 657 item names given in the [Environment] extension. 659 6.5. Registration of environment item: changedannotations 661 The following template specifies the IANA registration of a sieve 662 environment item specified in this document: 664 To: iana@iana.org 665 Subject: Registration of new Sieve environment item 666 Item name: changedannotations 667 Description: If the script was invoked because of annotation changes 668 to an existing message, this contains the name(s) of the 669 annotation(s) that have changed. Otherwise, the value of this item 670 MUST be the empty string. 671 RFC number: this RFC 672 Contact address: 673 Barry Leiba 675 This information should be added to the list of sieve environment 676 item names given in the [Environment] extension. 678 6.6. Registration of IMAP METADATA mailbox entry name 680 The following template specifies the IANA registration of an IMAP 681 METADATA entry name specified in this document: 683 To: iana@iana.org 684 Subject: IMAP METADATA Registration 685 Please register the following IMAP METADATA item: 686 [x] Entry [ ] Attribute 687 [x] Mailbox [ ] Server 688 Name: /IMAPSieve/Script 689 Description: This entry name is used to define mailbox metadata 690 associated with IMAPSieve events for the associated mailbox. 691 Specifically, this specifies the Sieve script that will be invoked 692 when IMAP events occur on the specified mailbox. 693 Content-type: text/plain; charset=utf-8 694 RFC number: this RFC 695 Contact person: Barry Leiba 696 Contact email: barryleiba@computer.org 698 This information should be added to the list of IMAP METADATA item 699 names given in the [Metadata] extension. 701 6.7. Registration of IMAP METADATA server entry name 703 The following template specifies the IANA registration of an IMAP 704 METADATA entry name specified in this document: 706 To: iana@iana.org 707 Subject: IMAP METADATA Registration 708 Please register the following IMAP METADATA item: 709 [x] Entry [ ] Attribute 710 [ ] Mailbox [x] Server 711 Name: /IMAPSieve/Script 712 Description: This entry name is used to define metadata associated 713 globally with IMAPSieve events for the associated server. 714 Specifically, this specifies the Sieve script that will be invoked 715 when IMAP events occur on any mailbox in the server that does not 716 have its own mailbox-level /IMAPSieve/Script entry. 717 Content-type: text/plain; charset=utf-8 718 RFC number: this RFC 719 Contact person: Barry Leiba 720 Contact email: barryleiba@computer.org 722 This information should be added to the list of IMAP METADATA item 723 names given in the [Metadata] extension. 725 7. References 727 7.1. Normative References 729 [Annotate] 730 Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", 731 RFC 5257, June 2008. 733 [Copy] Degener, J., "Sieve Extension: Copying Without Side 734 Effects", RFC 3894, October 2004. 736 [Environment] 737 Freed, N., "Sieve Email Filtering: Environment Extension", 738 RFC 5183, May 2008. 740 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 741 4rev1", RFC 3501, March 2003. 743 [IMAP4Flags] 744 Melnikov, A., "Sieve Mail Filtering Language: IMAP flag 745 Extension", RFC 5232, January 2008. 747 [Keywds] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", RFC 2119, March 1997. 750 [Metadata] 751 Daboo, C., "The IMAP METADATA Extension", RFC 5464, 752 February 2009. 754 [MultiAppend] 755 Crispin, M., "Internet Message Access Protocol (IMAP) - 756 MULTIAPPEND Extension", RFC 3502, March 2003. 758 [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 759 Filtering Language", RFC 5228, January 2008. 761 7.2. Non-Normative References 763 [EditHeader] 764 Degener, J. and P. Guenther, "Sieve Email Filtering: 765 Editheader Extension", RFC 5293, August 2008. 767 [Include] Daboo, C. and A. Stone, "SIEVE Email Filtering: Include 768 Extension", work in progress, http://tools.ietf.org/html/ 769 draft-ietf-sieve-include, July 2009. 771 [Manage] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 772 Managing Sieve Scripts", RFC editor queue, http:// 773 tools.ietf.org/html/draft-ietf-sieve-managesieve, 774 January 2009. 776 [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 777 Martin, "Sieve Email Filtering: Extension for 778 Notifications", RFC 5435, January 2009. 780 [Spamtest] 781 Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 782 Extensions", RFC 5235, January 2008. 784 [UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - 785 UIDPLUS Extension", RFC 4315, December 2005. 787 [Vacation] 788 Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: 789 Vacation Extension", RFC 5230, January 2008. 791 Author's Address 793 Barry Leiba 794 Huawei Technologies 796 Phone: +1 646 827 0648 797 Email: barryleiba@computer.org 798 URI: http://internetmessagingtechnology.org/