< draft-ietf-sieve-imap-sieve-01.txt   draft-ietf-sieve-imap-sieve-02.txt >
Sieve Working Group B. Leiba Sieve Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track September 27, 2010 Intended status: Standards Track July 8, 2011
Expires: March 31, 2011 Expires: January 9, 2012
Support for Sieve in Internet Message Access Protocol (IMAP4) Support for Sieve in Internet Message Access Protocol (IMAP4)
draft-ietf-sieve-imap-sieve-01 draft-ietf-sieve-imap-sieve-02
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 the IMAP protocol
where messages are created or changed, adding the option of user- where messages are created or changed, adding the option of user-
defined or installation-defined filtering (or, with Sieve extensions, defined or installation-defined filtering (or, with Sieve extensions,
features such as notifications). features such as notifications).
skipping to change at page 2, line 40 skipping to change at page 2, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2011. This Internet-Draft will expire on January 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Conventions used in this document . . . . . . . . . . . . 6 1.2. Conventions used in this document . . . . . . . . . . . . 5
2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 7 2. The IMAPSieve Extension . . . . . . . . . . . . . . . . . 6
2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 7 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 6
2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 7 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 6
2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7
2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7
2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 8 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7
2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 8 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7
2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 8
2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 9 2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8
2.3.1. Changes to Metadata . . . . . . . . . . . . . . . . . . . 9
3. Applicable Sieve Actions and Interactions . . . . . . . . 11 3. Applicable Sieve Actions and Interactions . . . . . . . . 10
3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 11 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10
3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 11 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10
3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 11 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10
3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 12 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11
3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 12 3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11
3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 12 3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 12
3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 13 3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12
3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 13 3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12
3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13 3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12
3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 14 3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 13
3.11. Spamtest . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 13
3.12. New Sieve Environment Item: cause . . . . . . . . . . . . 14
3.13. New Sieve Environment Item: mailbox . . . . . . . . . . . 14
3.14. New Sieve Environment Item: changedflags . . . . . . . . . 15
3.15. New Sieve Environment Item: changedannotations . . . . . . 15
3.16. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. New Sieve Environment Items . . . . . . . . . . . . . . . 14
4.1. New Sieve Environment Items: imapuser and imapemail . . . 14
4.2. New Sieve Environment Item: cause . . . . . . . . . . . . 14
4.3. New Sieve Environment Item: mailbox . . . . . . . . . . . 14
4.4. New Sieve Environment Item: changedflags . . . . . . . . . 15
4.5. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . 17 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . 17
6.1. Registration of imapsieve extension . . . . . . . . . . . 18
6.2. Registration of environment item: cause . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
6.3. Registration of environment item: mailbox . . . . . . . . 18 7.1. Registration of IMAPSIEVE IMAP capability . . . . . . . . 18
6.4. Registration of environment item: changedflags . . . . . . 19 7.2. Registration of imapsieve Sieve extension . . . . . . . . 18
6.5. Registration of environment item: changedannotations . . . 19 7.3. Registration of environment item: cause . . . . . . . . . 18
6.6. Registration of IMAP METADATA mailbox entry name . . . . . 20 7.4. Registration of environment item: mailbox . . . . . . . . 19
6.7. Registration of IMAP METADATA server entry name . . . . . 20 7.5. Registration of environment item: changedflags . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . 22 7.6. Registration of environment item: imapuser . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 7.7. Registration of environment item: imapemail . . . . . . . 20
7.2. Non-Normative References . . . . . . . . . . . . . . . . . 22 7.8. Registration of IMAP METADATA mailbox entry name . . . . . 20
7.9. Registration of IMAP METADATA server entry name . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Non-Normative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
Some applications have a need to apply [Sieve] filters in situations Some applications have a need to apply Sieve filters [RFC5228] in
other than initial mail delivery. This is especially true in diverse situations other than initial mail delivery. This is especially true
service environments, such as when the client is sporadically in diverse service environments, such as when the client is
connected, is connected through a high-latency or high-cost channel, sporadically connected, is connected through a high-latency or high-
or is on a limited-function device. For such clients, it may be very cost channel, or is on a limited-function device. For such clients,
important, for higher performance and reliability, to take advantage it may be very important, for higher performance and reliability, to
of server capabilities, including those provided by Sieve filtering take advantage of server capabilities, including those provided by
(and Sieve extensions, such as [Notify]). Sieve filtering (and Sieve extensions, such as Notify [RFC5435]).
This specification defines extensions to [IMAP] to support the This specification defines extensions to IMAP [RFC3501] to support
invocation of Sieve scripts at times when the IMAP server creates new the invocation of Sieve scripts at times when the IMAP server creates
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 IMAPSieve scripts will process these invocations. Support for IMAPSieve
requires support for [Metadata] as well, since the latter is used to requires support for IMAP Metadata [RFC5464] and Sieve Environment
associate scripts with IMAP mailboxes. [RFC5183] as well, because Metadata is used to associate scripts with
IMAP mailboxes and Environment defines an important way for Sieve
[[anchor1: General note: Sieve was designed to work at final scripts to test the conditions under which they have been invoked.
delivery, 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 Sieve to impose
fine-grained access controls. In final delivery, there's no identity
for the "filer". Here, there is: the logged-in IMAP user. How do we
get at that identity?]]
1.2. Conventions used in this document 1.2. 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", "MAY", and "OPTIONAL" in this document are to "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [Keywds]. be interpreted as described in [RFC2119].
2. The IMAP "IMAPSieve" Extension 2. The IMAPSieve Extension
2.1. The "IMAPSieve" Capability String 2.1. The "IMAPSieve" Capability String
[[anchor1: Should we use "imapsieve" for both of these, as here? Or
should we use something like "SieveEvents" for the IMAP capability
and "IMAPEvents" for the Sieve capability? I rather think it's less
confusing to use the same string for both.]]
An IMAP server advertises support for this extension through the An IMAP server advertises support for this extension through the
capability string "IMAPSieve" (the string is not case-sensitive, and capability string "IMAPSieve" (the string is not case-sensitive, and
is shown here with this capitalization for readability). A server is shown here with this capitalization for readability). A server
that advertises IMAPSieve is claiming to be in compliance with this that advertises IMAPSieve is claiming to be in compliance with this
specification in all aspects. specification in all aspects.
Implementations that support IMAPSieve MUST also support The corresponding Sieve implementation uses the Sieve capability
[Environment], because the latter defines an important way for Sieve string "IMAPSieve (also case-insensitive), and scripts that depend
scripts to test the conditions under which they have been invoked. upon the IMAP events MUST include that string in their "required"
Notwithstanding this requirement, scripts that use IMAPSieve must lists.
include BOTH capability strings in their required lists.
Implementations that support IMAPSieve MUST also support IMAP
Metadata [RFC5464] and Sieve Environment [RFC5183], because Metadata
is used to associate scripts with IMAP mailboxes and Environment
defines an important way for Sieve scripts to test the conditions
under which they have been invoked. Notwithstanding the support
requirement, scripts that directly use Environment MUST also include
its capability string in their "required" lists.
2.2. Existing IMAP Functions Affected by IMAPSieve 2.2. Existing IMAP Functions Affected by IMAPSieve
The subsections below describe in detail the IMAP commands and The subsections below describe in detail the IMAP commands and
situations on which IMAPSieve has an effect. Not all Sieve actions situations on which IMAPSieve has an effect. Not all Sieve actions
make sense in the case of messages affected by IMAP commands. See make sense in the case of messages affected by IMAP commands. See
Section 3 for details. 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
[Sieve]) 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 behaviour 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 way In a server that advertises IMAPSieve, new messages added in this way
MUST trigger the execution of a Sieve script, subject to the settings MUST trigger the execution of a Sieve script, subject to the settings
defined through Metadata (see Section 2.3.1). defined through Metadata (see Section 2.3.1).
2.2.2. The IMAP MULTIAPPEND Command 2.2.2. The IMAP MULTIAPPEND Command
If the IMAP server supports the IMAP [MultiAppend] extension, If the IMAP server supports the IMAP MultiAppend extension [RFC3502],
messages may be added to a mailbox through the IMAP MULTIAPPEND messages may be added to a mailbox through the IMAP MULTIAPPEND
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, as with the in this way MUST trigger the execution of a Sieve script, as with the
APPEND command, also subject to the settings defined through APPEND command, also subject to the settings defined through
Metadata. Metadata.
2.2.3. The IMAP COPY Command 2.2.3. 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
skipping to change at page 8, line 27 skipping to change at page 7, line 40
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
Sieve implementation supports the [IMAP4Flags] extension and the Sieve implementation supports the IMAP4Flags extension [RFC5232]
script uses one of the actions defined in that extension. and the script uses one of the actions defined in that extension.
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 was itself invoked because of flag changes SHOULD NOT result in
another script invocation. In any case, implementations MUST take another script invocation. In any case, implementations MUST take
steps to avoid such loops. steps to avoid such loops.
For flag-change events, the Sieve script will see the message flags For flag-change events, the Sieve script will see the message flags
as they are AFTER the changes. 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. New Functions Defined by IMAPSieve
2.3.1. Changes to Metadata 2.3.1. Interaction with Metadata
Support for IMAPSieve requires support for [Metadata] as well, since Support for IMAPSieve requires support for IMAP Metadata [RFC5464] as
the latter is used to associate scripts with IMAP mailboxes. 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 When an applicable event occurs on an IMAP mailbox, if there is an
IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that
entry is used. If there is not, but there is an IMAP metadata entry entry is used. If there is not, but there is an IMAP metadata entry
named "/IMAPSieve/Script" for the server, that entry is used named "/IMAPSieve/Script" for the server, that entry is used
(providing a way to define a global script for all mailboxes on a (providing a way to define a global script for all mailboxes on a
server). If neither entry exists, then no script will be invoked. server). If neither entry exists, then no script will be invoked.
If an "/IMAPSieve/Script" metadata entry was selected above, the If an "/IMAPSieve/Script" metadata entry was selected above, the
shared value of that metadata name (its "value.shared" attribute) shared value of that metadata name (its "value.shared" attribute)
MUST be the name of the Sieve script that will be invoked in response 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 to the IMAP event OR the name of another metadata entry, the name
prefixed with "metadata:" (such as "metadata:/IMAPSieve/ prefixed with "metadata:" (such as "metadata:/IMAPSieve/
ScriptContents"), that contains the actual script in its value.shared ScriptContents"), that contains the actual script in its value.shared
attribute. Note that only the value.shared attribute is used; any attribute. Note that only the value.shared attribute is used; any
value.priv attributes are ignored. value.priv attributes are ignored.
[[COMMENT FROM NED: But the real question is why should we limit
ourselves this way? Why not make the contents of "/IMAPSieve/Script"
a URL? (The metadata: prefix can then be defined as a URL.) If we
want to reach into ManageSieve, use a sieve: URL. (I do see a big
problem with this currently - RFC 5804 appears to have badly botched
the specification of sieve: URLs - the authority field is mandatory
when it shouldn't be, and the owner field is encoded into the URL
path when it should have been extracted from the authority field if
it is present. The way it's done now, you cannot write
sieve:///scriptname and have it mean what it should mean: Select out
of the mailbox owner's scripts. -------- Now, there is no doubt that
allowing URLs creates additional concerns, mostly security related.
But we've dealt with this sort of thing before, e.g., in BURL. All
we have to say is that metadata:foo MUST be implemented and sieve:bar
(modulo some fixes to RFC 5804) SHOULD work if ManageSieve is
available. -------- If this goes too far, then at a minimum I believe
this section needs to be more explicit about how, if ManageSieve is
used, the mapping from script collections in ManageSieve to a mailbox
works.]]
This specifies the mechanism for "activating" a script for a given 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 MAY use creating, storing, or validating the script. Implementations MAY use
[Manage] to acomplish this, using the PUTSCRIPT command to store the ManageSieve [RFC5804] to acomplish this, using the PUTSCRIPT command
script without using the SETACTIVE command to activate it. In any to store the script without using the SETACTIVE command to activate
case, the script name that is specified in the /IMAPSieve/Script it. In any case, the script name that is specified in the
metadata entry is in a form that depends upon how the server handles /IMAPSieve/Script metadata entry is in a form that depends upon how
the storing of Sieve scripts. the server handles the storing of Sieve scripts.
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
coordinating the results of multiple scripts. Any sub-filtering is coordinating the results of multiple scripts. Any sub-filtering is
done in the Sieve script. For example, if it's only necessary to 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, 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 the Sieve script will still be invoked for all events, and the script
is responsible for checking the event type. is responsible for checking the event type.
The possibility is open for an extensions to add support for multiple The possibility is open for an extension to add support for multiple
scripts -- for example, per-client scripts on a multi-client user's 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. inbox, or per-user scripts on a mailbox that is shared among users.
Because this metadata name is associated with the mailbox, there can Because this metadata name is associated with the mailbox, there can
(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 make sense when the messages are created by other not all actions and extensions make sense when the messages are
means or when changes are made to data associated with existing created by other means or when changes are made to data associated
messages. This section describes how actions in the base Sieve with existing messages. This section describes how actions in the
specification, and those in extensions known at this writing, relate base Sieve specification, and those in extensions known at this
to this specification. 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 IMAPSieve, the implicit keep means that 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 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 run. For APPEND, MULTIAPPEND and COPY, the message is stored into
the target mailbox normally. For flag or annotation changes, the the target mailbox normally. For flag changes, the message is left
message is left in the mailbox. 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 3.2. The Keep Action
The keep action is applicable in all cases that fall under IMAPSieve. The keep action is applicable in all cases that fall under IMAPSieve.
Its behaviour is as described for implicit keep, in Section 3.1. Its behaviour is as described for implicit keep, in 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 action
is applicable in all cases that fall under IMAPSieve. If the [Copy] is applicable in all cases that fall under IMAPSieve. If the Copy
extension is available and the :copy option is specified, the extension [RFC3894] is available and the :copy option is specified,
implicit keep is retained; otherwise, fileinto cancels the implicit the implicit keep is retained; otherwise, fileinto cancels the
keep, as specified in the base Sieve specification. implicit keep, as specified in the base Sieve specification.
For APPEND, MULTIAPPEND, and COPY, the message is stored into the For APPEND, MULTIAPPEND, and COPY, the message is stored into the
fileinto mailbox IN ADDITION TO the original target mailbox. For fileinto mailbox IN ADDITION TO the original target mailbox. For
flag or annotation changes, the message is COPIED into the fileinto flag changes, the message is COPIED into the fileinto mailbox,
mailbox, without removing the original. without removing the original.
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 then
marked with the \Deleted flag (and a flag-change Sieve script is NOT marked with the \Deleted flag (and a flag-change Sieve script is NOT
invoked). The implementation MAY then expunge the original message invoked). The implementation MAY then expunge the original message
(WITHOUT expunging other messages in the mailbox), or it MAY choose (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 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 expunge, the effect is as though a client had flagged the message and
done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only.
Handling it this way allows clients to handle messages consistently, Handling it this way allows clients to handle messages consistently,
and avoids hidden changes that might invalidate their message caches. and avoids hidden changes that might invalidate their message caches.
3.4. The Redirect Action 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 The redirect action is applicable in all cases that fall under
IMAPSieve. It causes the message to be sent, as specified in the IMAPSieve. It causes the message to be sent, as specified in the
base Sieve specification, to the designated address. If the [Copy] base Sieve specification, to the designated address. If the Copy
extension is available and the :copy option is specified, the extension [RFC3894] is available and the :copy option is specified,
implicit keep is retained; otherwise, redirect cancels the implicit the implicit keep is retained; otherwise, redirect cancels the
keep, as specified in the base Sieve specification. implicit keep, as specified in the base Sieve specification.
It's possible that a message processed in this way does not have the
information necessary to be redirected properly. It might lack
necessary header information, and there might not be appropriate
information for the MAIL FROM command. In such cases, the "redirect"
action uses Message Submission [RFC4409], and it is up to the Sieve
engine to supply the missing information. The redirect address is,
of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be set
to the address of the owner of the mailbox. The message submission
server is allowed, according to the Message Submission protocol, to
perform necessary fix-up to the message (see section 8 of RFC 4409).
It can also reject the submission attempt, if the message is too ill-
formed for submission.
For APPEND, MULTIAPPEND, and COPY, the message is stored into the For APPEND, MULTIAPPEND, and COPY, the message is stored into the
target mailbox in addition to being redirected. For flag or target mailbox in addition to being redirected. For flag changes,
annotation changes, the message remains in its original mailbox. the message remains 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 then
marked with the \Deleted flag (and a flag-change Sieve script is NOT marked with the \Deleted flag (and a flag-change Sieve script is NOT
invoked). The implementation MAY then expunge the original message invoked). The implementation MAY then expunge the original message
(WITHOUT expunging other messages in the mailbox), or it MAY choose (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 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 expunge, the effect is as though a client had flagged the message and
done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only.
Handling it this way allows clients to handle messages consistently, Handling it this way allows clients to handle messages consistently,
and avoids hidden changes that might invalidate their message caches. and avoids hidden changes that might invalidate their message caches.
3.5. The Reject Action 3.5. The Discard 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 The discard action is applicable in all cases that fall under
IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first IMAPSieve. For APPEND, MULTIAPPEND, and COPY, the message is first
stored into the target mailbox. If an explicit keep action is also stored into the target mailbox. If an explicit keep action is also
in effect, the discard action now does nothing. Otherwise, the in effect, the discard action now does nothing. Otherwise, the
original message is then marked with the \Deleted flag (and a flag- original message is then marked with the \Deleted flag (and a flag-
change Sieve script is NOT invoked). The implementation MAY then change Sieve script is NOT invoked). The implementation MAY then
expunge the original message (WITHOUT expunging other messages in the expunge the original message (WITHOUT expunging other messages in the
mailbox), or it MAY choose to have expunges batched, or done by a 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 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]) client had flagged the message and done a UID EXPUNGE (see [RFC4315])
on the affected message(s) only. Handling it this way allows clients on the affected message(s) only. Handling it this way allows clients
to handle messages consistently, and avoids hidden changes that might to handle messages consistently, and avoids hidden changes that might
invalidate their message caches. invalidate their message caches.
3.7. The Notify Action 3.6. The Notify Action
If the [Notify] extension is available, the notify action is If the Nofity extension [RFC5435] is available, the notify action is
applicable in all cases that fall under IMAPSieve. The result is applicable in all cases that fall under IMAPSieve. The result is
that the requested notification is sent, and that the message is that the requested notification is sent, and that the message is
otherwise handled as it would normally have been. otherwise handled as it would normally have been.
3.8. The Addheader and Deleteheader Actions 3.7. The Addheader and Deleteheader Actions
[[anchor5: Should editheader be allowed to change header fields that
aren't saved in place, such as for redirect or fileinto? Editheader
would still have to be banned for "keep", but not otherwise.]]
Even if the [EditHeader] extension is available, since messages in If the EditHeader extension [RFC5293] is available, it can be used to
IMAP mailboxes are immutable these actions are NOT applicable. Use make transient changes to header fields, which aren't saved in place,
of these MUST result in an error condition that will terminate the such as for "redirect" or "fileinto" actions. Because messages in
Sieve script. Explanation: Using them for flag or annotation changes IMAP mailboxes are immutable, such changes are NOT applicable for the
to existing messages would cause the message to be changed. Using "keep" acton (explicit or implicit). See Section 3.1.
them 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. The Setflag, Deleteflag, and Removeflag Actions 3.8. The Setflag, Deleteflag, and Removeflag Actions
[[anchor6: Should this just require imap4flags? Some implementors Implementations of the IMAPSieve extension MUST also support the
have said they wouldn't bother with it without the ability to IMAP4Flags extension [RFC5232], and the actions associated with it
manipulate flags. And what values of flags does it see -- before or are all applicable to any case that falls under IMAPSieve.
after the change? If it changes them, can it see the originals? Can
it reset changes?]]
If the [IMAP4Flags] extension is available, 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 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.10. The Vacation Action 3.9. MIME Part Tests and Replacement
Even if the [Vacation] extension is available, the vacation action is If the MIME Part Tests extension [RFC5703] is available, all of its
NOT applicable to any case that falls under IMAPSieve. Its use MUST functions can be used, but any changes made to the message, using the
result in an error condition that will terminate the Sieve script. "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.11. Spamtest 3.10. Spamtest and Virustest
[Spamtest] [[anchor7: We need to say something about the spamtest/ If the Spamtest and Virustest extensions [RFC5235] are available,
virustest extension. We need to be able to scan appended messages. they are applicable in all cases that fall under IMAPSieve.
And we can't use headers to communicate spam status, because the
message is immutable. What should we say here?]]
3.12. New Sieve Environment Item: cause 3.11. Inapplicable Actions
The following actions and extensions are NOT applicable to any case
that falls under IMAPSieve. Their use or their appearance in the
"require" control MUST result in an error condition that will
terminate the Sieve script:
reject [RFC5228]
ereject [RFC5429]
vacation [RFC5230]
4. New Sieve Environment Items
4.1. New Sieve Environment Items: imapuser and imapemail
In the normal case, when Sieve is used in final delivery, there is no
identity for the "filer" -- the user who is creating or changing the
message. In this case, there is such an identity, and a Sieve script
might want to access that identity.
Implementations MUST set and make available two new environment
items:
"imapuser" -- the identity (login ID) of the IMAP user that caused
the action. This MUST be the empty string if it is accessed during
normal (final delivery) Sieve processing.
"imapemail" -- the primary email address of the IMAP user that caused
the action (the user identified by "imapuser"). In some
implementations, "imapuser" and "imapemail" might have the same
value. This MUST be the empty string if it is accessed during normal
(final delivery) Sieve processing.
4.2. New Sieve Environment Item: cause
Implementations MAY invoke different Sieve scripts for the different Implementations MAY invoke different Sieve scripts for the different
conditions described in this document (append, copy, flag changes, conditions described in this document (append, copy, flag changes).
annotation changes). If the actions to be taken are common, and the If the actions to be taken are common, and the implementation
implementation supports the [Include] extension, the common script supports the Include extension [I-D.ietf-sieve-include], the common
code can be included as specified there. script code can be included as specified there.
It may be preferable, though, to use a single script for all these Each mailbox uses a single script for all the change conditions
conditions. To support that, the implementation MUST set the described in this document (append, copy, flag changes). To support
[Environment] item "cause", which contains the name of the action that, the implementation MUST set the Environment [RFC5183] item
that caused the script to be invoked. Its value is one of the "cause", which contains the name of the action that caused the script
following: to be invoked. Its value is one of the following:
o APPEND (for invocations resulting from APPEND or MULTIAPPEND) o APPEND (for invocations resulting from APPEND or MULTIAPPEND)
o COPY (for invocations resulting from COPY) o COPY (for invocations resulting from COPY)
o FLAG (for invocations resulting from flag changes) o FLAG (for invocations resulting from flag changes)
o ANNOTATE (for invocations resulting from new or changed 4.3. New Sieve Environment Item: mailbox
annotations)
3.13. New Sieve Environment Item: mailbox
The implementation MUST set the [Environment] item "mailbox" to the The implementation MUST set the Environment [RFC5183] item "mailbox"
name of the mailbox that the affected message is in, in the case of to the name of the mailbox that the affected message is in, in the
existing messages, or is targeted to be stored into, in the case of case of existing messages, or is targeted to be stored into, in the
new messages. The value of this item is fixed when the script case of new messages. The value of this item is fixed when the
begins, and, in particular, MUST NOT change as a result of any script begins, and, in particular, MUST NOT change as a result of any
action, such as "fileinto". action, such as "fileinto".
3.14. New Sieve Environment Item: changedflags 4.4. New Sieve Environment Item: changedflags
If the [IMAP4Flags] extension is available, AND the script was If the IMAP4Flags extension [RFC5232] is available, AND the script
invoked because of flag changes to an existing message, the was invoked because of flag changes to an existing message, the
implementation MUST set the [Environment] item "changedflags" to the implementation MUST set the Environment [RFC5183] item "changedflags"
name(s) of the flag(s) that have changed. If the script was not to the name(s) of the flag(s) that have changed. If the script was
invoked because of flag changes, the value of this item MUST be the not invoked because of flag changes, the value of this item MUST be
empty string. The script will not know from this item whether the the empty string. The script will not know from this item whether
flags have been set or reset, but it can use the "hasflag" test to the flags have been set or reset, but it can use the "hasflag" test
determine the current value. See example 2 in Section 4 for an to determine the current value. See example 2 in Section 5 for an
example of how this might be used. example of how this might be used.
3.15. New Sieve Environment Item: changedannotations 4.5. Interaction With Sieve Tests (Comparisons)
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. Interaction With Sieve Tests (Comparisons)
This extension does not affect the operation of any tests or This extension does not affect the operation of tests or comparisons
comparisons. in the Sieve base specification.
4. Examples 5. Examples
Example 1: Example 1:
If a new message is added to the "ActionItems" mailbox, a copy is If a new message is added to the "ActionItems" mailbox, a copy is
sent to the address "actionitems@example.com". sent to the address "actionitems@example.com".
require ["copy", "environment"]; require ["copy", "environment"];
if anyof (environment :is "cause" "APPEND", if anyof (environment :is "cause" "APPEND",
environment :is "cause" "COPY") { environment :is "cause" "COPY") {
if environment :is "mailbox" "ActionItems" { if environment :is "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), a notification is sent (tested through the IMAP4Flags extension [RFC5232]), a notification
using the [Notify] extension. No notification will be sent, though, is sent using the Notify extension [RFC5435]. No notification will
if we're called with an existing message that already had that flag be sent, though, if we're called with an existing message that
set. already had that flag set.
require ["notify", "imap4flags", "variables", "environment"]; require ["enotify", "imap4flags", "variables", "environment"];
if environment :matches "mailbox" "*" { if environment :matches "mailbox" "*" {
set "mailbox" "${1}"; set "mailbox" "${1}";
} }
if allof (hasflag "\\Flagged", if allof (hasflag "\\Flagged",
not environment :contains "changedflags" "\\Flagged") { not environment :contains "changedflags" "\\Flagged") {
notify :message "Important message in ${mailbox}"; notify :message "Important message in ${mailbox}"
"xmpp:tim@example.com?message;subject=SIEVE";
} }
5. 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. Implementations MUST take steps to the IMAP4Flags extension [RFC5232]. Implementations MUST take steps
prevent such loops. One way to avoid this problem is that if a 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 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.
Other security considerations are discussed in [IMAP], and [Sieve], It is also possible to introduce loops through the "redirect" or
as well as in some of the other extension documents. "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.
6. IANA Considerations Other security considerations are discussed in IMAP [RFC3501], and
Sieve [RFC5228], as well as in some of the other extension documents.
6.1. Registration of imapsieve extension 7. IANA Considerations
7.1. Registration of IMAPSIEVE IMAP capability
This document defines a new IMAP capability. IANA is asked to add
"IMAPSIEVE" to the IMAP 4 Capabilities registry.
7.2. Registration of imapsieve Sieve extension
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
extension specified in this document: extension specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension 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: this RFC
Contact address: Barry Leiba <barryleiba@computer.org> Contact address: Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve extensions This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
6.2. Registration of environment item: cause 7.3. Registration of environment item: cause
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: cause Item name: 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 or MULTIAPPEND) o APPEND (for invocations resulting from APPEND or MULTIAPPEND)
o COPY (for invocations resulting from COPY) o COPY (for invocations resulting from COPY)
o FLAG (for invocations resulting from flag changes) o FLAG (for invocations resulting from flag changes)
o ANNOTATE (for invocations resulting from new or changed
annotations)
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <barryleiba@computer.org> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the Environment extension [RFC5183].
6.3. Registration of environment item: mailbox 7.4. Registration of environment item: mailbox
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: mailbox Item name: 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 into,
in the case of new messages. The value of this item is fixed when 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 the script begins, and, in particular, MUST NOT change as a result of
any action, such as "fileinto". any action, such as "fileinto".
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <barryleiba@computer.org> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the Environment extension [RFC5183].
6.4. Registration of environment item: changedflags 7.5. Registration of environment item: changedflags
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: changedflags Item name: 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 have
changed. Otherwise, the value of this item MUST be the empty string. changed. Otherwise, the value of this item MUST be the empty string.
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <barryleiba@computer.org> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the Environment extension [RFC5183].
6.5. Registration of environment item: changedannotations 7.6. Registration of environment item: imapuser
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: changedannotations Item name: imapuser
Description: If the script was invoked because of annotation changes Description: The identity (IMAP login ID) of the IMAP user that
to an existing message, this contains the name(s) of the caused the action.
annotation(s) that have changed. Otherwise, the value of this item
MUST be the empty string.
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <barryleiba@computer.org> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the Environment extension [RFC5183].
6.6. Registration of IMAP METADATA mailbox entry name 7.7. Registration of environment item: imapemail
The following template specifies the IANA registration of a sieve
environment item specified in this document:
To: iana@iana.org
Subject: Registration of new Sieve environment item
Item name: imapemail
Description: The primary email address of the IMAP user that caused
the action (the user identified by "imapuser").
RFC number: this RFC
Contact address:
Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment
item names given in the Environment extension [RFC5183].
7.8. Registration of IMAP METADATA mailbox entry name
The following template specifies the IANA registration of an IMAP The following template specifies the IANA registration of an IMAP
METADATA entry name specified in this document: METADATA entry name specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: IMAP METADATA Registration Subject: IMAP METADATA Registration
Please register the following IMAP METADATA item: Please register the following IMAP METADATA item:
[x] Entry [ ] Attribute [x] Entry [ ] Attribute
[x] Mailbox [ ] Server [x] Mailbox [ ] Server
Name: /IMAPSieve/Script Name: /IMAPSieve/Script
Description: This entry name is used to define mailbox metadata Description: This entry name is used to define mailbox metadata
associated with IMAPSieve events for the associated mailbox. associated with IMAPSieve events 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: this RFC
Contact person: Barry Leiba Contact person: Barry Leiba
Contact email: barryleiba@computer.org Contact email: barryleiba@computer.org
This information should be added to the list of IMAP METADATA item This information should be added to the list of IMAP METADATA item
names given in the [Metadata] extension. names given in the Metadata extension [RFC5464].
6.7. Registration of IMAP METADATA server entry name 7.9. Registration of IMAP METADATA server entry name
The following template specifies the IANA registration of an IMAP The following template specifies the IANA registration of an IMAP
METADATA entry name specified in this document: METADATA entry name specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: IMAP METADATA Registration Subject: IMAP METADATA Registration
Please register the following IMAP METADATA item: Please register the following IMAP METADATA item:
[x] Entry [ ] Attribute [x] Entry [ ] Attribute
[ ] Mailbox [x] Server [ ] Mailbox [x] Server
Name: /IMAPSieve/Script Name: /IMAPSieve/Script
skipping to change at page 21, line 4 skipping to change at page 21, line 27
globally with IMAPSieve events for the associated server. globally with IMAPSieve events 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 /IMAPSieve/Script entry. have its own mailbox-level /IMAPSieve/Script entry.
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
RFC number: this RFC RFC number: this RFC
Contact person: Barry Leiba Contact person: Barry Leiba
Contact email: barryleiba@computer.org Contact email: barryleiba@computer.org
This information should be added to the list of IMAP METADATA item This information should be added to the list of IMAP METADATA item
names given in the [Metadata] extension. names given in the Metadata extension [RFC5464].
7. References 8. References
7.1. Normative References 8.1. Normative References
[Annotate] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 5257, June 2008.
[Copy] Degener, J., "Sieve Extension: Copying Without Side [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003.
[RFC3894] Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, October 2004. Effects", RFC 3894, October 2004.
[Environment] [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
Freed, N., "Sieve Email Filtering: Environment Extension", RFC 4409, April 2006.
[RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension",
RFC 5183, May 2008. RFC 5183, May 2008.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
4rev1", RFC 3501, March 2003. Language", RFC 5228, January 2008.
[IMAP4Flags] [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags
Melnikov, A., "Sieve Mail Filtering Language: IMAP flag
Extension", RFC 5232, January 2008. Extension", RFC 5232, January 2008.
[Keywds] Bradner, S., "Key words for use in RFCs to Indicate [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
Requirement Levels", RFC 2119, March 1997.
[Metadata]
Daboo, C., "The IMAP METADATA Extension", RFC 5464,
February 2009. February 2009.
[MultiAppend] 8.2. Non-Normative References
Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003.
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email [I-D.ietf-sieve-include]
Filtering Language", RFC 5228, January 2008. Daboo, C. and A. Stone, "Sieve Email Filtering: Include
Extension", draft-ietf-sieve-include-06 (work in
progress), July 2010.
7.2. Non-Normative References [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[EditHeader] [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
Degener, J. and P. Guenther, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
Editheader Extension", RFC 5293, August 2008.
[Include] Daboo, C. and A. Stone, "SIEVE Email Filtering: Include [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extension", work in progress, http://tools.ietf.org/html/ Extensions", RFC 5235, January 2008.
draft-ietf-sieve-include, July 2009.
[Manage] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering:
Managing Sieve Scripts", RFC editor queue, http://
tools.ietf.org/html/draft-ietf-sieve-managesieve,
January 2009.
[Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Editheader Extension", RFC 5293, August 2008.
Martin, "Sieve Email Filtering: Extension for
Notifications", RFC 5435, January 2009.
[Spamtest] [RFC5429] Stone, A., "Sieve Email Filtering: Reject and Extended
Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Reject Extensions", RFC 5429, March 2009.
Extensions", RFC 5235, January 2008.
[UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
UIDPLUS Extension", RFC 4315, December 2005. "Sieve Email Filtering: Extension for Notifications",
RFC 5435, January 2009.
[Vacation] [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Tests, Iteration, Extraction, Replacement, and Enclosure",
Vacation Extension", RFC 5230, January 2008. RFC 5703, October 2009.
[RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, July 2010.
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. 99 change blocks. 
290 lines changed or deleted 346 lines changed or added

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