draft-ietf-sieve-imap-sieve-08.txt   draft-ietf-sieve-imap-sieve-09.txt 
Sieve Working Group B. Leiba Sieve Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Updates: 5228 (if approved) September 10, 2012 Updates: 5228 (if approved) September 14, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: March 14, 2013 Expires: March 18, 2013
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-08 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 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). Because this requires future Sieve features such as notifications). Because this requires future Sieve
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 14, 2013. This Internet-Draft will expire on March 18, 2013.
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . 6 2. The IMAP Events in Sieve Extension . . . . . . . . . . . . 6
2.1. The "imapsieve" Capability Strings . . . . . . . . . . . . 6 2.1. The "imapsieve" Capability Strings . . . . . . . . . . . . 6
2.2. Existing IMAP Functions Affected by IMAP events in 2.2. Existing IMAP Functions Affected by IMAP events in
Sieve . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Sieve . . . . . . . . . . . . . . . . . . . . . . . . . . 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 COPY Command . . . . . . . . . . . . . . . . . . 7
2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7 2.2.3. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7
2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7 2.2.4. When Script Actions Set the \Deleted Flag . . . . . . . . 8
2.3. New Functions Defined by IMAP events in Sieve . . . . . . 8 2.3. New Functions Defined by IMAP events in Sieve . . . . . . 8
2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8 2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8
3. Applicable Sieve Actions and Interactions . . . . . . . . 10 3. Applicable Sieve Actions and Interactions . . . . . . . . 10
3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10
3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10
3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10
3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11
3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11 3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11
3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 12 3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 11
3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12 3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12
3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12
3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12 3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12
3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 13 3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 12
3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 13 3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 12
3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 13 3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 13
4. Interaction With Sieve Environment . . . . . . . . . . . . 14 4. Interaction With Sieve Environment . . . . . . . . . . . . 14
4.1. Base Sieve Environment Items: location and phase . . . . . 14 4.1. Base Sieve Environment Items: location and phase . . . . . 14
4.2. New Sieve Environment Items: imapuser and imapemail . . . 14 4.2. New Sieve Environment Items: imap.user and imap.email . . 14
4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 14 4.3. New Sieve Environment Item: imap.cause . . . . . . . . . . 14
4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 15 4.4. New Sieve Environment Item: imap.mailbox . . . . . . . . . 15
4.5. New Sieve Environment Item: changedflags . . . . . . . . . 15 4.5. New Sieve Environment Item: imap.changedflags . . . . . . 15
4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15 4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Registration of "imapsieve" IMAP capability . . . . . . . 18 7.1. Registration of "imapsieve" IMAP capability . . . . . . . 18
7.2. Registration of "imapsieve" Sieve extension . . . . . . . 18 7.2. Registration of "imapsieve" Sieve extension . . . . . . . 18
7.3. Registration of Sieve Environment Items . . . . . . . . . 18 7.3. Registration of Sieve Environment Items . . . . . . . . . 18
7.3.1. Registration of Sieve Environment Item: cause . . . . . . 18 7.3.1. Registration of Sieve Environment Item: imap.cause . . . . 18
7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 19 7.3.2. Registration of Sieve Environment Item: imap.mailbox . . . 19
7.3.3. Registration of Sieve Environment Item: changedflags . . . 19 7.3.3. Registration of Sieve Environment Item:
7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 19 imap.changedflags . . . . . . . . . . . . . . . . . . . . 19
7.3.5. Registration of Sieve Environment Item: imapemail . . . . 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.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 19
7.5. Registration of IMAP METADATA Server Entry Name . . . . . 20 7.5. Registration of IMAP METADATA Server Entry Name . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
skipping to change at page 4, line 22 skipping to change at page 4, line 22
sporadically connected, is connected through a high-latency or high- sporadically connected, is connected through a high-latency or high-
cost channel, or is on a limited-function device. For such clients, cost channel, or is on a limited-function device. For such clients,
it may be very important, for higher performance and reliability, to it may be very important, for higher performance and reliability, to
take advantage of server capabilities, including those provided by take advantage of server capabilities, including those provided by
Sieve filtering (and Sieve extensions, such as Notify [RFC5435]). 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 requires support for IMAP Metadata [RFC5464] and Sieve Sieve also requires support for the following:
Environment [RFC5183] as well, because Metadata is used to associate
scripts with IMAP mailboxes and Environment defines an important way o IMAP Metadata [RFC5464], because Metadata is used to associate
for Sieve scripts to test the conditions under which they have been scripts with IMAP mailboxes.
invoked.
o Sieve Environment [RFC5183], because it defines an important way
for Sieve scripts to test the conditions under which they have
been invoked.
o Sieve IMAP4Flags [RFC5232], because it provides important
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, which changes the applicability of Sieve
features and creates implementation challenges and user interface features and creates implementation challenges and user interface
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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).
2.2.2. The IMAP MULTIAPPEND Command If the IMAP server also supports the IMAP MultiAppend extension
[RFC3502], the APPEND command can create more than one message at a
If the IMAP server supports the IMAP MultiAppend extension [RFC3502], time. In that case, each message creation is considered a separate
messages may be added to a mailbox through the IMAP MULTIAPPEND event, and any applicable Sieve script is called once for each
command. In a server that advertises "imapsieve", new messages added message.
in this way MUST trigger the execution of a Sieve script, as with the
APPEND command, also subject to the settings defined through
Metadata.
2.2.3. The IMAP COPY Command 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
the settings defined through Metadata. the settings defined through Metadata.
2.2.4. Changes to IMAP Message Flags 2.2.3. Changes to IMAP Message Flags
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 [RFC5232] script uses one of the actions defined in the IMAP4Flags extension
and the script uses one of the actions defined in that extension. [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.
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.4. When Script Actions Set the \Deleted Flag
There are times when the actions "fileinto" (see Section 3.3),
"redirect" (see Section 3.4), and "discard" (see Section 3.5) will
set the \Deleted flag on the message. In those cases, the following
apply:
When the \Deleted flag is set by the script, a flag-change Sieve
script is not invoked.
The implementation MAY then expunge the original message (WITHOUT
expunging other messages in the mailbox). Alternatively, it might
have expunges batched or done by a user. (It might be helpful to
allow the user to make this choice through a preference.)
If the server does the expunge, the effect is as though a client had
flagged the message and done a UID EXPUNGE (see [RFC4315]) on the
affected message(s) only. Handling it this way allows clients to
handle messages consistently, and avoids hidden changes that might
invalidate their message caches.
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,
skipping to change at page 10, line 21 skipping to change at page 10, line 21
base Sieve specification, and those in extensions known at this base Sieve specification, and those in extensions known at this
writing, relate 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 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, MULTIAPPEND and COPY, the message is script were run. For APPEND and COPY, the message is stored into the
stored into the target mailbox normally. For flag changes, the target mailbox normally. For flag changes, the message is left in
message is left in the mailbox. If actions have been taken that the mailbox. If actions have been taken that change the message,
change the message, those changes are considered transient and MUST those changes are considered transient and MUST NOT be retained for
NOT be retained for any keep action (because IMAP messages are any keep action (because IMAP messages are immutable). No error is
immutable). No error is generated, but the original message, without generated, but the original message, without the changes, is kept.
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 behaviour 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 action
is applicable in all cases that fall under IMAP events in Sieve. If is applicable in all cases that fall under IMAP events in Sieve. If
the Copy extension [RFC3894] is available and the :copy option is the Copy extension [RFC3894] is available and the :copy option is
specified, the implicit keep is retained; otherwise, fileinto cancels specified, the implicit keep is retained; otherwise, fileinto cancels
the implicit keep, as specified in the base Sieve specification. the implicit keep, as specified in the base Sieve specification.
For APPEND, MULTIAPPEND, and COPY, the message is stored into the For APPEND and COPY, the message is stored into the fileinto mailbox
fileinto mailbox IN ADDITION TO the original target mailbox. For IN ADDITION TO the original target mailbox. For flag changes, the
flag changes, the message is COPIED into the fileinto mailbox, message is COPIED into the fileinto mailbox, without removing the
without removing the original. In all cases, fileinto always creates original. In all cases, fileinto always creates a new message,
a new message, separate from the original. separate from the original.
The fileinto action is not an IMAP APPEND or COPY, and therefore does
not result in a subsequent event (see also the Security
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 then
marked with the \Deleted flag (and a flag-change Sieve script is not marked with the \Deleted flag (see Section 2.2.4).
invoked). The implementation MAY then expunge the original message
(WITHOUT expunging other messages in the mailbox); alternatively, it
might choose to have expunges batched or done by a user. If the
server does the expunge, the effect is as though a client had flagged
the message and done a UID EXPUNGE (see [RFC4315]) on the affected
message(s) only. Handling it this way allows clients to handle
messages consistently, and avoids hidden changes that might
invalidate their message caches.
3.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 Copy
extension [RFC3894] is available and the :copy option is specified, extension [RFC3894] is available and the :copy option is specified,
the implicit keep is retained; otherwise, redirect cancels the the implicit keep is retained; otherwise, redirect cancels the
implicit keep, as specified in the base Sieve specification. implicit keep, as specified in the base Sieve specification.
skipping to change at page 11, line 33 skipping to change at page 11, line 28
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 ill-
formed for submission. formed for submission.
For APPEND, MULTIAPPEND, and COPY, the message is stored into the For APPEND and COPY, the message is stored into the target mailbox in
target mailbox in addition to being redirected. For flag changes, addition to being redirected. For flag changes, the message remains
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 then
marked with the \Deleted flag (and a flag-change Sieve script is not marked with the \Deleted flag (see Section 2.2.4).
invoked). The implementation MAY then expunge the original message
(WITHOUT expunging other messages in the mailbox); alternatively, it
might choose to have expunges batched or done by a user. If the
server does the expunge, the effect is as though a client had flagged
the message and done a UID EXPUNGE (see [RFC4315]) on the affected
message(s) only. Handling it this way allows clients to handle
messages consistently, and avoids hidden changes that might
invalidate their message caches.
3.5. The Discard Action 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, MULTIAPPEND, and COPY, the message is events in Sieve. For APPEND and COPY, the message is first stored
first stored into the target mailbox. If an explicit keep action is into the target mailbox. If an explicit keep action is also in
also in effect, the discard action now does nothing. Otherwise, the effect, the discard action now does nothing. Otherwise, the original
original message is then marked with the \Deleted flag (and a flag- message is then marked with the \Deleted flag (see Section 2.2.4).
change Sieve script is not invoked). The implementation MAY then
expunge the original message (WITHOUT expunging other messages in the
mailbox); alternatively, it might choose to have expunges batched or
done by a user. If the server does the expunge, the effect is as
though a client had flagged the message and done a UID EXPUNGE (see
[RFC4315]) on the affected message(s) only. Handling it this way
allows clients to handle messages consistently, and avoids hidden
changes that might invalidate their message caches.
3.6. The Notify Action 3.6. The Notify Action
If the Nofity extension [RFC5435] is available, the notify action is If the Nofity extension [RFC5435] is available, the notify action is
applicable in all cases that fall under IMAP events in Sieve. The applicable in all cases that fall under IMAP events in Sieve. The
result is that the requested notification is sent, and that the result is that the requested notification is sent, and that the
message is otherwise handled as it would normally have been. message is otherwise handled as it would normally have been.
3.7. The Addheader and Deleteheader Actions 3.7. The Addheader and Deleteheader Actions
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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.
The value of "phase" is set to "post" -- processing is taking place The value of "phase" is set to "post" -- processing is taking place
after (or perhaps instead of, in the case of APPEND) final delivery. after (or perhaps instead of, in the case of APPEND) final delivery.
4.2. New Sieve Environment Items: imapuser and imapemail 4.2. New Sieve Environment Items: imap.user and imap.email
In the normal case, when Sieve is used in final delivery, there is no 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 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 message. In this case, there is such an identity, and a Sieve script
might want to access that identity. might want to access that identity.
Implementations MUST set and make available two new environment Implementations MUST set and make available two new environment
items: items:
"imapuser" -- the identity (login ID) of the IMAP user that caused "imap.user" -- the identity (login ID) of the IMAP user that caused
the action. This MUST be the empty string if it is accessed during the action. This MUST be the empty string if it is accessed during
normal (final delivery) Sieve processing. normal (final delivery) Sieve processing.
"imapemail" -- the primary email address of the IMAP user that caused "imap.email" -- the primary email address of the IMAP user that
the action (the user identified by "imapuser"). In some caused the action (the user identified by "imap.user"). In some
implementations, "imapuser" and "imapemail" might have the same implementations, "imap.user" and "imap.email" might have the same
value. This MUST be the empty string if it is accessed during normal value. This MUST be the empty string if it is accessed during normal
(final delivery) Sieve processing. (final delivery) Sieve processing.
4.3. New Sieve Environment Item: cause 4.3. New Sieve Environment Item: imap.cause
Each mailbox uses a single script for all the change conditions Each mailbox uses a single script for all the change conditions
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
"cause", which contains the name of the action that caused the script "imap.cause", which contains the name of the action that caused the
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 or MULTIAPPEND) o APPEND (for invocations resulting from APPEND commands)
o COPY (for invocations resulting from COPY) 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: mailbox 4.4. New Sieve Environment Item: imap.mailbox
The implementation MUST set the Environment [RFC5183] item "mailbox" The implementation MUST set the Environment [RFC5183] item
to the name of the mailbox that the affected message is in, in the "imap.mailbox" to the name of the mailbox that the affected message
case of existing messages, or is targeted to be stored into, in the is in, in the case of existing messages, or is targeted to be stored
case of new messages. The value of this item is fixed when the into, in the case of new messages. The value of this item is fixed
script begins, and, in particular, MUST NOT change as a result of any when the script begins, and, in particular, MUST NOT change as a
action, such as "fileinto". result of any action, such as "fileinto".
4.5. New Sieve Environment Item: changedflags 4.5. New Sieve Environment Item: imap.changedflags
If the IMAP4Flags extension [RFC5232] is available, AND the script If the script was invoked because of flag changes to an existing
was invoked because of flag changes to an existing message, the message, the implementation MUST set the Environment [RFC5183] item
implementation MUST set the Environment [RFC5183] item "changedflags" "imap.changedflags" to the name(s) of the flag(s) that have changed.
to the name(s) of the flag(s) that have changed. If the script was If the script was not invoked because of flag changes, the value of
not invoked because of flag changes, the value of this item MUST be this item MUST be the empty string. The script will not know from
the empty string. The script will not know from this item whether this item whether the flags have been set or reset, but it can use
the flags have been set or reset, but it can use the "hasflag" test the "hasflag" test to determine the current value. See example 2 in
to determine the current value. See example 2 in Section 5 for an Section 5 for an example of how this might be used.
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.
skipping to change at page 16, line 13 skipping to change at page 16, line 13
comparisons in the Sieve base specification. comparisons in the Sieve base specification.
5. 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", "imapsieve"]; require ["copy", "environment", "imapsieve"];
if anyof (environment :is "cause" "APPEND", if anyof (environment :is "imap.cause" "APPEND",
environment :is "cause" "COPY") { environment :is "imap.cause" "COPY") {
if environment :is "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]), a notification (tested through the IMAP4Flags extension [RFC5232]) AND this script
is sent using the Notify extension [RFC5435]. No notification will invocation represents a change to that flag, then a notification is
be sent, though, if we're called with an existing message that sent using the Notify extension [RFC5435]. No notification will be
already had that flag set. sent, though, if we're called with an existing message that already
had that flag set.
require ["enotify", "imap4flags", "variables", require ["enotify", "imap4flags", "variables",
"environment", "imapsieve"]; "environment", "imapsieve"];
if environment :matches "mailbox" "*" { if environment :matches "imap.mailbox" "*" {
set "mailbox" "${1}"; set "mailbox" "${1}";
} }
if allof (hasflag "\\Flagged", if allof (hasflag "\\Flagged",
not environment :contains "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 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 such 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
an implementation did invoke a script as the result of a fileinto, 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",
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
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 Section 10 of Sieve [RFC5228], Section 8 of
Sieve Notify [RFC5435], and the Security Considerations sections of Sieve Notify [RFC5435], and the Security Considerations sections of
the applicable notification-method documents for loop-prevention the 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
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.
In particular, certain actions, such as redirect, can cause a message
(such as a message appended to a mailbox by a user) to be sent to the
Internet in response to something as simple as a flag change. For
example, a script might cause messages marked for deletion to be sent
to some off-site archiving service. If a user appends a draft
message to a mailbox (perhaps an unencrypted draft message) and then
marks it for deletion, it might be very surprising to the user that
the message is sent off site. Script authors need to be careful not
to create these kinds of surprises, especially when 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 is asked to add "IMAPSIEVE=" to the IMAP 4 Capabilities
registry, according to the IMAP 4 specification [RFC3501]. registry, according to the IMAP 4 specification [RFC3501].
(http://www.iana.org/assignments/imap4-capabilities) (http://www.iana.org/assignments/imap4-capabilities)
skipping to change at page 18, line 33 skipping to change at page 18, line 33
RFC number: [[this RFC]] RFC number: [[this RFC]]
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, according to the Environment extension [RFC5183].
(http://www.iana.org/assignments/sieve-environment-items/ sieve- (http://www.iana.org/assignments/sieve-environment-items/ sieve-
environment-items.xml) environment-items.xml)
7.3.1. Registration of Sieve Environment Item: cause 7.3.1. Registration of Sieve Environment Item: imap.cause
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: 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 or MULTIAPPEND) o APPEND (for invocations resulting from APPEND commands)
o COPY (for invocations resulting from COPY) 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: [[this RFC]]
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.2. Registration of Sieve Environment Item: mailbox 7.3.2. Registration of Sieve Environment Item: imap.mailbox
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: 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 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: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.3. Registration of Sieve Environment Item: changedflags 7.3.3. Registration of Sieve Environment Item: imap.changedflags
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: 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 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: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.4. Registration of Sieve Environment Item: imapuser 7.3.4. Registration of Sieve Environment Item: imap.user
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: imapuser 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: [[this RFC]]
Contact address: Sieve mailing list <sieve@ietf.org> Contact address: Sieve mailing list <sieve@ietf.org>
7.3.5. Registration of Sieve Environment Item: imapemail 7.3.5. Registration of Sieve Environment Item: imap.email
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: imapemail 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 caused
the action (the user identified by "imapuser"). the action (the user identified by "imap.user").
RFC number: [[this RFC]] RFC number: [[this RFC]]
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 should be added to the IMAP METADATA
Mailbox Entry Registry, according to the Metadata extension Mailbox Entry Registry, according to the Metadata extension
[RFC5464]. [RFC5464].
(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml) (http://www.iana.org/assignments/imap-metadata/imap-metadata.xml)
 End of changes. 52 change blocks. 
131 lines changed or deleted 157 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/