Sieve Working Group B. Leiba Internet-Draft Huawei Technologies Intended status: Standards Track July 8, 2011 Expires: January 9, 2012 Support for Sieve in Internet Message Access Protocol (IMAP4) draft-ietf-sieve-imap-sieve-02 Abstract Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Leiba Expires January 9, 2012 [Page 1] Internet-Draft IMAP-Sieve July 2011 Note This document defines extensions to IMAP and Sieve. It is the work of the Sieve Working Group, but had previously been in the lemonade mailing list, as draft-ietf-lemonade-imap-sieve. 1. Discussion of this document should be taken to the Sieve mailing list at mailto:sieve@ietf.org 2. Subscription requests can be sent to mailto:sieve@ietf.org?body=subscribe (send an email message with the word "subscribe" in the body). 3. A WWW archive of back messages is available at http://www.ietf.org/mail-archive/web/sieve/index.html 4. Older messages, which were posted to the lemonade mailing list, are archived at http://www.ietf.org/mail-archive/web/lemonade/index.html Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Leiba Expires January 9, 2012 [Page 2] Internet-Draft IMAP-Sieve July 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Conventions used in this document . . . . . . . . . . . . 5 2. The IMAPSieve Extension . . . . . . . . . . . . . . . . . 6 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 6 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 6 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 8 2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8 3. Applicable Sieve Actions and Interactions . . . . . . . . 10 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11 3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11 3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 12 3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12 3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12 3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 13 3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 13 4. New Sieve Environment Items . . . . . . . . . . . . . . . 14 4.1. New Sieve Environment Items: imapuser and imapemail . . . 14 4.2. New Sieve Environment Item: cause . . . . . . . . . . . . 14 4.3. New Sieve Environment Item: mailbox . . . . . . . . . . . 14 4.4. New Sieve Environment Item: changedflags . . . . . . . . . 15 4.5. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. Registration of IMAPSIEVE IMAP capability . . . . . . . . 18 Leiba Expires January 9, 2012 [Page 3] Internet-Draft IMAP-Sieve July 2011 7.2. Registration of imapsieve Sieve extension . . . . . . . . 18 7.3. Registration of environment item: cause . . . . . . . . . 18 7.4. Registration of environment item: mailbox . . . . . . . . 19 7.5. Registration of environment item: changedflags . . . . . . 19 7.6. Registration of environment item: imapuser . . . . . . . . 19 7.7. Registration of environment item: imapemail . . . . . . . 20 7.8. Registration of IMAP METADATA mailbox entry name . . . . . 20 7.9. Registration of IMAP METADATA server entry name . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . 24 Leiba Expires January 9, 2012 [Page 4] Internet-Draft IMAP-Sieve July 2011 1. Introduction 1.1. Overview Some applications have a need to apply Sieve filters [RFC5228] in situations other than initial mail delivery. This is especially true in diverse service environments, such as when the client is sporadically connected, is connected through a high-latency or high- cost channel, or is on a limited-function device. For such clients, it may be very important, for higher performance and reliability, to take advantage of server capabilities, including those provided by Sieve filtering (and Sieve extensions, such as Notify [RFC5435]). This specification defines extensions to IMAP [RFC3501] to support the invocation of Sieve scripts at times when the IMAP server creates new messages or modifies existing ones. It also defines how Sieve scripts will process these invocations. Support for IMAPSieve requires support for IMAP Metadata [RFC5464] and Sieve Environment [RFC5183] as well, because Metadata is used to associate scripts with IMAP mailboxes and Environment defines an important way for Sieve scripts to test the conditions under which they have been invoked. 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Leiba Expires January 9, 2012 [Page 5] Internet-Draft IMAP-Sieve July 2011 2. The IMAPSieve Extension 2.1. The "IMAPSieve" Capability String [[anchor1: Should we use "imapsieve" for both of these, as here? Or should we use something like "SieveEvents" for the IMAP capability and "IMAPEvents" for the Sieve capability? I rather think it's less confusing to use the same string for both.]] An IMAP server advertises support for this extension through the capability string "IMAPSieve" (the string is not case-sensitive, and is shown here with this capitalization for readability). A server that advertises IMAPSieve is claiming to be in compliance with this specification in all aspects. The corresponding Sieve implementation uses the Sieve capability string "IMAPSieve (also case-insensitive), and scripts that depend upon the IMAP events MUST include that string in their "required" lists. Implementations that support IMAPSieve MUST also support IMAP Metadata [RFC5464] and Sieve Environment [RFC5183], because Metadata is used to associate scripts with IMAP mailboxes and Environment defines an important way for Sieve scripts to test the conditions under which they have been invoked. Notwithstanding the support requirement, scripts that directly use Environment MUST also include its capability string in their "required" lists. 2.2. Existing IMAP Functions Affected by IMAPSieve The subsections below describe in detail the IMAP commands and situations on which IMAPSieve has an effect. Not all Sieve actions make sense in the case of messages affected by IMAP commands. See Section 3 for details. It's important to note that since the base Sieve specification (see [RFC5228]) and its extensions define functions for scripts that are invoked during initial mail delivery, those function definitions are necessarily tailored to and limited by that context. This document extends those function definitions for use during IMAP events. By nature of that, Sieve functions, in this extended context, may behave somewhat differently, though their extended behaviour will still be consistent with the functions' goals. If more than one message is affected at the same time, each message triggers the execution of a Sieve script separately. The scripts MAY be run in parallel. Leiba Expires January 9, 2012 [Page 6] Internet-Draft IMAP-Sieve July 2011 2.2.1. The IMAP APPEND Command A message may be added to a mailbox through the IMAP APPEND command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, subject to the settings defined through Metadata (see Section 2.3.1). 2.2.2. The IMAP MULTIAPPEND Command If the IMAP server supports the IMAP MultiAppend extension [RFC3502], messages may be added to a mailbox through the IMAP MULTIAPPEND command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, as with the APPEND command, also subject to the settings defined through Metadata. 2.2.3. The IMAP COPY Command One or more messages may be added to a mailbox through the IMAP COPY command. In a server that advertises IMAPSieve, new messages added in this way MUST trigger the execution of a Sieve script, subject to the settings defined through Metadata. 2.2.4. Changes to IMAP Message Flags One or more existing messages can have their flags changed in a number of ways, including: o The FETCH command (may cause the \Seen flag to be set). o The STORE command (may cause the \Answered, \Deleted, \Draft, \Flagged, and \Seen flags to be set or reset, and may cause keywords to be set or reset). o The invocation of a Sieve script on an existing message, where the Sieve implementation supports the IMAP4Flags extension [RFC5232] and the script uses one of the actions defined in that extension. In a server that advertises IMAPSieve, messages whose flags are changed in any way (except as explained in the next sentence) MUST trigger the execution of a Sieve script, subject to the settings defined through Metadata. The exception is that in order to avoid script loops, flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. For flag-change events, the Sieve script will see the message flags Leiba Expires January 9, 2012 [Page 7] Internet-Draft IMAP-Sieve July 2011 as they are AFTER the changes. 2.3. New Functions Defined by IMAPSieve 2.3.1. Interaction with Metadata Support for IMAPSieve requires support for IMAP Metadata [RFC5464] as well, since the latter is used to associate scripts with IMAP mailboxes. When an applicable event occurs on an IMAP mailbox, if there is an IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that entry is used. If there is not, but there is an IMAP metadata entry named "/IMAPSieve/Script" for the server, that entry is used (providing a way to define a global script for all mailboxes on a server). If neither entry exists, then no script will be invoked. If an "/IMAPSieve/Script" metadata entry was selected above, the shared value of that metadata name (its "value.shared" attribute) MUST be the name of the Sieve script that will be invoked in response to the IMAP event OR the name of another metadata entry, the name prefixed with "metadata:" (such as "metadata:/IMAPSieve/ ScriptContents"), that contains the actual script in its value.shared attribute. Note that only the value.shared attribute is used; any value.priv attributes are ignored. [[COMMENT FROM NED: But the real question is why should we limit ourselves this way? Why not make the contents of "/IMAPSieve/Script" a URL? (The metadata: prefix can then be defined as a URL.) If we want to reach into ManageSieve, use a sieve: URL. (I do see a big problem with this currently - RFC 5804 appears to have badly botched the specification of sieve: URLs - the authority field is mandatory when it shouldn't be, and the owner field is encoded into the URL path when it should have been extracted from the authority field if it is present. The way it's done now, you cannot write sieve:///scriptname and have it mean what it should mean: Select out of the mailbox owner's scripts. -------- Now, there is no doubt that allowing URLs creates additional concerns, mostly security related. But we've dealt with this sort of thing before, e.g., in BURL. All we have to say is that metadata:foo MUST be implemented and sieve:bar (modulo some fixes to RFC 5804) SHOULD work if ManageSieve is available. -------- If this goes too far, then at a minimum I believe this section needs to be more explicit about how, if ManageSieve is used, the mapping from script collections in ManageSieve to a mailbox works.]] This specifies the mechanism for "activating" a script for a given mailbox (or for all mailboxes), but does not specify a mechanism for Leiba Expires January 9, 2012 [Page 8] Internet-Draft IMAP-Sieve July 2011 creating, storing, or validating the script. Implementations MAY use ManageSieve [RFC5804] to acomplish this, using the PUTSCRIPT command to store the script without using the SETACTIVE command to activate it. In any case, the script name that is specified in the /IMAPSieve/Script metadata entry is in a form that depends upon how the server handles the storing of Sieve scripts. Only one Sieve script may currently be defined per mailbox, eliminating the complexity and possible ambiguity involved with coordinating the results of multiple scripts. Any sub-filtering is done in the Sieve script. For example, if it's only necessary to deal with flag changes, but not with new messages appended or copied, the Sieve script will still be invoked for all events, and the script is responsible for checking the event type. The possibility is open for an extension to add support for multiple scripts -- for example, per-client scripts on a multi-client user's inbox, or per-user scripts on a mailbox that is shared among users. Because this metadata name is associated with the mailbox, there can (and it's expected that there will) be different scripts associated with events for different mailboxes. Indeed, most mailboxes will probably invoke no script at all. Leiba Expires January 9, 2012 [Page 9] Internet-Draft IMAP-Sieve July 2011 3. Applicable Sieve Actions and Interactions Since some Sieve actions relate specifically to the delivery of mail, not all actions and extensions make sense when the messages are created by other means or when changes are made to data associated with existing messages. This section describes how actions in the base Sieve specification, and those in extensions known at this writing, relate to this specification. In addition to what is specified here, interactions noted in the individual specifications apply, and must be considered. 3.1. The Implicit Keep For all cases that fall under IMAPSieve, the implicit keep means that the message is treated as it would have been if no Sieve script were run. For APPEND, MULTIAPPEND and COPY, the message is stored into the target mailbox normally. For flag changes, the message is left in the mailbox. If actions have been taken that change the message, those changes are considered transient and MUST NOT be retained for any keep action (because IMAP messages are immutable). No error is generated, but the original message, without the changes, is kept. 3.2. The Keep Action The keep action is applicable in all cases that fall under IMAPSieve. Its behaviour is as described for implicit keep, in Section 3.1. 3.3. The Fileinto Action If the Sieve implementation supports the fileinto action, that action is applicable in all cases that fall under IMAPSieve. If the Copy extension [RFC3894] is available and the :copy option is specified, the implicit keep is retained; otherwise, fileinto cancels the implicit keep, as specified in the base Sieve specification. For APPEND, MULTIAPPEND, and COPY, the message is stored into the fileinto mailbox IN ADDITION TO the original target mailbox. For flag changes, the message is COPIED into the fileinto mailbox, without removing the original. If a keep action is NOT also in effect, the original message is then marked with the \Deleted flag (and a flag-change Sieve script is NOT invoked). The implementation MAY then expunge the original message (WITHOUT expunging other messages in the mailbox), or it MAY choose to have expunges batched, or done by a user. If the server does the expunge, the effect is as though a client had flagged the message and done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. Leiba Expires January 9, 2012 [Page 10] Internet-Draft IMAP-Sieve July 2011 Handling it this way allows clients to handle messages consistently, and avoids hidden changes that might invalidate their message caches. 3.4. The Redirect Action The redirect action is applicable in all cases that fall under IMAPSieve. It causes the message to be sent, as specified in the base Sieve specification, to the designated address. If the Copy extension [RFC3894] is available and the :copy option is specified, the implicit keep is retained; otherwise, redirect cancels the implicit keep, as specified in the base Sieve specification. It's possible that a message processed in this way does not have the information necessary to be redirected properly. It might lack necessary header information, and there might not be appropriate information for the MAIL FROM command. In such cases, the "redirect" action uses Message Submission [RFC4409], and it is up to the Sieve engine to supply the missing information. The redirect address is, of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be set to the address of the owner of the mailbox. The message submission server is allowed, according to the Message Submission protocol, to perform necessary fix-up to the message (see section 8 of RFC 4409). It can also reject the submission attempt, if the message is too ill- formed for submission. For APPEND, MULTIAPPEND, and COPY, the message is stored into the target mailbox in addition to being redirected. For flag changes, the message remains in its original mailbox. If a keep action is NOT also in effect, the original message is then marked with the \Deleted flag (and a flag-change Sieve script is NOT invoked). The implementation MAY then expunge the original message (WITHOUT expunging other messages in the mailbox), or it MAY choose to have expunges batched, or done by a user. If the server does the expunge, the effect is as though a client had flagged the message and done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. Handling it this way allows clients to handle messages consistently, and avoids hidden changes that might invalidate their message caches. 3.5. The Discard Action The discard action is applicable in all cases that fall under IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first stored into the target mailbox. If an explicit keep action is also in effect, the discard action now does nothing. Otherwise, the original message is then marked with the \Deleted flag (and a flag- change Sieve script is NOT invoked). The implementation MAY then expunge the original message (WITHOUT expunging other messages in the Leiba Expires January 9, 2012 [Page 11] Internet-Draft IMAP-Sieve July 2011 mailbox), or it MAY choose to have expunges batched, or done by a user. If the server does the expunge, the effect is as though a client had flagged the message and done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. Handling it this way allows clients to handle messages consistently, and avoids hidden changes that might invalidate their message caches. 3.6. The Notify Action If the Nofity extension [RFC5435] is available, the notify action is applicable in all cases that fall under IMAPSieve. The result is that the requested notification is sent, and that the message is otherwise handled as it would normally have been. 3.7. The Addheader and Deleteheader Actions If the EditHeader extension [RFC5293] is available, it can be used to make transient changes to header fields, which aren't saved in place, such as for "redirect" or "fileinto" actions. Because messages in IMAP mailboxes are immutable, such changes are NOT applicable for the "keep" acton (explicit or implicit). See Section 3.1. 3.8. The Setflag, Deleteflag, and Removeflag Actions Implementations of the IMAPSieve extension MUST also support the IMAP4Flags extension [RFC5232], and the actions associated with it are all applicable to any case that falls under IMAPSieve. It is worth noting also that the "hasflag" test that is defined in the IMAP4Flags extension might be particularly useful in scripts triggered by flag changes ("hasflag" will see the new, changed flags). The flag changes behave as though a client had made the change. As explained above, in order to avoid script loops flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. 3.9. MIME Part Tests and Replacement If the MIME Part Tests extension [RFC5703] is available, all of its functions can be used, but any changes made to the message, using the "replace" or "enclose" action, MUST be considered transient, and are only applicable with actions such as "redirect" and "fileinto". Because messages in IMAP mailboxes are immutable, such changes are NOT applicable for the "keep" acton (explicit or implicit). See Section 3.1. Leiba Expires January 9, 2012 [Page 12] Internet-Draft IMAP-Sieve July 2011 3.10. Spamtest and Virustest If the Spamtest and Virustest extensions [RFC5235] are available, they are applicable in all cases that fall under IMAPSieve. 3.11. Inapplicable Actions The following actions and extensions are NOT applicable to any case that falls under IMAPSieve. Their use or their appearance in the "require" control MUST result in an error condition that will terminate the Sieve script: reject [RFC5228] ereject [RFC5429] vacation [RFC5230] Leiba Expires January 9, 2012 [Page 13] Internet-Draft IMAP-Sieve July 2011 4. New Sieve Environment Items 4.1. New Sieve Environment Items: imapuser and imapemail In the normal case, when Sieve is used in final delivery, there is no identity for the "filer" -- the user who is creating or changing the message. In this case, there is such an identity, and a Sieve script might want to access that identity. Implementations MUST set and make available two new environment items: "imapuser" -- the identity (login ID) of the IMAP user that caused the action. This MUST be the empty string if it is accessed during normal (final delivery) Sieve processing. "imapemail" -- the primary email address of the IMAP user that caused the action (the user identified by "imapuser"). In some implementations, "imapuser" and "imapemail" might have the same value. This MUST be the empty string if it is accessed during normal (final delivery) Sieve processing. 4.2. New Sieve Environment Item: cause Implementations MAY invoke different Sieve scripts for the different conditions described in this document (append, copy, flag changes). If the actions to be taken are common, and the implementation supports the Include extension [I-D.ietf-sieve-include], the common script code can be included as specified there. Each mailbox uses a single script for all the change conditions described in this document (append, copy, flag changes). To support that, the implementation MUST set the Environment [RFC5183] item "cause", which contains the name of the action that caused the script to be invoked. Its value is one of the following: o APPEND (for invocations resulting from APPEND or MULTIAPPEND) o COPY (for invocations resulting from COPY) o FLAG (for invocations resulting from flag changes) 4.3. New Sieve Environment Item: mailbox The implementation MUST set the Environment [RFC5183] item "mailbox" to the name of the mailbox that the affected message is in, in the case of existing messages, or is targeted to be stored into, in the case of new messages. The value of this item is fixed when the Leiba Expires January 9, 2012 [Page 14] Internet-Draft IMAP-Sieve July 2011 script begins, and, in particular, MUST NOT change as a result of any action, such as "fileinto". 4.4. New Sieve Environment Item: changedflags If the IMAP4Flags extension [RFC5232] is available, AND the script was invoked because of flag changes to an existing message, the implementation MUST set the Environment [RFC5183] item "changedflags" to the name(s) of the flag(s) that have changed. If the script was not invoked because of flag changes, the value of this item MUST be the empty string. The script will not know from this item whether the flags have been set or reset, but it can use the "hasflag" test to determine the current value. See example 2 in Section 5 for an example of how this might be used. 4.5. Interaction With Sieve Tests (Comparisons) This extension does not affect the operation of tests or comparisons in the Sieve base specification. Leiba Expires January 9, 2012 [Page 15] Internet-Draft IMAP-Sieve July 2011 5. Examples Example 1: If a new message is added to the "ActionItems" mailbox, a copy is sent to the address "actionitems@example.com". require ["copy", "environment"]; if anyof (environment :is "cause" "APPEND", environment :is "cause" "COPY") { if environment :is "mailbox" "ActionItems" { redirect :copy "actionitems@example.com"; } } Example 2: If the script is called for any message with the \Flagged flag set (tested through the IMAP4Flags extension [RFC5232]), a notification is sent using the Notify extension [RFC5435]. No notification will be sent, though, if we're called with an existing message that already had that flag set. require ["enotify", "imap4flags", "variables", "environment"]; if environment :matches "mailbox" "*" { set "mailbox" "${1}"; } if allof (hasflag "\\Flagged", not environment :contains "changedflags" "\\Flagged") { notify :message "Important message in ${mailbox}" "xmpp:tim@example.com?message;subject=SIEVE"; } Leiba Expires January 9, 2012 [Page 16] Internet-Draft IMAP-Sieve July 2011 6. Security Considerations It is possible to introduce script processing loops by having a Sieve script that is triggered by flag changes use the actions defined in the IMAP4Flags extension [RFC5232]. Implementations MUST take steps to prevent such loops. One way to avoid this problem is that if a script is invoked by flag changes, and that script further changes the flags, those flag changes SHOULD NOT trigger a Sieve script invocation. It is also possible to introduce loops through the "redirect" or "notify" actions. See section 10 of Sieve [RFC5228], section 8 of Sieve Notify [RFC5435], and the Security Considerations sections of the applicable notification-method documents for loop-prevention information. This extension does not change any of that advice. Other security considerations are discussed in IMAP [RFC3501], and Sieve [RFC5228], as well as in some of the other extension documents. Leiba Expires January 9, 2012 [Page 17] Internet-Draft IMAP-Sieve July 2011 7. IANA Considerations 7.1. Registration of IMAPSIEVE IMAP capability This document defines a new IMAP capability. IANA is asked to add "IMAPSIEVE" to the IMAP 4 Capabilities registry. 7.2. Registration of imapsieve Sieve extension The following template specifies the IANA registration of the Sieve extension specified in this document: To: iana@iana.org Subject: Registration of new Sieve extension Capability name: imapsieve Description: Add Sieve processing for IMAP events. RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions. 7.3. Registration of environment item: cause The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: cause Description: The name of the action that caused the script to be invoked. Its value is one of the following: o APPEND (for invocations resulting from APPEND or MULTIAPPEND) o COPY (for invocations resulting from COPY) o FLAG (for invocations resulting from flag changes) RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the Environment extension [RFC5183]. Leiba Expires January 9, 2012 [Page 18] Internet-Draft IMAP-Sieve July 2011 7.4. Registration of environment item: mailbox The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: mailbox Description: The name of the mailbox that the affected message is in, in the case of existing messages, or is targeted to be stored into, in the case of new messages. The value of this item is fixed when the script begins, and, in particular, MUST NOT change as a result of any action, such as "fileinto". RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the Environment extension [RFC5183]. 7.5. Registration of environment item: changedflags The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: changedflags Description: If the script was invoked because of flag changes to an existing message, this contains the name(s) of the flag(s) that have changed. Otherwise, the value of this item MUST be the empty string. RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the Environment extension [RFC5183]. 7.6. Registration of environment item: imapuser The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: imapuser Description: The identity (IMAP login ID) of the IMAP user that caused the action. Leiba Expires January 9, 2012 [Page 19] Internet-Draft IMAP-Sieve July 2011 RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the Environment extension [RFC5183]. 7.7. Registration of environment item: imapemail The following template specifies the IANA registration of a sieve environment item specified in this document: To: iana@iana.org Subject: Registration of new Sieve environment item Item name: imapemail Description: The primary email address of the IMAP user that caused the action (the user identified by "imapuser"). RFC number: this RFC Contact address: Barry Leiba This information should be added to the list of sieve environment item names given in the Environment extension [RFC5183]. 7.8. Registration of IMAP METADATA mailbox entry name The following template specifies the IANA registration of an IMAP METADATA entry name specified in this document: To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [x] Mailbox [ ] Server Name: /IMAPSieve/Script Description: This entry name is used to define mailbox metadata associated with IMAPSieve events for the associated mailbox. Specifically, this specifies the Sieve script that will be invoked when IMAP events occur on the specified mailbox. Content-type: text/plain; charset=utf-8 RFC number: this RFC Contact person: Barry Leiba Contact email: barryleiba@computer.org This information should be added to the list of IMAP METADATA item names given in the Metadata extension [RFC5464]. Leiba Expires January 9, 2012 [Page 20] Internet-Draft IMAP-Sieve July 2011 7.9. Registration of IMAP METADATA server entry name The following template specifies the IANA registration of an IMAP METADATA entry name specified in this document: To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /IMAPSieve/Script Description: This entry name is used to define metadata associated globally with IMAPSieve events for the associated server. Specifically, this specifies the Sieve script that will be invoked when IMAP events occur on any mailbox in the server that does not have its own mailbox-level /IMAPSieve/Script entry. Content-type: text/plain; charset=utf-8 RFC number: this RFC Contact person: Barry Leiba Contact email: barryleiba@computer.org This information should be added to the list of IMAP METADATA item names given in the Metadata extension [RFC5464]. Leiba Expires January 9, 2012 [Page 21] Internet-Draft IMAP-Sieve July 2011 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003. [RFC3894] Degener, J., "Sieve Extension: Copying Without Side Effects", RFC 3894, October 2004. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", RFC 5183, May 2008. [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008. [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009. 8.2. Non-Normative References [I-D.ietf-sieve-include] Daboo, C. and A. Stone, "Sieve Email Filtering: Include Extension", draft-ietf-sieve-include-06 (work in progress), July 2010. [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005. [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008. [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008. [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: Leiba Expires January 9, 2012 [Page 22] Internet-Draft IMAP-Sieve July 2011 Editheader Extension", RFC 5293, August 2008. [RFC5429] Stone, A., "Sieve Email Filtering: Reject and Extended Reject Extensions", RFC 5429, March 2009. [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009. [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, October 2009. [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, July 2010. Leiba Expires January 9, 2012 [Page 23] Internet-Draft IMAP-Sieve July 2011 Author's Address Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/ Leiba Expires January 9, 2012 [Page 24]