draft-ietf-sieve-imap-sieve-09.txt   rfc6785.txt 
Sieve Working Group B. Leiba Internet Engineering Task Force (IETF) B. Leiba
Internet-Draft Huawei Technologies Request for Comments: 6785 Huawei Technologies
Updates: 5228 (if approved) September 14, 2012 Updates: 5228 November 2012
Intended status: Standards Track Category: Standards Track
Expires: March 18, 2013 ISSN: 2070-1721
Support for Internet Message Access Protocol (IMAP) Events in Sieve Support for Internet Message Access Protocol (IMAP) Events in Sieve
draft-ietf-sieve-imap-sieve-09
Abstract Abstract
Sieve defines an email filtering language that can, in principle, Sieve defines an email filtering language that can, in principle,
plug into any point in the processing of an email message. As plug into any point in the processing of an email message. As
defined in the base specification, it plugs into mail delivery. This defined in the base specification, it plugs into mail delivery. This
document defines how Sieve can plug into points in the IMAP protocol document defines how Sieve can plug into points in IMAP where
where messages are created or changed, adding the option of user- messages are created or changed, adding the option of user-defined or
defined or installation-defined filtering (or, with Sieve extensions, installation-defined filtering (or, with Sieve extensions, features
features such as notifications). Because this requires future Sieve such as notifications). Because this requires future Sieve
extensions to specify their interactions with this one, this document extensions to specify their interactions with this one, this document
updates the base Sieve specification, RFC 5228. updates the base Sieve specification, RFC 5228.
Status of this Memo 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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 18, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6785.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview ...................................................3
1.2. Differences Between IMAP Events and Mail Delivery . . . . 4 1.2. Differences between IMAP Events and Mail Delivery ..........4
1.3. Conventions used in this document . . . . . . . . . . . . 5 1.3. Conventions Used in This Document ..........................5
2. The "IMAP Events in Sieve" Extension ............................5
2. The IMAP Events in Sieve Extension . . . . . . . . . . . . 6 2.1. The "imapsieve" Capability Strings .........................5
2.1. The "imapsieve" Capability Strings . . . . . . . . . . . . 6 2.2. Existing IMAP Functions Affected by IMAP Events in Sieve ...5
2.2. Existing IMAP Functions Affected by IMAP events in 2.2.1. The IMAP APPEND Command .............................6
Sieve . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. The IMAP COPY Command ...............................6
2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 2.2.3. Changes to IMAP Message Flags .......................6
2.2.2. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7 2.2.4. When Script Actions Set the \Deleted Flag ...........7
2.2.3. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7 2.3. New Functions Defined by IMAP Events in Sieve ..............7
2.2.4. When Script Actions Set the \Deleted Flag . . . . . . . . 8 2.3.1. Interaction with Metadata ...........................7
2.3. New Functions Defined by IMAP events in Sieve . . . . . . 8 3. Applicable Sieve Actions and Interactions .......................8
2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8 3.1. The Implicit Keep ..........................................9
3.2. The "keep" Action ..........................................9
3. Applicable Sieve Actions and Interactions . . . . . . . . 10 3.3. The "fileinto" Action ......................................9
3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10 3.4. The "redirect" Action ......................................9
3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10 3.5. The "discard" Action ......................................10
3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10 3.6. The "notify" Action .......................................10
3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11 3.7. The "addheader" and "deleteheader" Actions ................10
3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11 3.8. The "setflag", "deleteflag", and "removeflag" Actions .....11
3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 11 3.9. MIME Part Tests and Replacement ...........................11
3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12 3.10. spamtest and virustest ...................................11
3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 3.11. Inapplicable Actions .....................................11
3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12 3.12. Future Sieve Actions .....................................12
3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 12
3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 12
3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 13
4. Interaction With Sieve Environment . . . . . . . . . . . . 14
4.1. Base Sieve Environment Items: location and phase . . . . . 14
4.2. New Sieve Environment Items: imap.user and imap.email . . 14
4.3. New Sieve Environment Item: imap.cause . . . . . . . . . . 14
4.4. New Sieve Environment Item: imap.mailbox . . . . . . . . . 15
4.5. New Sieve Environment Item: imap.changedflags . . . . . . 15
4.6. 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
7.2. Registration of "imapsieve" Sieve extension . . . . . . . 18
7.3. Registration of Sieve Environment Items . . . . . . . . . 18
7.3.1. Registration of Sieve Environment Item: imap.cause . . . . 18
7.3.2. Registration of Sieve Environment Item: imap.mailbox . . . 19
7.3.3. Registration of Sieve Environment Item:
imap.changedflags . . . . . . . . . . . . . . . . . . . . 19
7.3.4. Registration of Sieve Environment Item: imap.user . . . . 19
7.3.5. Registration of Sieve Environment Item: imap.email . . . . 19
7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 19
7.5. Registration of IMAP METADATA Server Entry Name . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . 23 4. Interaction with Sieve Environment .............................12
4.1. Base Sieve Environment Items: location and phase ..........12
4.2. New Sieve Environment Items: imap.user and imap.email .....12
4.3. New Sieve Environment Item: imap.cause ....................13
4.4. New Sieve Environment Item: imap.mailbox ..................13
4.5. New Sieve Environment Item: imap.changedflags .............13
4.6. Interaction with Sieve Tests (Comparisons) ................13
5. Examples .......................................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................16
7.1. Registration of "imapsieve" IMAP Capability ...............16
7.2. Registration of "imapsieve" Sieve Extension ...............16
7.3. Registration of Sieve Environment Items ...................16
7.3.1. Registration of Sieve Environment Item:
imap.cause .........................................16
7.3.2. Registration of Sieve Environment Item:
imap.mailbox .......................................17
7.3.3. Registration of Sieve Environment Item:
imap.changedflags ..................................17
7.3.4. Registration of Sieve Environment Item: imap.user ..17
7.3.5. Registration of Sieve Environment Item:
imap.email .........................................17
7.4. Registration of IMAP METADATA Mailbox Entry Name ..........18
7.5. Registration of IMAP METADATA Server Entry Name ...........18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................19
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
Some applications have a need to apply Sieve filters [RFC5228] in Some applications have a need to apply Sieve filters [RFC5228] in
contexts other than initial mail delivery. This is especially true contexts other than initial mail delivery. This is especially true
in diverse service environments, such as when the client is in diverse service environments, such as when the client is
sporadically connected, is connected through a high-latency or high- sporadically connected, is connected through a high-latency or
cost channel, or is on a limited-function device. For such clients, high-cost channel, or is on a limited-function device. For such
it may be very important, for higher performance and reliability, to clients, it may be very important, for higher performance and
take advantage of server capabilities, including those provided by reliability, to take advantage of server capabilities, including
Sieve filtering (and Sieve extensions, such as Notify [RFC5435]). those provided by Sieve filtering (and Sieve extensions, such as
Notify [RFC5435]).
This specification defines extensions to IMAP [RFC3501] to support This specification defines extensions to IMAP [RFC3501] to support
the invocation of Sieve scripts at times when the IMAP server creates the invocation of Sieve scripts at times when the IMAP server creates
new messages or modifies existing ones. It also defines how Sieve new messages or modifies existing ones. It also defines how Sieve
scripts will process these invocations. Support for IMAP events in scripts will process these invocations. Support for IMAP events in
Sieve also requires support for the following: Sieve also requires support for the following:
o IMAP Metadata [RFC5464], because Metadata is used to associate o IMAP Metadata [RFC5464], because Metadata is used to associate
scripts with IMAP mailboxes. scripts with IMAP mailboxes.
o Sieve Environment [RFC5183], because it defines an important way o Sieve Environment [RFC5183], because it defines an important way
for Sieve scripts to test the conditions under which they have for Sieve scripts to test the conditions under which they have
been invoked. been invoked.
o Sieve IMAP4Flags [RFC5232], because it provides important o Sieve imap4flags [RFC5232], because it provides important
functionality in handling IMAP events related to flag changes. functionality in handling IMAP events related to flag changes.
Because this requires future Sieve extensions to specify their Because this requires future Sieve extensions to specify their
interactions with this one (see Section 3.12), this document updates interactions with this one (see Section 3.12), this document updates
the base Sieve specification, RFC 5228. the base Sieve specification, RFC 5228.
1.2. Differences Between IMAP Events and Mail Delivery 1.2. Differences between IMAP Events and Mail Delivery
Invoking Sieve scripts in a context other than initial mail delivery Invoking Sieve scripts in a context other than initial mail delivery
introduces new situations, which changes the applicability of Sieve introduces new situations; this changes the applicability of Sieve
features and creates implementation challenges and user interface features, creates implementation challenges, and creates user
issues. This section discusses some of those differences, interface issues. This section discusses some of those differences,
challenges, and issues. challenges, and issues.
At times other than message delivery, delivery "envelope" information At times other than message delivery, delivery "envelope" information
might not be available. With messages added through IMAP APPEND, might not be available. With messages added through IMAP APPEND,
there might be no way to even guess who the intended recipient is, there might be no way to even guess who the intended recipient is,
and no concept of who "sent" the message. Sieve actions that relate and no concept of who "sent" the message. Sieve actions that relate
to contacting the sender, for example, will not be applicable. to contacting the sender, for example, will not be applicable.
Because IMAP events will often be triggered by user actions, and Because IMAP events will often be triggered by user actions, and
because user interfaces allow bulk actions that differ from because user interfaces allow bulk actions that differ from
individual message arrival, it now becomes possible for a single user individual message arrival, it now becomes possible for a single user
action, such as drag-and-drop, to initiate Sieve script processing on action, such as drag-and-drop, to initiate Sieve script processing on
a large number of messages at once. Implementations will have to a large number of messages at once. Implementations will have to
deal with such situations as a "COPY" action or flag changes on deal with such situations as a "COPY" action or flag changes on
dozens, or even thousands of messages. dozens, or even thousands, of messages.
Other issues might surface as this extension is deployed and Other issues might surface as this extension is deployed and
experience with it develops. experience with it develops.
1.3. Conventions used in this document 1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The IMAP Events in Sieve Extension 2. The "IMAP Events in Sieve" Extension
2.1. The "imapsieve" Capability Strings 2.1. The "imapsieve" Capability Strings
An IMAP server advertises support for IMAP events in Sieve through An IMAP server advertises support for IMAP events in Sieve through
the "imapsieve" capability. A server that advertises "imapsieve" is the "imapsieve" capability. A server that advertises "imapsieve" is
claiming to be in compliance with this specification in all aspects. claiming to be in compliance with this specification in all aspects.
The syntax of the "imapsieve" capability string is defined as The syntax of the "imapsieve" capability string is defined as
follows: follows:
capability /= "IMAPSIEVE=" sieveurl-server capability /= "IMAPSIEVE=" sieveurl-server
; <sieveurl-server> is defined in RFC 5804, Section 3 ; <sieveurl-server> is defined in RFC 5804, Section 3
Only one "imapsieve" capability string, specifying one sieveurl- Only one "imapsieve" capability string, specifying one
server, is allowed to be present. The sieveurl-server identifies the sieveurl-server, is allowed to be present. The sieveurl-server
ManageSieve server that clients need to contact for managing Sieve identifies the ManageSieve server that clients need to contact for
scripts associated with this IMAP server. managing Sieve scripts associated with this IMAP server.
The corresponding Sieve implementation uses the Sieve capability The corresponding Sieve implementation uses the Sieve capability
string "imapsieve", and Sieve scripts that depend upon the IMAP string "imapsieve", and Sieve scripts that depend upon the IMAP
events MUST include that string in their "required" lists. events MUST include that string in their "required" lists.
Implementations that support IMAP events in Sieve MUST also support Implementations that support IMAP events in Sieve MUST also support
IMAP Metadata [RFC5464] and Sieve Environment [RFC5183], because IMAP Metadata [RFC5464] and Sieve Environment [RFC5183], because
Metadata is used to associate scripts with IMAP mailboxes and Metadata is used to associate scripts with IMAP mailboxes and
Environment defines an important way for Sieve scripts to test the Environment defines an important way for Sieve scripts to test the
conditions under which they have been invoked. Notwithstanding the conditions under which they have been invoked. Notwithstanding the
support requirement, scripts that directly use Environment MUST also support requirement, scripts that directly use Environment MUST also
include its capability string in their "required" lists. include its capability string in their "required" lists.
2.2. Existing IMAP Functions Affected by IMAP events in Sieve 2.2. Existing IMAP Functions Affected by IMAP Events in Sieve
The subsections below describe in detail the IMAP commands and The subsections below describe in detail the IMAP commands and
situations on which IMAP events in Sieve have an effect. Not all situations on which IMAP events in Sieve have an effect. Not all
Sieve actions make sense in the case of messages affected by IMAP Sieve actions make sense in the case of messages affected by IMAP
commands. See Section 3 for details. commands. See Section 3 for details.
It's important to note that since the base Sieve specification (see It's important to note that since the base Sieve specification (see
[RFC5228]) and its extensions define functions for scripts that are [RFC5228]) and its extensions define functions for scripts that are
invoked during initial mail delivery, those function definitions are invoked during initial mail delivery, those function definitions are
necessarily tailored to and limited by that context. This document necessarily tailored to and limited by that context. This document
extends those function definitions for use during IMAP events. By extends those function definitions for use during IMAP events. By
nature of that, Sieve functions, in this extended context, may behave nature of that, Sieve functions, in this extended context, may behave
somewhat differently, though their extended behaviour will still be somewhat differently, though their extended behavior will still be
consistent with the functions' goals. consistent with the functions' goals.
If more than one message is affected at the same time, each message If more than one message is affected at the same time, each message
triggers the execution of a Sieve script separately. The scripts MAY triggers the execution of a Sieve script separately. The scripts MAY
be run in parallel. be run in parallel.
2.2.1. The IMAP APPEND Command 2.2.1. The IMAP APPEND Command
A message may be added to a mailbox through 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 In a server that advertises "imapsieve", new messages added in this
way MUST trigger the execution of a Sieve script, subject to the way MUST trigger the execution of a Sieve script, subject to the
settings defined through Metadata (see Section 2.3.1). settings defined through Metadata (see Section 2.3.1).
If the IMAP server also supports the IMAP MultiAppend extension If the IMAP server also supports the IMAP MULTIAPPEND extension
[RFC3502], the APPEND command can create more than one message at a [RFC3502], the APPEND command can create more than one message at a
time. In that case, each message creation is considered a separate time. In that case, each message creation is considered a separate
event, and any applicable Sieve script is called once for each event, and any applicable Sieve script is called once for each
message. message.
2.2.2. The IMAP COPY Command 2.2.2. The IMAP COPY Command
One or more messages may be added to a mailbox through the IMAP COPY One or more messages may be added to a mailbox through the IMAP COPY
command. In a server that advertises "imapsieve", new messages added command. In a server that advertises "imapsieve", new messages added
in this way MUST trigger the execution of a Sieve script, subject to in this way MUST trigger the execution of a Sieve script, subject to
skipping to change at page 7, line 38 skipping to change at page 6, line 44
One or more existing messages can have their flags changed in a One or more existing messages can have their flags changed in a
number of ways, including: number of ways, including:
o The FETCH command (may cause the \Seen flag to be set). o The FETCH command (may cause the \Seen flag to be set).
o The STORE command (may cause the \Answered, \Deleted, \Draft, o The STORE command (may cause the \Answered, \Deleted, \Draft,
\Flagged, and \Seen flags to be set or reset, and may cause \Flagged, and \Seen flags to be set or reset, and may cause
keywords to be set or reset). keywords to be set or reset).
o The invocation of a Sieve script on an existing message, where the o The invocation of a Sieve script on an existing message, where the
script uses one of the actions defined in the IMAP4Flags extension script uses one of the actions defined in the imap4flags extension
[RFC5232] to change the flags. [RFC5232] to change the flags.
In a server that advertises "imapsieve", messages whose flags are In a server that advertises "imapsieve", messages whose flags are
changed in any way (except as explained in the next sentence) MUST changed in any way (except as explained in the next sentence) MUST
trigger the execution of a Sieve script, subject to the settings trigger the execution of a Sieve script, subject to the settings
defined through Metadata. The exception is that in order to avoid 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 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 a was itself invoked because of flag changes SHOULD NOT result in a
further invocation of the script. In any case, implementations MUST further invocation of the script. In any case, implementations MUST
take steps to avoid such loops. take steps to avoid such loops.
skipping to change at page 8, line 23 skipping to change at page 7, line 29
script is not invoked. script is not invoked.
The implementation MAY then expunge the original message (WITHOUT The implementation MAY then expunge the original message (WITHOUT
expunging other messages in the mailbox). Alternatively, it might expunging other messages in the mailbox). Alternatively, it might
have expunges batched or done by a user. (It might be helpful to have expunges batched or done by a user. (It might be helpful to
allow the user to make this choice through a preference.) allow the user to make this choice through a preference.)
If the server does the expunge, the effect is as though a client had 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 flagged the message and done a UID EXPUNGE (see [RFC4315]) on the
affected message(s) only. Handling it this way allows clients to affected message(s) only. Handling it this way allows clients to
handle messages consistently, and avoids hidden changes that might handle messages consistently and avoids hidden changes that might
invalidate their message caches. invalidate their message caches.
2.3. New Functions Defined by IMAP events in Sieve 2.3. New Functions Defined by IMAP Events in Sieve
2.3.1. Interaction with Metadata 2.3.1. Interaction with Metadata
Support for IMAP events in Sieve requires support for IMAP Metadata Support for IMAP events in Sieve requires support for IMAP Metadata
[RFC5464] as well, since the latter is used to associate scripts with [RFC5464] as well, since the latter is used to associate scripts with
IMAP mailboxes. IMAP mailboxes.
When an applicable event occurs on an IMAP mailbox, if there is an When an applicable event occurs on an IMAP mailbox, if there is an
IMAP metadata entry named "/shared/imapsieve/script" for the mailbox, IMAP metadata entry named "/shared/imapsieve/script" for the mailbox,
that entry is used. If there is not, but there is an IMAP metadata that entry is used. If there is not, but there is an IMAP metadata
skipping to change at page 8, line 50 skipping to change at page 8, line 9
If a "/shared/imapsieve/script" metadata entry was selected above, If a "/shared/imapsieve/script" metadata entry was selected above,
its value is used as the name of the Sieve script that will be its value is used as the name of the Sieve script that will be
invoked in response to the IMAP event. If the value is empty, then invoked in response to the IMAP event. If the value is empty, then
no script is run. The selection of which metadata entry to use no script is run. The selection of which metadata entry to use
happens before any examination of the contents of the entry. If the happens before any examination of the contents of the entry. If the
mailbox entry is selected and is then found to be unusable or empty, mailbox entry is selected and is then found to be unusable or empty,
the server entry is not used as a backup: no script is run. the server entry is not used as a backup: no script is run.
This specifies the mechanism for "activating" a script for a given This specifies the mechanism for "activating" a script for a given
mailbox (or for all mailboxes), but does not specify a mechanism for mailbox (or for all mailboxes) but does not specify a mechanism for
creating, storing, or validating the script. Implementations MUST creating, storing, or validating the script. Implementations MUST
support ManageSieve [RFC5804], and can use the PUTSCRIPT command to support ManageSieve [RFC5804] and can use the PUTSCRIPT command to
store the script without using the SETACTIVE command to activate it. store the script without using the SETACTIVE command to activate it.
Script names used in "/shared/imapsieve/script" metadata entries are Script names used in "/shared/imapsieve/script" metadata entries are
the script names used on the corresponding ManageSieve server. If a the script names used on the corresponding ManageSieve server. If a
"/shared/imapsieve/script" metadata entry contains a script name that "/shared/imapsieve/script" metadata entry contains a script name that
doesn't exist in the ManageSieve server, then no Sieve script will be doesn't exist in the ManageSieve server, then no Sieve script will be
invoked for IMAP Sieve events. invoked for IMAP Sieve events.
Only one Sieve script may currently be defined per mailbox, Only one Sieve script may currently be defined per mailbox,
eliminating the complexity and possible ambiguity involved with eliminating the complexity and possible ambiguity involved with
skipping to change at page 10, line 11 skipping to change at page 8, line 43
(and it's expected that there will) be different scripts associated (and it's expected that there will) be different scripts associated
with events for different mailboxes. Indeed, most mailboxes will with events for different mailboxes. Indeed, most mailboxes will
probably invoke no script at all. probably invoke no script at all.
3. Applicable Sieve Actions and Interactions 3. Applicable Sieve Actions and Interactions
Since some Sieve actions relate specifically to the delivery of mail, Since some Sieve actions relate specifically to the delivery of mail,
not all actions and extensions make sense when the messages are not all actions and extensions make sense when the messages are
created by other means or when changes are made to data associated created by other means or when changes are made to data associated
with existing messages. This section describes how actions in the with existing messages. This section describes how actions in the
base Sieve specification, and those in extensions known at this base Sieve specification, and those in extensions known at the time
writing, relate to this specification. of this writing, relate to this specification.
In addition to what is specified here, interactions noted in the In addition to what is specified here, interactions noted in the
individual specifications apply, and must be considered. individual specifications apply and must be considered.
3.1. The Implicit Keep 3.1. The Implicit Keep
For all cases that fall under IMAP events in Sieve, the implicit keep For all cases that fall under IMAP events in Sieve, the implicit keep
means that the message is treated as it would have been if no Sieve means that the message is treated as it would have been if no Sieve
script were run. For APPEND and COPY, the message is stored into the script were run. For APPEND and COPY, the message is stored into the
target mailbox normally. For flag changes, the message is left in target mailbox normally. For flag changes, the message is left in
the mailbox. If actions have been taken that change the message, the mailbox. If actions have been taken that change the message,
those changes are considered transient and MUST NOT be retained for those changes are considered transient and MUST NOT be retained for
any keep action (because IMAP messages are immutable). No error is any "keep" action (because IMAP messages are immutable). No error is
generated, but the original message, without the changes, is kept. generated, but the original message, without the changes, is kept.
3.2. The Keep Action 3.2. The "keep" Action
The keep action is applicable in all cases that fall under IMAP The "keep" action is applicable in all cases that fall under IMAP
events in Sieve. Its behaviour is as described for implicit keep, in events in Sieve. Its behavior is as described for implicit keep, in
Section 3.1. Section 3.1.
3.3. The Fileinto Action 3.3. The "fileinto" Action
If the Sieve implementation supports the fileinto action, that action If the Sieve implementation supports the "fileinto" action, that
is applicable in all cases that fall under IMAP events in Sieve. If action is applicable in all cases that fall under IMAP events in
the Copy extension [RFC3894] is available and the :copy option is Sieve. If the "copy" extension [RFC3894] is available and the :copy
specified, the implicit keep is retained; otherwise, fileinto cancels option is specified, the implicit keep is retained; otherwise,
the implicit keep, as specified in the base Sieve specification. fileinto cancels the implicit keep, as specified in the base Sieve
specification.
For APPEND and COPY, the message is stored into the fileinto mailbox For APPEND and COPY, the message is stored into the fileinto mailbox
IN ADDITION TO the original target mailbox. For flag changes, the IN ADDITION TO the original target mailbox. For flag changes, the
message is COPIED into the fileinto mailbox, without removing the message is COPIED into the fileinto mailbox, without removing the
original. In all cases, fileinto always creates a new message, original. In all cases, fileinto always creates a new message,
separate from the original. separate from the original.
The fileinto action is not an IMAP APPEND or COPY, and therefore does The "fileinto" action is not an IMAP APPEND or COPY and therefore
not result in a subsequent event (see also the Security does not result in a subsequent event (see also the Security
Considerations, Section 6). Considerations, Section 6).
If a keep action is not also in effect, the original message is then If a "keep" action is not also in effect, the original message is
marked with the \Deleted flag (see Section 2.2.4). then marked with the \Deleted flag (see Section 2.2.4).
3.4. The Redirect Action 3.4. The "redirect" Action
The redirect action is applicable in all cases that fall under IMAP The "redirect" action is applicable in all cases that fall under IMAP
events in Sieve. It causes the message to be sent, as specified in events in Sieve. It causes the message to be sent, as specified in
the base Sieve specification, to the designated address. If the Copy the base Sieve specification, to the designated address. If the
extension [RFC3894] is available and the :copy option is specified, "copy" extension [RFC3894] is available and the :copy option is
the implicit keep is retained; otherwise, redirect cancels the specified, the implicit keep is retained; otherwise, redirect cancels
implicit keep, as specified in the base Sieve specification. the implicit keep, as specified in the base Sieve specification.
It's possible that a message processed in this way does not have the It's possible that a message processed in this way does not have the
information necessary to be redirected properly. It might lack information necessary to be redirected properly. It might lack
necessary header information, and there might not be appropriate necessary header information, and there might not be appropriate
information for the MAIL FROM command. In such cases, the "redirect" information for the MAIL FROM command. In such cases, the "redirect"
action uses Message Submission [RFC6409], and it is up to the Sieve action uses message submission [RFC6409], and it is up to the Sieve
engine to supply the missing information. The redirect address is, engine to supply the missing information. The redirect address is,
of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be set 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 to the address of the owner of the mailbox. The message submission
server is allowed, according to the Message Submission protocol, to server is allowed, according to the message submission protocol, to
perform necessary fix-up to the message (see Section 8 of RFC 6409). perform necessary fix-up to the message (see Section 8 of RFC 6409).
It can also reject the submission attempt, if the message is too ill- It can also reject the submission attempt if the message is too
formed for submission. ill-formed for submission.
For APPEND and COPY, the message is stored into the target mailbox in For APPEND and COPY, the message is stored into the target mailbox in
addition to being redirected. For flag changes, the message remains addition to being redirected. For flag changes, the message remains
in its original mailbox. in its original mailbox.
If a keep action is not also in effect, the original message is then If a "keep" action is not also in effect, the original message is
marked with the \Deleted flag (see Section 2.2.4). then marked with the \Deleted flag (see Section 2.2.4).
3.5. The Discard Action 3.5. The "discard" Action
The discard action is applicable in all cases that fall under IMAP The "discard" action is applicable in all cases that fall under IMAP
events in Sieve. For APPEND and COPY, the message is first stored events in Sieve. For APPEND and COPY, the message is first stored
into the target mailbox. If an explicit keep action is also in into the target mailbox. If an explicit "keep" action is also in
effect, the discard action now does nothing. Otherwise, the original effect, the "discard" action now does nothing. Otherwise, the
message is then marked with the \Deleted flag (see Section 2.2.4). original message is then marked with the \Deleted flag (see
Section 2.2.4).
3.6. The Notify Action 3.6. The "notify" Action
If the Nofity extension [RFC5435] is available, the notify action is If the Sieve notify extension [RFC5435] is available, the "notify"
applicable in all cases that fall under IMAP events in Sieve. The action is applicable in all cases that fall under IMAP events in
result is that the requested notification is sent, and that the Sieve. The result is that the requested notification is sent and
message is otherwise handled as it would normally have been. that the message is otherwise handled as it would normally have been.
3.7. The Addheader and Deleteheader Actions 3.7. The "addheader" and "deleteheader" Actions
If the EditHeader extension [RFC5293] is available, it can be used to If the editheader extension [RFC5293] is available, it can be used to
make transient changes to header fields, which aren't saved in place, make transient changes to header fields, which aren't saved in place,
such as for "redirect" or "fileinto" actions. Because messages in such as for "redirect" or "fileinto" actions. Because messages in
IMAP mailboxes are immutable, such changes are not applicable for the IMAP mailboxes are immutable, such changes are not applicable for the
"keep" action (explicit or implicit). See Section 3.1. "keep" action (explicit or implicit). See Section 3.1.
3.8. The Setflag, Deleteflag, and Removeflag Actions 3.8. The "setflag", "deleteflag", and "removeflag" Actions
Implementations of IMAP events in Sieve MUST also support the Implementations of IMAP events in Sieve MUST also support the
IMAP4Flags extension [RFC5232], and the actions associated with it imap4flags extension [RFC5232], and the actions associated with it
are all applicable to any case that falls under IMAP events in Sieve. are all applicable to any case that falls under IMAP events in Sieve.
It is worth noting also that the "hasflag" test that is defined in It is worth noting also that the "hasflag" test that is defined in
the IMAP4Flags extension might be particularly useful in scripts the imap4flags extension might be particularly useful in scripts
triggered by flag changes ("hasflag" will see the new, changed triggered by flag changes ("hasflag" will see the new, changed
flags). The flag changes behave as though a client had made the flags). The flag changes behave as though a client had made the
change. change.
As explained above, in order to avoid script loops flag changes that 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 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 flag changes SHOULD NOT result in another script invocation. In any
case, implementations MUST take steps to avoid such loops. case, implementations MUST take steps to avoid such loops.
3.9. MIME Part Tests and Replacement 3.9. MIME Part Tests and Replacement
If the MIME Part Tests extension [RFC5703] is available, all of its 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 functions can be used, but any changes made to the message, using the
"replace" or "enclose" action, MUST be considered transient, and are "replace" or "enclose" action, MUST be considered transient and are
only applicable with actions such as "redirect" and "fileinto". only applicable with actions such as "redirect" and "fileinto".
Because messages in IMAP mailboxes are immutable, such changes are Because messages in IMAP mailboxes are immutable, such changes are
not applicable for the "keep" action (explicit or implicit). See not applicable for the "keep" action (explicit or implicit). See
Section 3.1. Section 3.1.
3.10. Spamtest and Virustest 3.10. spamtest and virustest
If the Spamtest and Virustest extensions [RFC5235] are available, If the spamtest and virustest extensions [RFC5235] are available,
they are applicable in all cases that fall under IMAP events in they are applicable in all cases that fall under IMAP events in
Sieve. Sieve.
3.11. Inapplicable Actions 3.11. Inapplicable Actions
The following actions and extensions are not applicable to any case The following actions and extensions are not applicable to any case
that falls under IMAP events in Sieve, because they are specifically that falls under IMAP events in Sieve, because they are specifically
designed to respond to delivery of a new email message. Their designed to respond to delivery of a new email message. Their
appearance in the "require" control or their use in an IMAP event appearance in the "require" control or their use in an IMAP event
MUST result in an error condition that will terminate the Sieve MUST result in an error condition that will terminate the Sieve
skipping to change at page 14, line 5 skipping to change at page 12, line 19
3.12. Future Sieve Actions 3.12. Future Sieve Actions
As noted above, future extensions that are specifically designed to As noted above, future extensions that are specifically designed to
respond to delivery of a new email message will not be applicable to respond to delivery of a new email message will not be applicable to
this extension, because this extension does not involve acting at this extension, because this extension does not involve acting at
new-message delivery time. new-message delivery time.
In general, future extensions to Sieve that define new actions MUST In general, future extensions to Sieve that define new actions MUST
specify the applicability of those actions to this specification. specify the applicability of those actions to this specification.
4. Interaction With Sieve Environment 4. Interaction with Sieve Environment
4.1. Base Sieve Environment Items: location and phase 4.1. Base Sieve Environment Items: location and phase
The Sieve Environment extension defines a set of standard environment The Sieve Environment extension defines a set of standard environment
items (see [RFC5183], Section 4.1). Two of those items are affected items (see [RFC5183], Section 4.1). Two of those items are affected
when the script is invoked through an IMAP event. when the script is invoked through an IMAP event.
The value of "location" is set to "MS" -- evaluation is being The value of "location" is set to "MS" -- evaluation is being
performed by a Message Store. performed by a Message Store.
skipping to change at page 15, line 4 skipping to change at page 13, line 18
described in this document (append, copy, flag changes). To support described in this document (append, copy, flag changes). To support
that, the implementation MUST set the Environment [RFC5183] item that, the implementation MUST set the Environment [RFC5183] item
"imap.cause", which contains the name of the action that caused the "imap.cause", which contains the name of the action that caused the
script to be invoked. Its value is one of the following: script to be invoked. Its value is one of the following:
o APPEND (for invocations resulting from APPEND commands) o APPEND (for invocations resulting from APPEND commands)
o COPY (for invocations resulting from COPY commands) o COPY (for invocations resulting from COPY commands)
o FLAG (for invocations resulting from flag changes) o FLAG (for invocations resulting from flag changes)
Future extensions might define new events and, thus, new causes. Future extensions might define new events and, thus, new causes.
Such extensions will come with their own capability strings, and the Such extensions will come with their own capability strings, and the
events they define will only be presented when their capabilities are events they define will only be presented when their capabilities are
requested. Scripts that do not request those capabilities will not requested. Scripts that do not request those capabilities will not
see those events, and will not encounter the new cause strings. see those events and will not encounter the new cause strings.
4.4. New Sieve Environment Item: imap.mailbox 4.4. New Sieve Environment Item: imap.mailbox
The implementation MUST set the Environment [RFC5183] item The implementation MUST set the Environment [RFC5183] item
"imap.mailbox" to the name of the mailbox that the affected message "imap.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 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 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 when the script begins, and, in particular, MUST NOT change as a
result of any action, such as "fileinto". result of any action, such as "fileinto".
skipping to change at page 15, line 30 skipping to change at page 13, line 45
If the script was invoked because of flag changes to an existing If the script was invoked because of flag changes to an existing
message, the implementation MUST set the Environment [RFC5183] item message, the implementation MUST set the Environment [RFC5183] item
"imap.changedflags" to the name(s) of the flag(s) that have changed. "imap.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 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 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 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 the "hasflag" test to determine the current value. See example 2 in
Section 5 for an example of how this might be used. Section 5 for an example of how this might be used.
4.6. Interaction With Sieve Tests (Comparisons) 4.6. Interaction with Sieve Tests (Comparisons)
Any tests against message envelope information, including the Any tests against message envelope information, including the
"envelope" test in the Sieve base specification, as well as any such "envelope" test in the Sieve base specification, as well as any such
test defined in extensions, are either inapplicable or have serious test defined in extensions, are either inapplicable or have serious
interoperability issues when performed at other than final-delivery interoperability issues when performed at other than final-delivery
time. Therefore, envelope tests MUST NOT be permitted in the cases time. Therefore, envelope tests MUST NOT be permitted in the cases
described here, and their use MUST generate a runtime error. described here, and their use MUST generate a runtime error.
This extension does not affect the operation of other tests or This extension does not affect the operation of other tests or
comparisons in the Sieve base specification. comparisons in the Sieve base specification.
skipping to change at page 16, line 22 skipping to change at page 14, line 25
if anyof (environment :is "imap.cause" "APPEND", if anyof (environment :is "imap.cause" "APPEND",
environment :is "imap.cause" "COPY") { environment :is "imap.cause" "COPY") {
if environment :is "imap.mailbox" "ActionItems" { if environment :is "imap.mailbox" "ActionItems" {
redirect :copy "actionitems@example.com"; redirect :copy "actionitems@example.com";
} }
} }
Example 2: Example 2:
If the script is called for any message with the \Flagged flag set If the script is called for any message with the \Flagged flag set
(tested through the IMAP4Flags extension [RFC5232]) AND this script (tested through the imap4flags extension [RFC5232]) AND this script
invocation represents a change to that flag, then a notification is invocation represents a change to that flag, then a notification is
sent using the Notify extension [RFC5435]. No notification will be sent using the Sieve notify extension [RFC5435]. No notification
sent, though, if we're called with an existing message that already will be sent, though, if we're called with an existing message that
had that flag set. already had that flag set.
require ["enotify", "imap4flags", "variables", require ["enotify", "imap4flags", "variables",
"environment", "imapsieve"]; "environment", "imapsieve"];
if environment :matches "imap.mailbox" "*" { if environment :matches "imap.mailbox" "*" {
set "mailbox" "${1}"; set "mailbox" "${1}";
} }
if allof (hasflag "\\Flagged", if allof (hasflag "\\Flagged",
environment :contains "imap.changedflags" "\\Flagged") { environment :contains "imap.changedflags" "\\Flagged") {
notify :message "Important message in ${mailbox}" notify :message "Important message in ${mailbox}"
"xmpp:tim@example.com?message;subject=SIEVE"; "xmpp:tim@example.com?message;subject=SIEVE";
} }
Example 3: Example 3:
This shows an example IMAP CAPABILITY response when this extension is This shows an example IMAP CAPABILITY response when this extension is
supported. The client has done STARTTLS with the server, and is now supported. The client has done STARTTLS with the server and is now
inspecting capabilities. (The untagged CAPABILITY response is split inspecting capabilities. (The untagged CAPABILITY response is split
here for readability only, but will be in one response message.) here for readability only, but it will be in one response message.)
C: A01 CAPABILITY C: A01 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN UIDPLUS LIST-EXTENDED S: * CAPABILITY IMAP4rev1 AUTH=PLAIN UIDPLUS LIST-EXTENDED
ACL IMAPSIEVE=sieve://sieve.example.com MULTISEARCH ACL IMAPSIEVE=sieve://sieve.example.com MULTISEARCH
S: A01 OK done S: A01 OK done
6. Security Considerations 6. Security Considerations
It is possible to introduce script processing loops by having a Sieve It is possible to introduce script processing loops by having a Sieve
script that is triggered by flag changes use the actions defined in script that is triggered by flag changes use the actions defined in
the IMAP4Flags extension [RFC5232]. Implementations MUST take steps the imap4flags extension [RFC5232]. Implementations MUST take steps
to prevent script loops. One way to avoid this problem is that if a to prevent script loops. One way to avoid this problem is that if a
script is invoked by flag changes, and that script further changes script is invoked by flag changes, and that script further changes
the flags, those flag changes SHOULD NOT trigger a Sieve script the flags, those flag changes SHOULD NOT trigger a Sieve script
invocation. invocation.
The fileinto action never results in the invocation of a script. If The "fileinto" action never results in the invocation of a script.
an implementation did invoke a script as the result of a fileinto, as If an implementation did invoke a script as the result of a fileinto,
though an IMAP APPEND or COPY had been done, script loops could as though an IMAP APPEND or COPY had been done, script loops could
result (mailbox A responds to all COPY events by doing "fileinto B", result (mailbox A responds to all COPY events by doing "fileinto B",
and mailbox B responds to all COPY events by doing "fileinto A"). In and mailbox B responds to all COPY events by doing "fileinto A"). In
general, actions taken as a result of the Sieve script are not IMAP general, actions taken as a result of the Sieve script are not IMAP
events, and do not themselves trigger Sieve script invocations. events and do not themselves trigger Sieve script invocations.
It is also possible to introduce loops through the "redirect" or It is also possible to introduce loops through the "redirect" or
"notify" actions. See Section 10 of Sieve [RFC5228], Section 8 of "notify" actions. See Sieve [RFC5228], Section 10, Sieve Notify
Sieve Notify [RFC5435], and the Security Considerations sections of [RFC5435], Section 8, and the Security Considerations sections of the
the applicable notification-method documents for loop-prevention applicable notification-method documents for loop-prevention
information. This extension does not change any of that advice. information. This extension does not change any of that advice.
This extension introduces side-effects to IMAP commands that users This extension introduces side effects to IMAP commands that users
and script authors might not be aware of and that can accidentally be and script authors might not be aware of and that can accidentally be
triggered by an operation that the user would expect to be innocuous. triggered by an operation that the user would expect to be innocuous.
In particular, certain actions, such as redirect, can cause a message In particular, certain actions, such as "redirect", can cause a
(such as a message appended to a mailbox by a user) to be sent to the message (such as a message appended to a mailbox by a user) to be
Internet in response to something as simple as a flag change. For sent to the Internet in response to something as simple as a flag
example, a script might cause messages marked for deletion to be sent change. For example, a script might cause messages marked for
to some off-site archiving service. If a user appends a draft deletion to be sent to some off-site archiving service. If a user
message to a mailbox (perhaps an unencrypted draft message) and then appends a draft message to a mailbox (perhaps an unencrypted draft
marks it for deletion, it might be very surprising to the user that message) and then marks it for deletion, it might be very surprising
the message is sent off site. Script authors need to be careful not to the user that the message is sent off site. Script authors need
to create these kinds of surprises, especially when creating global to be careful not to create these kinds of surprises, especially when
scripts. creating global scripts.
Other security considerations are discussed in IMAP [RFC3501], and Other security considerations are discussed in IMAP [RFC3501] and
Sieve [RFC5228], as well as in some of the other extension documents. Sieve [RFC5228], as well as in some of the other extension documents.
7. IANA Considerations 7. IANA Considerations
7.1. Registration of "imapsieve" IMAP capability 7.1. Registration of "imapsieve" IMAP Capability
IANA is asked to add "IMAPSIEVE=" to the IMAP 4 Capabilities IANA has added "IMAPSIEVE=" to the IMAP 4 Capabilities registry
registry, according to the IMAP 4 specification [RFC3501]. (<http://www.iana.org/assignments/imap4-capabilities>), according to
(http://www.iana.org/assignments/imap4-capabilities) the IMAP 4 specification [RFC3501].
7.2. Registration of "imapsieve" Sieve extension 7.2. Registration of "imapsieve" Sieve Extension
The following information should be added to the Sieve Extensions The following information has been added to the Sieve Extensions
registry, according to the Sieve specification [RFC5228]. (http:// registry (<http://www.iana.org/assignments/sieve-extensions>),
www.iana.org/assignments/sieve-extensions/sieve-extensions.xml) according to the Sieve specification [RFC5228].
To: iana@iana.org
Subject: Registration of new Sieve extension
Capability name: imapsieve Capability name: imapsieve
Description: Add Sieve processing for IMAP events. Description: Add Sieve processing for IMAP events.
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3. Registration of Sieve Environment Items 7.3. Registration of Sieve Environment Items
The following subsections register items in the Sieve Environment The following subsections register items in the Sieve Environment
Items registry, according to the Environment extension [RFC5183]. Items registry
(http://www.iana.org/assignments/sieve-environment-items/ sieve- (<http://www.iana.org/assignments/sieve-environment-items>),
environment-items.xml) according to the Environment extension [RFC5183].
7.3.1. Registration of Sieve Environment Item: imap.cause 7.3.1. Registration of Sieve Environment Item: imap.cause
To: iana@iana.org
Subject: Registration of new Sieve environment item
Item name: imap.cause Item name: imap.cause
Description: The name of the action that caused the script to be Description: The name of the action that caused the script to be
invoked. Its value is one of the following: invoked. Its value is one of the following:
o APPEND (for invocations resulting from APPEND commands) o APPEND (for invocations resulting from APPEND commands)
o COPY (for invocations resulting from COPY commands) o COPY (for invocations resulting from COPY commands)
o FLAG (for invocations resulting from flag changes) o FLAG (for invocations resulting from flag changes)
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.2. Registration of Sieve Environment Item: imap.mailbox 7.3.2. Registration of Sieve Environment Item: imap.mailbox
To: iana@iana.org
Subject: Registration of new Sieve environment item
Item name: imap.mailbox Item name: imap.mailbox
Description: The name of the mailbox that the affected message is in, 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 existing messages, or is targeted to be stored
in the case of new messages. The value of this item is fixed when into, in the case of new messages. The value of this item is
the script begins, and, in particular, MUST NOT change as a result of fixed when the script begins, and, in particular, MUST NOT change
any action, such as "fileinto". as a result of any action, such as "fileinto".
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.3. Registration of Sieve Environment Item: imap.changedflags 7.3.3. Registration of Sieve Environment Item: imap.changedflags
To: iana@iana.org
Subject: Registration of new Sieve environment item
Item name: imap.changedflags Item name: imap.changedflags
Description: If the script was invoked because of flag changes to an 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 existing message, this contains the name(s) of the flag(s) that
changed. Otherwise, the value of this item MUST be the empty string. have changed. Otherwise, the value of this item MUST be the
RFC number: [[this RFC]] empty string.
RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.4. Registration of Sieve Environment Item: imap.user 7.3.4. Registration of Sieve Environment Item: imap.user
To: iana@iana.org
Subject: Registration of new Sieve environment item
Item name: imap.user Item name: imap.user
Description: The identity (IMAP login ID) of the IMAP user that Description: The identity (IMAP login ID) of the IMAP user that
caused the action. caused the action.
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.5. Registration of Sieve Environment Item: imap.email 7.3.5. Registration of Sieve Environment Item: imap.email
To: iana@iana.org
Subject: Registration of new Sieve environment item
Item name: imap.email Item name: imap.email
Description: The primary email address of the IMAP user that caused Description: The primary email address of the IMAP user that
the action (the user identified by "imap.user"). caused the action (the user identified by "imap.user").
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.4. Registration of IMAP METADATA Mailbox Entry Name 7.4. Registration of IMAP METADATA Mailbox Entry Name
The following information should be added to the IMAP METADATA The following information has been added to the IMAP METADATA Mailbox
Mailbox Entry Registry, according to the Metadata extension Entry Registry (<http://www.iana.org/assignments/imap-metadata>),
according to the METADATA extension [RFC5464].
[RFC5464].
(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml)
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Mailbox Type: Mailbox
Name: /shared/imapsieve/script Name: /shared/imapsieve/script
Description: This entry name is used to define mailbox metadata Description: This entry name is used to define mailbox metadata
associated with IMAP events in Sieve for the associated mailbox. associated with IMAP events in Sieve for the associated mailbox.
Specifically, this specifies the Sieve script that will be invoked Specifically, this specifies the Sieve script that will be invoked
when IMAP events occur on the specified mailbox. when IMAP events occur on the specified mailbox.
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.5. Registration of IMAP METADATA Server Entry Name 7.5. Registration of IMAP METADATA Server Entry Name
The following information should be added to the IMAP METADATA Server The following information has been added to the IMAP METADATA Server
Entry Registry, items according to the Metadata extension [RFC5464]. Entry Registry (<http://www.iana.org/assignments/imap-metadata>),
(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml) according to the METADATA extension [RFC5464].
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server Type: Server
Name: /shared/imapsieve/script Name: /shared/imapsieve/script
Description: This entry name is used to define metadata associated Description: This entry name is used to define metadata associated
globally with IMAP events in Sieve for the associated server. globally with IMAP events in Sieve for the associated server.
Specifically, this specifies the Sieve script that will be invoked Specifically, this specifies the Sieve script that will be invoked
when IMAP events occur on any mailbox in the server that does not when IMAP events occur on any mailbox in the server that does not
have its own mailbox-level /shared/imapsieve/script entry. have its own mailbox-level /shared/imapsieve/script entry.
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
RFC number: [[this RFC]] RFC number: 6785
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
4rev1", RFC 3501, March 2003. VERSION 4rev1", RFC 3501, March 2003.
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003. MULTIAPPEND Extension", RFC 3502, March 2003.
[RFC3894] Degener, J., "Sieve Extension: Copying Without Side [RFC3894] Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, October 2004. Effects", RFC 3894, October 2004.
[RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension",
RFC 5183, May 2008. RFC 5183, May 2008.
skipping to change at page 23, line 11 skipping to change at page 20, line 11
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
Tests, Iteration, Extraction, Replacement, and Enclosure", Tests, Iteration, Extraction, Replacement, and Enclosure",
RFC 5703, October 2009. RFC 5703, October 2009.
Author's Address Author's Address
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
 End of changes. 98 change blocks. 
246 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/