Sieve Working Group                                             B. Leiba
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                      September 27, 2010
Expires: March 31,                            July 8, 2011
Expires: January 9, 2012

     Support for Sieve in Internet Message Access Protocol (IMAP4)
                     draft-ietf-sieve-imap-sieve-01
                     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).

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 March 31, 2011. January 9, 2012.

Copyright Notice

   Copyright (c) 2010 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
   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 . . . . . . . . . . . . . . . . . . . . . . .  6  5
   1.1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . .  6  5
   1.2.    Conventions used in this document  . . . . . . . . . . . .  6  5

   2.      The IMAP "IMAPSieve" IMAPSieve Extension  . . . . . . . . . . . . . .  7 . . .  6
   2.1.    The "IMAPSieve" Capability String  . . . . . . . . . . . .  7  6
   2.2.    Existing IMAP Functions Affected by IMAPSieve  . . . . . .  7  6
   2.2.1.  The IMAP APPEND Command  . . . . . . . . . . . . . . . . .  7
   2.2.2.  The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . .  7
   2.2.3.  The IMAP COPY Command  . . . . . . . . . . . . . . . . . .  8  7
   2.2.4.  Changes to IMAP Message Flags  . . . . . . . . . . . . . .  8
   2.2.5.  New or Changed IMAP Message Annotations  . . . . . . . . .  8  7
   2.3.    New Functions Defined by IMAPSieve . . . . . . . . . . . .  9  8
   2.3.1.  Changes to  Interaction with Metadata  . . . . . . . . . . . . . . . . . . .  9  8

   3.      Applicable Sieve Actions and Interactions  . . . . . . . . 11 10
   3.1.    The Implicit Keep  . . . . . . . . . . . . . . . . . . . . 11 10
   3.2.    The Keep Action  . . . . . . . . . . . . . . . . . . . . . 11 10
   3.3.    The Fileinto Action  . . . . . . . . . . . . . . . . . . . 11 10
   3.4.    The Redirect Action  . . . . . . . . . . . . . . . . . . . 12 11
   3.5.    The Reject Discard Action . . . . . . . . . . . . . . . . . . . . 12 11
   3.6.    The Discard Notify Action  . . . . . . . . . . . . . . . . . . . . 12
   3.7.    The Notify Action Addheader and Deleteheader Actions . . . . . . . . . . 12
   3.8.    The Setflag, Deleteflag, and Removeflag Actions  . . . . . 12
   3.9.    MIME Part Tests and Replacement  . . . . . 13
   3.8.    The Addheader and Deleteheader Actions . . . . . . . . 12
   3.10.   Spamtest and Virustest . . . 13
   3.9.    The Setflag, Deleteflag, and Removeflag Actions . . . . . 13
   3.10.   The Vacation Action . . . . . . . . . . 13
   3.11.   Inapplicable Actions . . . . . . . . . 14
   3.11.   Spamtest . . . . . . . . . . 13

   4.      New Sieve Environment Items  . . . . . . . . . . . . . . . 14
   4.1.    New Sieve Environment Items: imapuser and imapemail  . . . 14
   3.12.
   4.2.    New Sieve Environment Item: cause  . . . . . . . . . . . . 14
   3.13.
   4.3.    New Sieve Environment Item: mailbox  . . . . . . . . . . . 14
   3.14.
   4.4.    New Sieve Environment Item: changedflags . . . . . . . . . 15
   3.15.   New Sieve Environment Item: changedannotations . . . . . . 15
   3.16.
   4.5.    Interaction With Sieve Tests (Comparisons) . . . . . . . . 15

   4.

   5.      Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16

   5.

   6.      Security Considerations  . . . . . . . . . . . . . . . . . 17

   6.

   7.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 18
   6.1.
   7.1.    Registration of imapsieve extension IMAPSIEVE IMAP capability  . . . . . . . . 18
   7.2.    Registration of imapsieve Sieve extension  . . . . . . . . 18
   6.2.
   7.3.    Registration of environment item: cause  . . . . . . . . . 18
   6.3.
   7.4.    Registration of environment item: mailbox  . . . . . . . . 18
   6.4. 19
   7.5.    Registration of environment item: changedflags . . . . . . 19
   6.5.
   7.6.    Registration of environment item: changedannotations imapuser . . . . . . . . 19
   6.6.
   7.7.    Registration of environment item: imapemail  . . . . . . . 20
   7.8.    Registration of IMAP METADATA mailbox entry name . . . . . 20
   6.7.
   7.9.    Registration of IMAP METADATA server entry name  . . . . . 20
   7. 21

   8.      References . . . . . . . . . . . . . . . . . . . . . . . . 22
   7.1.
   8.1.    Normative References . . . . . . . . . . . . . . . . . . . 22
   7.2.
   8.2.    Non-Normative References . . . . . . . . . . . . . . . . . 22

           Author's Address . . . . . . . . . . . . . . . . . . . . . 24

