idnits 2.17.1 draft-ietf-sieve-imap-sieve-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 6, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) Summary: 2 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 March 6, 2012 5 Expires: September 7, 2012 7 Support for Internet Message Access Protocol (IMAP) Events in Sieve 8 draft-ietf-sieve-imap-sieve-03 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 [[anchor1: RFC Editor: Please remove this note prior to 23 publication.]] 25 This document defines extensions to IMAP and Sieve. It is the work 26 of the Sieve Working Group, but had previously been in the lemonade 27 mailing list, as draft-ietf-lemonade-imap-sieve. 29 1. Discussion of this document should be taken to the Sieve mailing 30 list at mailto:sieve@ietf.org 32 2. Subscription requests can be sent to 33 mailto:sieve@ietf.org?body=subscribe (send an email message with 34 the word "subscribe" in the body). 36 3. A WWW archive of back messages is available at 37 http://www.ietf.org/mail-archive/web/sieve/index.html 39 4. Older messages, which were posted to the lemonade mailing list, 40 are archived at 41 http://www.ietf.org/mail-archive/web/lemonade/index.html 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 7, 2012. 60 Copyright Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 78 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 1.2. Differences Between IMAP Events and Mail Delivery . . . . 5 80 1.3. Conventions used in this document . . . . . . . . . . . . 6 81 1.4. Notes from Reviews, and To-Do Items . . . . . . . . . . . 6 83 2. The IMAP Events in Sieve Extension . . . . . . . . . . . . 8 84 2.1. The "imapsieve" Capability Strings . . . . . . . . . . . . 8 85 2.2. Existing IMAP Functions Affected by IMAP events in 86 Sieve . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 8 88 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 9 89 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 9 90 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 9 91 2.3. New Functions Defined by IMAP events in Sieve . . . . . . 9 92 2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 10 94 3. Applicable Sieve Actions and Interactions . . . . . . . . 11 95 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 11 96 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 11 97 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 11 98 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 12 99 3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 12 100 3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 13 101 3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 13 102 3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13 103 3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 13 104 3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 14 105 3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 14 107 4. Interaction With Sieve Environment . . . . . . . . . . . . 15 108 4.1. Base Sieve Environment Items: location and phase . . . . . 15 109 4.2. New Sieve Environment Items: imapuser and imapemail . . . 15 110 4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 15 111 4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 16 112 4.5. New Sieve Environment Item: changedflags . . . . . . . . . 16 113 4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 16 114 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 116 6. Security Considerations . . . . . . . . . . . . . . . . . 18 118 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 119 7.1. Registration of "imapsieve" IMAP capability . . . . . . . 19 120 7.2. Registration of imapsieve Sieve extension . . . . . . . . 19 121 7.3. Registration of environment item: cause . . . . . . . . . 19 122 7.4. Registration of environment item: mailbox . . . . . . . . 20 123 7.5. Registration of environment item: changedflags . . . . . . 20 124 7.6. Registration of environment item: imapuser . . . . . . . . 20 125 7.7. Registration of environment item: imapemail . . . . . . . 21 126 7.8. Registration of IMAP METADATA mailbox entry name . . . . . 21 127 7.9. Registration of IMAP METADATA server entry name . . . . . 22 129 8. References . . . . . . . . . . . . . . . . . . . . . . . . 23 130 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 131 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 23 133 Author's Address . . . . . . . . . . . . . . . . . . . . . 25 135 1. Introduction 137 1.1. Overview 139 Some applications have a need to apply Sieve filters [RFC5228] in 140 contexts other than initial mail delivery. This is especially true 141 in diverse service environments, such as when the client is 142 sporadically connected, is connected through a high-latency or high- 143 cost channel, or is on a limited-function device. For such clients, 144 it may be very important, for higher performance and reliability, to 145 take advantage of server capabilities, including those provided by 146 Sieve filtering (and Sieve extensions, such as Notify [RFC5435]). 148 This specification defines extensions to IMAP [RFC3501] to support 149 the invocation of Sieve scripts at times when the IMAP server creates 150 new messages or modifies existing ones. It also defines how Sieve 151 scripts will process these invocations. Support for IMAP events in 152 Sieve requires support for IMAP Metadata [RFC5464] and Sieve 153 Environment [RFC5183] as well, because Metadata is used to associate 154 scripts with IMAP mailboxes and Environment defines an important way 155 for Sieve scripts to test the conditions under which they have been 156 invoked. 158 1.2. Differences Between IMAP Events and Mail Delivery 160 Invoking Sieve scripts in a context other than initial mail delivery 161 introduces new situations, which changes the applicability of Sieve 162 features and creates implementation challenges and user interface 163 issues. This section discusses some of those differences, 164 challenges, and issues. 166 At times other than message delivery, delivery "envelope" 167 information, might not be available. With messages added through 168 IMAP APPEND, there might be no way to even guess who the intended 169 recipient is, and no concept of who "sent" the message. Sieve 170 actions that relate to contacting the sender, for example, will not 171 be applicable. 173 Because IMAP events will often be triggered by user actions, and 174 because user interfaces allow bulk actions that differ from 175 individual message arrival, it now becomes possible for a single user 176 action, such as drag-and-drop, to initiate Sieve script processing on 177 a large number of messages at once. Implementations will have to 178 deal with such situations as a "COPY" action or flag changes on 179 dozens, or even thousands of messages. 181 Other issues might surface as this extension is deployed and 182 experience with it develops. 184 1.3. Conventions used in this document 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 188 be interpreted as described in [RFC2119]. 190 1.4. Notes from Reviews, and To-Do Items 192 [[anchor3: This section should be resolved and removed prior to 193 publication.]] 195 Stephan Bosch: 4) Invoking the Sieve script linked to the mailbox for 196 every possible event seems inefficient, especially when only one 197 event (e.g. APPEND) is of interest. Whould a means to explicitly 198 select which events are applicable for a (mailbox, script) pair be 199 useful? 201 Barry: We did discuss the general issue of multiple scripts, and I 202 had originally planned to have separate scripts for each event 203 type ("cause"). In the end, we decided that was too complicated, 204 and could be added as a later extension if it turns out to be 205 important. 207 Stephan Bosch: 6) Allowing redirect seems risky. What if I 208 accidently 'drag' in my mailclient the content of some enormous 209 mailing list mailbox to a Sieve-enabled mailbox with a redirect? 210 Shouldn't this at least be bounded somehow? 212 Barry: I don't know if we can specify what to do -- I don't know 213 if we KNOW what to do -- but I've incorporated this into my answer 214 to (7), below. 216 Stephan Bosch: 7) Since this document essentially defines a whole new 217 context in which Sieve scripts can be executed, it can be helpful for 218 the reader to have an introductory section that outlines and 219 summarizes the main differences between the new and the familiar 220 context, e.g. things like the lack of an envelope as pointed out 221 earlier on this list, the undesirability of sending responses back to 222 senders, etc. 224 Barry: I've added a section to the introduction, "Differences 225 Between IMAP Events and Mail Delivery". Please review it, and see 226 if there's stuff to add. 228 To Do: "Interaction with Metadata": Add text requiring ManageSieve, 229 and giving ManageSieve URI in IMAP capability. 231 To Do: "Interaction with Metadata": Add ManageSieve action to set 232 metadata item. 234 2. The IMAP Events in Sieve Extension 236 2.1. The "imapsieve" Capability Strings 238 An IMAP server advertises support for IMAP events in Sieve through 239 the capability string "imapsieve". A server that advertises 240 "imapsieve" is claiming to be in compliance with this specification 241 in all aspects. 243 The corresponding Sieve implementation uses the Sieve capability 244 string "imapsieve", and Sieve scripts that depend upon the IMAP 245 events MUST include that string in their "required" lists. 247 Implementations that support IMAP events in Sieve MUST also support 248 IMAP Metadata [RFC5464] and Sieve Environment [RFC5183], because 249 Metadata is used to associate scripts with IMAP mailboxes and 250 Environment defines an important way for Sieve scripts to test the 251 conditions under which they have been invoked. Notwithstanding the 252 support requirement, scripts that directly use Environment MUST also 253 include its capability string in their "required" lists. 255 2.2. Existing IMAP Functions Affected by IMAP events in Sieve 257 The subsections below describe in detail the IMAP commands and 258 situations on which IMAP events in Sieve have an effect. Not all 259 Sieve actions make sense in the case of messages affected by IMAP 260 commands. See Section 3 for details. 262 It's important to note that since the base Sieve specification (see 263 [RFC5228]) and its extensions define functions for scripts that are 264 invoked during initial mail delivery, those function definitions are 265 necessarily tailored to and limited by that context. This document 266 extends those function definitions for use during IMAP events. By 267 nature of that, Sieve functions, in this extended context, may behave 268 somewhat differently, though their extended behaviour will still be 269 consistent with the functions' goals. 271 If more than one message is affected at the same time, each message 272 triggers the execution of a Sieve script separately. The scripts MAY 273 be run in parallel. 275 2.2.1. The IMAP APPEND Command 277 A message may be added to a mailbox through the IMAP APPEND command. 278 In a server that advertises "imapsieve", new messages added in this 279 way MUST trigger the execution of a Sieve script, subject to the 280 settings defined through Metadata (see Section 2.3.1). 282 2.2.2. The IMAP MULTIAPPEND Command 284 If the IMAP server supports the IMAP MultiAppend extension [RFC3502], 285 messages may be added to a mailbox through the IMAP MULTIAPPEND 286 command. In a server that advertises "imapsieve", new messages added 287 in this way MUST trigger the execution of a Sieve script, as with the 288 APPEND command, also subject to the settings defined through 289 Metadata. 291 2.2.3. The IMAP COPY Command 293 One or more messages may be added to a mailbox through the IMAP COPY 294 command. In a server that advertises "imapsieve", new messages added 295 in this way MUST trigger the execution of a Sieve script, subject to 296 the settings defined through Metadata. 298 2.2.4. Changes to IMAP Message Flags 300 One or more existing messages can have their flags changed in a 301 number of ways, including: 303 o The FETCH command (may cause the \Seen flag to be set). 305 o The STORE command (may cause the \Answered, \Deleted, \Draft, 306 \Flagged, and \Seen flags to be set or reset, and may cause 307 keywords to be set or reset). 309 o The invocation of a Sieve script on an existing message, where the 310 Sieve implementation supports the IMAP4Flags extension [RFC5232] 311 and the script uses one of the actions defined in that extension. 313 In a server that advertises "imapsieve", messages whose flags are 314 changed in any way (except as explained in the next sentence) MUST 315 trigger the execution of a Sieve script, subject to the settings 316 defined through Metadata. The exception is that in order to avoid 317 script loops, flag changes that are made as a result of a script that 318 was itself invoked because of flag changes SHOULD NOT result in 319 another script invocation. In any case, implementations MUST take 320 steps to avoid such loops. 322 For flag-change events, the Sieve script will see the message flags 323 as they are AFTER the changes. 325 2.3. New Functions Defined by IMAP events in Sieve 326 2.3.1. Interaction with Metadata 328 Support for IMAP events in Sieve requires support for IMAP Metadata 329 [RFC5464] as well, since the latter is used to associate scripts with 330 IMAP mailboxes. 332 When an applicable event occurs on an IMAP mailbox, if there is an 333 IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that 334 entry is used. If there is not, but there is an IMAP metadata entry 335 named "/IMAPSieve/Script" for the server, that entry is used 336 (providing a way to define a global script for all mailboxes on a 337 server). If neither entry exists, then no script will be invoked. 339 If an "/IMAPSieve/Script" metadata entry was selected above, the 340 shared value of that metadata name (its "value.shared" attribute) 341 MUST be the name of the Sieve script that will be invoked in response 342 to the IMAP event. Note that only the value.shared attribute is 343 used; any value.priv attributes are ignored. 345 This specifies the mechanism for "activating" a script for a given 346 mailbox (or for all mailboxes), but does not specify a mechanism for 347 creating, storing, or validating the script. Implementations MUST 348 support ManageSieve [RFC5804], and can use the PUTSCRIPT command to 349 store the script without using the SETACTIVE command to activate it. 350 In any case, the script name that is specified in the /IMAPSieve/ 351 Script metadata entry is in a form that depends upon how the server 352 handles the storing of Sieve scripts. Script names used here MUST 353 match script names used by METADATA. 355 Only one Sieve script may currently be defined per mailbox, 356 eliminating the complexity and possible ambiguity involved with 357 coordinating the results of multiple scripts. Any sub-filtering is 358 done in the Sieve script. For example, if it's only necessary to 359 deal with flag changes, but not with new messages appended or copied, 360 the Sieve script will still be invoked for all events, and the script 361 is responsible for checking the event type. 363 The possibility is open for an extension to add support for multiple 364 scripts -- for example, per-client scripts on a multi-client user's 365 inbox, or per-user scripts on a mailbox that is shared among users. 367 Because this metadata name is associated with the mailbox, there can 368 (and it's expected that there will) be different scripts associated 369 with events for different mailboxes. Indeed, most mailboxes will 370 probably invoke no script at all. 372 3. Applicable Sieve Actions and Interactions 374 Since some Sieve actions relate specifically to the delivery of mail, 375 not all actions and extensions make sense when the messages are 376 created by other means or when changes are made to data associated 377 with existing messages. This section describes how actions in the 378 base Sieve specification, and those in extensions known at this 379 writing, relate to this specification. 381 In addition to what is specified here, interactions noted in the 382 individual specifications apply, and must be considered. 384 3.1. The Implicit Keep 386 For all cases that fall under IMAP events in Sieve, the implicit keep 387 means that the message is treated as it would have been if no Sieve 388 script were run. For APPEND, MULTIAPPEND and COPY, the message is 389 stored into the target mailbox normally. For flag changes, the 390 message is left in the mailbox. If actions have been taken that 391 change the message, those changes are considered transient and MUST 392 NOT be retained for any keep action (because IMAP messages are 393 immutable). No error is generated, but the original message, without 394 the changes, is kept. 396 3.2. The Keep Action 398 The keep action is applicable in all cases that fall under IMAP 399 events in Sieve. Its behaviour is as described for implicit keep, in 400 Section 3.1. 402 3.3. The Fileinto Action 404 If the Sieve implementation supports the fileinto action, that action 405 is applicable in all cases that fall under IMAP events in Sieve. If 406 the Copy extension [RFC3894] is available and the :copy option is 407 specified, the implicit keep is retained; otherwise, fileinto cancels 408 the implicit keep, as specified in the base Sieve specification. 410 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 411 fileinto mailbox IN ADDITION TO the original target mailbox. For 412 flag changes, the message is COPIED into the fileinto mailbox, 413 without removing the original. 415 If a keep action is NOT also in effect, the original message is then 416 marked with the \Deleted flag (and a flag-change Sieve script is NOT 417 invoked). The implementation MAY then expunge the original message 418 (WITHOUT expunging other messages in the mailbox), or it MAY choose 419 to have expunges batched, or done by a user. If the server does the 420 expunge, the effect is as though a client had flagged the message and 421 done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. 422 Handling it this way allows clients to handle messages consistently, 423 and avoids hidden changes that might invalidate their message caches. 425 3.4. The Redirect Action 427 The redirect action is applicable in all cases that fall under IMAP 428 events in Sieve. It causes the message to be sent, as specified in 429 the base Sieve specification, to the designated address. If the Copy 430 extension [RFC3894] is available and the :copy option is specified, 431 the implicit keep is retained; otherwise, redirect cancels the 432 implicit keep, as specified in the base Sieve specification. 434 It's possible that a message processed in this way does not have the 435 information necessary to be redirected properly. It might lack 436 necessary header information, and there might not be appropriate 437 information for the MAIL FROM command. In such cases, the "redirect" 438 action uses Message Submission [RFC4409], and it is up to the Sieve 439 engine to supply the missing information. The redirect address is, 440 of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be set 441 to the address of the owner of the mailbox. The message submission 442 server is allowed, according to the Message Submission protocol, to 443 perform necessary fix-up to the message (see section 8 of RFC 4409). 444 It can also reject the submission attempt, if the message is too ill- 445 formed for submission. 447 For APPEND, MULTIAPPEND, and COPY, the message is stored into the 448 target mailbox in addition to being redirected. For flag changes, 449 the message remains in its original mailbox. 451 If a keep action is NOT also in effect, the original message is then 452 marked with the \Deleted flag (and a flag-change Sieve script is NOT 453 invoked). The implementation MAY then expunge the original message 454 (WITHOUT expunging other messages in the mailbox), or it MAY choose 455 to have expunges batched, or done by a user. If the server does the 456 expunge, the effect is as though a client had flagged the message and 457 done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. 458 Handling it this way allows clients to handle messages consistently, 459 and avoids hidden changes that might invalidate their message caches. 461 3.5. The Discard Action 463 The discard action is applicable in all cases that fall under IMAP 464 events in Sieve. For APPEND, MULTIAPPEND, and COPY, the message is 465 first stored into the target mailbox. If an explicit keep action is 466 also in effect, the discard action now does nothing. Otherwise, the 467 original message is then marked with the \Deleted flag (and a flag- 468 change Sieve script is NOT invoked). The implementation MAY then 469 expunge the original message (WITHOUT expunging other messages in the 470 mailbox), or it MAY choose to have expunges batched, or done by a 471 user. If the server does the expunge, the effect is as though a 472 client had flagged the message and done a UID EXPUNGE (see [RFC4315]) 473 on the affected message(s) only. Handling it this way allows clients 474 to handle messages consistently, and avoids hidden changes that might 475 invalidate their message caches. 477 3.6. The Notify Action 479 If the Nofity extension [RFC5435] is available, the notify action is 480 applicable in all cases that fall under IMAP events in Sieve. The 481 result is that the requested notification is sent, and that the 482 message is otherwise handled as it would normally have been. 484 3.7. The Addheader and Deleteheader Actions 486 If the EditHeader extension [RFC5293] is available, it can be used to 487 make transient changes to header fields, which aren't saved in place, 488 such as for "redirect" or "fileinto" actions. Because messages in 489 IMAP mailboxes are immutable, such changes are NOT applicable for the 490 "keep" acton (explicit or implicit). See Section 3.1. 492 3.8. The Setflag, Deleteflag, and Removeflag Actions 494 Implementations of IMAP events in Sieve MUST also support the 495 IMAP4Flags extension [RFC5232], and the actions associated with it 496 are all applicable to any case that falls under IMAP events in Sieve. 498 It is worth noting also that the "hasflag" test that is defined in 499 the IMAP4Flags extension might be particularly useful in scripts 500 triggered by flag changes ("hasflag" will see the new, changed 501 flags). The flag changes behave as though a client had made the 502 change. 504 As explained above, in order to avoid script loops flag changes that 505 are made as a result of a script that was itself invoked because of 506 flag changes SHOULD NOT result in another script invocation. In any 507 case, implementations MUST take steps to avoid such loops. 509 3.9. MIME Part Tests and Replacement 511 If the MIME Part Tests extension [RFC5703] is available, all of its 512 functions can be used, but any changes made to the message, using the 513 "replace" or "enclose" action, MUST be considered transient, and are 514 only applicable with actions such as "redirect" and "fileinto". 515 Because messages in IMAP mailboxes are immutable, such changes are 516 NOT applicable for the "keep" acton (explicit or implicit). See 517 Section 3.1. 519 3.10. Spamtest and Virustest 521 If the Spamtest and Virustest extensions [RFC5235] are available, 522 they are applicable in all cases that fall under IMAP events in 523 Sieve. 525 3.11. Inapplicable Actions 527 The following actions and extensions are NOT applicable to any case 528 that falls under IMAP events in Sieve, because they are specifically 529 designed to respond to delivery of a new email message. Their 530 appearance in the "require" control or their use in an IMAP event 531 MUST result in an error condition that will terminate the Sieve 532 script: 534 reject [RFC5228] 536 ereject [RFC5429] 538 vacation [RFC5230] 540 Future extensions that are specifically designed to respond to 541 delivery of a new email message will likewise not be applicable to 542 this extension. 544 4. Interaction With Sieve Environment 546 4.1. Base Sieve Environment Items: location and phase 548 The Sieve Environment extension defines a set of standard environment 549 items (see [RFC5183], Section 4.1). Two of those items are affected 550 when the script is invoked through an IMAP event. 552 The value of "location" is set to "MS" -- evaluation is being 553 performed by a Message Store. 555 The value of "phase" is set to "post" -- processing is taking place 556 after (or perhaps instead of, in the case of APPEND) final delivery. 558 4.2. New Sieve Environment Items: imapuser and imapemail 560 In the normal case, when Sieve is used in final delivery, there is no 561 identity for the "filer" -- the user who is creating or changing the 562 message. In this case, there is such an identity, and a Sieve script 563 might want to access that identity. 565 Implementations MUST set and make available two new environment 566 items: 568 "imapuser" -- the identity (login ID) of the IMAP user that caused 569 the action. This MUST be the empty string if it is accessed during 570 normal (final delivery) Sieve processing. 572 "imapemail" -- the primary email address of the IMAP user that caused 573 the action (the user identified by "imapuser"). In some 574 implementations, "imapuser" and "imapemail" might have the same 575 value. This MUST be the empty string if it is accessed during normal 576 (final delivery) Sieve processing. 578 4.3. New Sieve Environment Item: cause 580 Each mailbox uses a single script for all the change conditions 581 described in this document (append, copy, flag changes). To support 582 that, the implementation MUST set the Environment [RFC5183] item 583 "cause", which contains the name of the action that caused the script 584 to be invoked. Its value is one of the following: 586 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 588 o COPY (for invocations resulting from COPY) 590 o FLAG (for invocations resulting from flag changes) 591 Future extensions might define new events and, thus, new causes. 592 Such extensions will come with their own capability strings, and the 593 events they define will only be presented when their capabilities are 594 requested. Scripts that do not request those capabilities will not 595 see those events, and will not encounter the new cause strings. 597 4.4. New Sieve Environment Item: mailbox 599 The implementation MUST set the Environment [RFC5183] item "mailbox" 600 to the name of the mailbox that the affected message is in, in the 601 case of existing messages, or is targeted to be stored into, in the 602 case of new messages. The value of this item is fixed when the 603 script begins, and, in particular, MUST NOT change as a result of any 604 action, such as "fileinto". 606 4.5. New Sieve Environment Item: changedflags 608 If the IMAP4Flags extension [RFC5232] is available, AND the script 609 was invoked because of flag changes to an existing message, the 610 implementation MUST set the Environment [RFC5183] item "changedflags" 611 to the name(s) of the flag(s) that have changed. If the script was 612 not invoked because of flag changes, the value of this item MUST be 613 the empty string. The script will not know from this item whether 614 the flags have been set or reset, but it can use the "hasflag" test 615 to determine the current value. See example 2 in Section 5 for an 616 example of how this might be used. 618 4.6. Interaction With Sieve Tests (Comparisons) 620 Any tests against message envelope information, including the 621 "envelope" test in the Sieve base specification, as well as any such 622 test defined in extensions, are either inapplicable or have serious 623 interoperability issues when performed at other than final-delivery 624 time. Therefore, envelope tests MUST NOT be permitted in the cases 625 described here, and their use MUST generate a runtime error. 627 This extension does not affect the operation of other tests or 628 comparisons in the Sieve base specification. 630 5. Examples 632 Example 1: 633 If a new message is added to the "ActionItems" mailbox, a copy is 634 sent to the address "actionitems@example.com". 636 require ["copy", "environment", "imapsieve"]; 638 if anyof (environment :is "cause" "APPEND", 639 environment :is "cause" "COPY") { 640 if environment :is "mailbox" "ActionItems" { 641 redirect :copy "actionitems@example.com"; 642 } 643 } 645 Example 2: 646 If the script is called for any message with the \Flagged flag set 647 (tested through the IMAP4Flags extension [RFC5232]), a notification 648 is sent using the Notify extension [RFC5435]. No notification will 649 be sent, though, if we're called with an existing message that 650 already had that flag set. 652 require ["enotify", "imap4flags", "variables", 653 "environment", "imapsieve"]; 655 if environment :matches "mailbox" "*" { 656 set "mailbox" "${1}"; 657 } 659 if allof (hasflag "\\Flagged", 660 not environment :contains "changedflags" "\\Flagged") { 661 notify :message "Important message in ${mailbox}" 662 "xmpp:tim@example.com?message;subject=SIEVE"; 663 } 665 6. Security Considerations 667 It is possible to introduce script processing loops by having a Sieve 668 script that is triggered by flag changes use the actions defined in 669 the IMAP4Flags extension [RFC5232]. Implementations MUST take steps 670 to prevent such loops. One way to avoid this problem is that if a 671 script is invoked by flag changes, and that script further changes 672 the flags, those flag changes SHOULD NOT trigger a Sieve script 673 invocation. 675 It is also possible to introduce loops through the "redirect" or 676 "notify" actions. See section 10 of Sieve [RFC5228], section 8 of 677 Sieve Notify [RFC5435], and the Security Considerations sections of 678 the applicable notification-method documents for loop-prevention 679 information. This extension does not change any of that advice. 681 Other security considerations are discussed in IMAP [RFC3501], and 682 Sieve [RFC5228], as well as in some of the other extension documents. 684 7. IANA Considerations 686 7.1. Registration of "imapsieve" IMAP capability 688 This document defines a new IMAP capability. IANA is asked to add 689 "imapsieve" to the IMAP 4 Capabilities registry. 691 7.2. Registration of imapsieve Sieve extension 693 The following template specifies the IANA registration of the Sieve 694 extension specified in this document: 696 To: iana@iana.org 697 Subject: Registration of new Sieve extension 698 Capability name: imapsieve 699 Description: Add Sieve processing for IMAP events. 700 RFC number: this RFC 701 Contact address: Sieve mailing list 703 This information should be added to the list of sieve extensions 704 given on http://www.iana.org/assignments/sieve-extensions. 706 7.3. Registration of environment item: cause 708 The following template specifies the IANA registration of a sieve 709 environment item specified in this document: 711 To: iana@iana.org 712 Subject: Registration of new Sieve environment item 713 Item name: cause 714 Description: The name of the action that caused the script to be 715 invoked. Its value is one of the following: 717 o APPEND (for invocations resulting from APPEND or MULTIAPPEND) 719 o COPY (for invocations resulting from COPY) 721 o FLAG (for invocations resulting from flag changes) 723 RFC number: this RFC 724 Contact address: 725 Sieve mailing list 727 This information should be added to the list of sieve environment 728 item names given in the Environment extension [RFC5183]. 730 7.4. Registration of environment item: mailbox 732 The following template specifies the IANA registration of a sieve 733 environment item specified in this document: 735 To: iana@iana.org 736 Subject: Registration of new Sieve environment item 737 Item name: mailbox 738 Description: The name of the mailbox that the affected message is in, 739 in the case of existing messages, or is targeted to be stored into, 740 in the case of new messages. The value of this item is fixed when 741 the script begins, and, in particular, MUST NOT change as a result of 742 any action, such as "fileinto". 743 RFC number: this RFC 744 Contact address: 745 Sieve mailing list 747 This information should be added to the list of sieve environment 748 item names given in the Environment extension [RFC5183]. 750 7.5. Registration of environment item: changedflags 752 The following template specifies the IANA registration of a sieve 753 environment item specified in this document: 755 To: iana@iana.org 756 Subject: Registration of new Sieve environment item 757 Item name: changedflags 758 Description: If the script was invoked because of flag changes to an 759 existing message, this contains the name(s) of the flag(s) that have 760 changed. Otherwise, the value of this item MUST be the empty string. 761 RFC number: this RFC 762 Contact address: 763 Sieve mailing list 765 This information should be added to the list of sieve environment 766 item names given in the Environment extension [RFC5183]. 768 7.6. Registration of environment item: imapuser 770 The following template specifies the IANA registration of a sieve 771 environment item specified in this document: 773 To: iana@iana.org 774 Subject: Registration of new Sieve environment item 775 Item name: imapuser 776 Description: The identity (IMAP login ID) of the IMAP user that 777 caused the action. 779 RFC number: this RFC 780 Contact address: 781 Sieve mailing list 783 This information should be added to the list of sieve environment 784 item names given in the Environment extension [RFC5183]. 786 7.7. Registration of environment item: imapemail 788 The following template specifies the IANA registration of a sieve 789 environment item specified in this document: 791 To: iana@iana.org 792 Subject: Registration of new Sieve environment item 793 Item name: imapemail 794 Description: The primary email address of the IMAP user that caused 795 the action (the user identified by "imapuser"). 796 RFC number: this RFC 797 Contact address: 798 Sieve mailing list 800 This information should be added to the list of sieve environment 801 item names given in the Environment extension [RFC5183]. 803 7.8. Registration of IMAP METADATA mailbox entry name 805 The following template specifies the IANA registration of an IMAP 806 METADATA entry name specified in this document: 808 To: iana@iana.org 809 Subject: IMAP METADATA Registration 810 Please register the following IMAP METADATA item: 811 [x] Entry [ ] Attribute 812 [x] Mailbox [ ] Server 813 Name: /IMAPSieve/Script 814 Description: This entry name is used to define mailbox metadata 815 associated with IMAP events in Sieve for the associated mailbox. 816 Specifically, this specifies the Sieve script that will be invoked 817 when IMAP events occur on the specified mailbox. 818 Content-type: text/plain; charset=utf-8 819 RFC number: this RFC 820 Contact person: Sieve mailing list 821 Contact email: sieve@ietf.org 823 This information should be added to the list of IMAP METADATA item 824 names given in the Metadata extension [RFC5464]. 826 7.9. Registration of IMAP METADATA server entry name 828 The following template specifies the IANA registration of an IMAP 829 METADATA entry name specified in this document: 831 To: iana@iana.org 832 Subject: IMAP METADATA Registration 833 Please register the following IMAP METADATA item: 834 [x] Entry [ ] Attribute 835 [ ] Mailbox [x] Server 836 Name: /IMAPSieve/Script 837 Description: This entry name is used to define metadata associated 838 globally with IMAP events in Sieve for the associated server. 839 Specifically, this specifies the Sieve script that will be invoked 840 when IMAP events occur on any mailbox in the server that does not 841 have its own mailbox-level /IMAPSieve/Script entry. 842 Content-type: text/plain; charset=utf-8 843 RFC number: this RFC 844 Contact person: Sieve mailing list 845 Contact email: sieve@ietf.org 847 This information should be added to the list of IMAP METADATA item 848 names given in the Metadata extension [RFC5464]. 850 8. References 852 8.1. Normative References 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, March 1997. 857 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 858 4rev1", RFC 3501, March 2003. 860 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 861 MULTIAPPEND Extension", RFC 3502, March 2003. 863 [RFC3894] Degener, J., "Sieve Extension: Copying Without Side 864 Effects", RFC 3894, October 2004. 866 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 867 RFC 4409, April 2006. 869 [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", 870 RFC 5183, May 2008. 872 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 873 Language", RFC 5228, January 2008. 875 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 876 Extension", RFC 5232, January 2008. 878 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 879 February 2009. 881 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 882 Managing Sieve Scripts", RFC 5804, July 2010. 884 8.2. Non-Normative References 886 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 887 UIDPLUS extension", RFC 4315, December 2005. 889 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 890 Vacation Extension", RFC 5230, January 2008. 892 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 893 Extensions", RFC 5235, January 2008. 895 [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: 896 Editheader Extension", RFC 5293, August 2008. 898 [RFC5429] Stone, A., "Sieve Email Filtering: Reject and Extended 899 Reject Extensions", RFC 5429, March 2009. 901 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 902 "Sieve Email Filtering: Extension for Notifications", 903 RFC 5435, January 2009. 905 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 906 Tests, Iteration, Extraction, Replacement, and Enclosure", 907 RFC 5703, October 2009. 909 Author's Address 911 Barry Leiba 912 Huawei Technologies 914 Phone: +1 646 827 0648 915 Email: barryleiba@computer.org 916 URI: http://internetmessagingtechnology.org/