1.  Introduction

1.1.  Overview

   Some applications have a need to apply [Sieve] 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 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]). Notify [RFC5435]).

   This specification defines extensions to [IMAP] IMAP [RFC3501] to support
   the invocation of Sieve scripts at times when the IMAP server creates
   new
   messages, messages or modifies existing ones.  It also defines how Sieve
   scripts will process these invocations.  Support for IMAPSieve
   requires support for [Metadata] IMAP Metadata [RFC5464] and Sieve Environment
   [RFC5183] as well, since the latter because Metadata is used to associate scripts with
   IMAP mailboxes.

   [[anchor1: General note: Sieve was designed to work at final
   delivery, mailboxes and makes many assumptions about the context.  Will those
   assumptions break this environment without our realizing it fully?]]

   [[anchor2: Note about identity: We might want to use Environment defines an important way for Sieve
   scripts to impose
   fine-grained access controls.  In final delivery, there's no identity
   for the "filer".  Here, there is: test the logged-in IMAP user.  How do we
   get at that identity?]] 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 [Keywds]. [RFC2119].

2.  The IMAP "IMAPSieve" IMAPSieve Extension

2.1.  The "IMAPSieve" Capability String

   An IMAP

   [[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
   [Environment], IMAP
   Metadata [RFC5464] and Sieve Environment [RFC5183], because the latter 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 this the support
   requirement, scripts that directly use IMAPSieve must Environment MUST also include BOTH
   its capability strings string in their required "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
   [Sieve])
   [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.

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, 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] 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
   as they are AFTER the changes.

2.2.5.  New or Changed IMAP Message Annotations

   [[anchor3: Sieve has no way to get the annotations, so is there
   really value in being told about annotation changes here?  Maybe push
   that into a sieve-annotations extension later.]]

   If the IMAP server supports the [Annotate] extension, one or more
   existing messages can have annotations added or changed through the
   ANNOTATE command.  In a server that advertises IMAPSieve, messages
   getting new or changed annotations MUST trigger the execution of a
   Sieve script, subject to the settings defined through Metadata.

   For annotation-change events, the Sieve script will see the message
   annotations as they are AFTER the changes.

2.3.  New Functions Defined by IMAPSieve

2.3.1.  Changes to  Interaction with Metadata

   Support for IMAPSieve requires support for [Metadata] 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.

   This specifies

   [[COMMENT FROM NED: But the mechanism for "activating" a script for a given
   mailbox (or for all mailboxes), but does real question is why should we limit
   ourselves this way?  Why not specify a mechanism for
   creating, storing, or validating make the script.  Implementations MAY use
   [Manage] contents of "/IMAPSieve/Script"
   a URL?  (The metadata: prefix can then be defined as a URL.)  If we
   want to acomplish this, using the PUTSCRIPT command reach into ManageSieve, use a sieve: URL.  (I do see a big
   problem with this currently - RFC 5804 appears to store have badly botched
   the
   script without using specification of sieve: URLs - the SETACTIVE command to activate it.  In any
   case, authority field is mandatory
   when it shouldn't be, and the script name that owner field is specified 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
   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 extensions 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.

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 or annotation 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] 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 or annotation 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 [UIDPlus]) [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.4.  The Redirect Action

   [[anchor4: Redirect assumes message can be submitted as is - not a
   valid assumption in this context.  What do we do if the decision is
   "redirect" and there's not enough information to do it?  Also, some
   have been concerned about, say, a flag change that has the Sieve
   effect of forwarding the message somewhere.  Perhaps we should just
   forbid redirect.]]

   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] 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.

   For APPEND, MULTIAPPEND, and COPY, the

   It's possible that a message is stored into the
   target mailbox processed in addition to being redirected.  For flag or
   annotation changes, this way does not have the message remains in its original mailbox.

   If a keep action
   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 [UIDPlus]) [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 Reject Action

   The reject action is NOT applicable to any case that falls under
   IMAPSieve.  Its use MUST result in an error condition that will
   terminate the Sieve script.

3.6.  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
   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 [UIDPlus]) [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.7.

3.6.  The Notify Action

   If the [Notify] 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.8.

3.7.  The Addheader and Deleteheader Actions

   [[anchor5: Should editheader

   If the EditHeader extension [RFC5293] is available, it can be allowed used to
   make transient changes to change header fields that fields, which aren't saved in place,
   such as for redirect "redirect" or fileinto?  Editheader
   would still have to be banned for "keep", but not otherwise.]]

   Even if the [EditHeader] extension is available, since "fileinto" actions.  Because messages in
   IMAP mailboxes are immutable these actions immutable, such changes are NOT applicable.  Use
   of these MUST result in an error condition that will terminate the
   Sieve script.  Explanation: Using them for flag or annotation changes
   to existing messages would cause the message to be changed.  Using
   them applicable for APPEND, MULTIAPPEND, and COPY would cause unexpected
   differences in the stored copy as compared to what the client
   expected, and would make the client's message cache invalid
   unexpectedly.

3.9.
   "keep" acton (explicit or implicit).  See Section 3.1.

3.8.  The Setflag, Deleteflag, and Removeflag Actions

   [[anchor6: Should this just require imap4flags?  Some implementors
   have said they wouldn't bother with it without the ability to
   manipulate flags.  And what values

   Implementations of flags does it see -- before or
   after the change?  If it changes them, can it see the originals?  Can
   it reset changes?]]

   If IMAPSieve extension MUST also support the [IMAP4Flags]
   IMAP4Flags extension is available, [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.10.  The Vacation Action

   Even if

3.9.  MIME Part Tests and Replacement

   If the [Vacation] MIME Part Tests extension [RFC5703] is available, all of its
   functions can be used, but any changes made to the vacation action is 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.

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.  Its  Their use or their appearance in the
   "require" control MUST result in an error condition that will
   terminate the Sieve script.

3.11.  Spamtest

   [Spamtest] [[anchor7: We need to say something about script:

      reject [RFC5228]

      ereject [RFC5429]

      vacation [RFC5230]

4.  New Sieve Environment Items

4.1.  New Sieve Environment Items: imapuser and imapemail

   In the spamtest/
   virustest extension.  We need 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 able to scan appended messages.
   And we can't use headers to communicate spam status, because the
   message empty string if it is immutable.  What should we say here?]]

3.12. 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,
   annotation changes).
   If the actions to be taken are common, and the implementation
   supports the [Include] extension, Include extension [I-D.ietf-sieve-include], the common
   script code can be included as specified there.

   It may be preferable, though, to use

   Each mailbox uses a single script for all these
   conditions. the change conditions
   described in this document (append, copy, flag changes).  To support
   that, the implementation MUST set the
   [Environment] 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)

   o  ANNOTATE (for invocations resulting from new or changed
      annotations)

3.13.

4.3.  New Sieve Environment Item: mailbox

   The implementation MUST set the [Environment] 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
   script begins, and, in particular, MUST NOT change as a result of any
   action, such as "fileinto".

3.14.

4.4.  New Sieve Environment Item: changedflags

   If the [IMAP4Flags] IMAP4Flags extension [RFC5232] is available, AND the script
   was invoked because of flag changes to an existing message, the
   implementation MUST set the [Environment] 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 4 5 for an
   example of how this might be used.

3.15.  New Sieve Environment Item: changedannotations

   If the [Annotate] extension is available, AND the script was invoked
   because of annotation changes to an existing message, the
   implementation MUST set the [Environment] item "changedannotations"
   to the name(s) of the annotation(s) that have changed.  If the script
   was not invoked because of annotation changes, the value of this item
   MUST be the empty string.

3.16.

4.5.  Interaction With Sieve Tests (Comparisons)

   This extension does not affect the operation of any tests or
   comparisons.

4. comparisons
   in the Sieve base specification.

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), IMAP4Flags extension [RFC5232]), a notification
   is sent using the [Notify] extension. Notify extension [RFC5435].  No notification will
   be sent, though, if we're called with an existing message that
   already had that flag set.

     require ["notify", ["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}"; ${mailbox}"
           "xmpp:tim@example.com?message;subject=SIEVE";
     }

5.

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. 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], IMAP [RFC3501], and [Sieve],
   Sieve [RFC5228], as well as in some of the other extension documents.

6.

7.  IANA Considerations

6.1.

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 <barryleiba@computer.org>

   This information should be added to the list of sieve extensions
   given on http://www.iana.org/assignments/sieve-extensions.

6.2.

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)

   o  ANNOTATE (for invocations resulting from new or changed
      annotations)

   RFC number: this RFC
   Contact address:
       Barry Leiba <barryleiba@computer.org>

   This information should be added to the list of sieve environment
   item names given in the [Environment] extension.

6.3. Environment extension [RFC5183].

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 <barryleiba@computer.org>

   This information should be added to the list of sieve environment
   item names given in the [Environment] extension.

6.4. 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 <barryleiba@computer.org>

   This information should be added to the list of sieve environment
   item names given in the [Environment] extension.

6.5. Environment extension [RFC5183].

7.6.  Registration of environment item: changedannotations 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: changedannotations imapuser
   Description: If the script was invoked because The identity (IMAP login ID) of annotation changes
   to an existing message, the IMAP user that
   caused the action.

   RFC number: this contains RFC
   Contact address:
       Barry Leiba <barryleiba@computer.org>

   This information should be added to the name(s) list of sieve environment
   item names given in the
   annotation(s) that have changed.  Otherwise, Environment extension [RFC5183].

7.7.  Registration of environment item: imapemail

   The following template specifies the value 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 this item
   MUST be the empty string. IMAP user that caused
   the action (the user identified by "imapuser").
   RFC number: this RFC
   Contact address:
       Barry Leiba <barryleiba@computer.org>

   This information should be added to the list of sieve environment
   item names given in the [Environment] extension.

6.6. 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.

6.7. Metadata extension [RFC5464].

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.

7. Metadata extension [RFC5464].

8.  References

7.1.

8.1.  Normative References

   [Annotate]
              Daboo, C. and R. Gellens, "IMAP ANNOTATE

   [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 5257, June 2008.

   [Copy] 3502, March 2003.

   [RFC3894]  Degener, J., "Sieve Extension: Copying Without Side
              Effects", RFC 3894, October 2004.

   [Environment]

   [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.

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1",

   [RFC5228]  Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", RFC 3501, March 2003.

   [IMAP4Flags] 5228, January 2008.

   [RFC5232]  Melnikov, A., "Sieve Mail Filtering Language: IMAP flag Email Filtering: Imap4flags
              Extension", RFC 5232, January 2008.

   [Keywds]   Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [Metadata]

   [RFC5464]  Daboo, C., "The IMAP METADATA Extension", RFC 5464,
              February 2009.

   [MultiAppend]

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) -
              MULTIAPPEND Extension",
              UIDPLUS extension", RFC 3502, March 2003.

   [Sieve]    Guenther, P., Ed. and T. 4315, December 2005.

   [RFC5230]  Showalter, Ed., "Sieve: An T. and N. Freed, "Sieve Email
              Filtering Language", Filtering:
              Vacation Extension", RFC 5228, 5230, January 2008.

7.2.  Non-Normative References

   [EditHeader]

   [RFC5235]  Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
              Extensions", RFC 5235, January 2008.

   [RFC5293]  Degener, J. and P. Guenther, "Sieve Email Filtering:

              Editheader Extension", RFC 5293, August 2008.

   [Include]  Daboo, C. and A.

   [RFC5429]  Stone, "SIEVE A., "Sieve Email Filtering: Include
              Extension", work in progress, http://tools.ietf.org/html/
              draft-ietf-sieve-include, July 2009.

   [Manage]   Melnikov, A., Ed. Reject and T. Martin, "A Protocol for Remotely
              Managing Sieve Scripts", Extended
              Reject Extensions", RFC editor queue, http://
              tools.ietf.org/html/draft-ietf-sieve-managesieve,
              January 5429, March 2009.

   [Notify]

   [RFC5435]  Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin,
              "Sieve Email Filtering: Extension for Notifications",
              RFC 5435, January 2009.

   [Spamtest]

   [RFC5703]  Hansen, T. and C. Daboo, C., "Sieve Email Filtering: Spamtest MIME Part
              Tests, Iteration, Extraction, Replacement, and Virustest
              Extensions", RFC 5235, January 2008.

   [UIDPlus]  Crispin, M., "Internet Message Access Protocol (IMAP) -
              UIDPLUS Extension", Enclosure",
              RFC 4315, December 2005.

   [Vacation]
              Showalter, T. 5703, October 2009.

   [RFC5804]  Melnikov, A. and N. Freed, Ed., "Sieve Email Filtering:
              Vacation Extension", T. Martin, "A Protocol for Remotely
              Managing Sieve Scripts", RFC 5230, January 2008. 5804, July 2010.

Author's Address

   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648
   Email: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/