< draft-ietf-sieve-imap-sieve-06.txt   draft-ietf-sieve-imap-sieve-07.txt >
Sieve Working Group B. Leiba Sieve Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track July 14, 2012 Updates: 5228 (if approved) September 10, 2012
Expires: January 15, 2013 Intended status: Standards Track
Expires: March 14, 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-06 draft-ietf-sieve-imap-sieve-07
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). Because this requires future Sieve
extensions to specify their interactions with this one, this document
updates the base Sieve specification, RFC 5228.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 15, 2013. This Internet-Draft will expire on March 14, 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 30 skipping to change at page 2, line 33
2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7
2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . 12
3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 12 3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 13
3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12 3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 13
3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13
3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12 3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 13
3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 13 3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 14
3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 13 3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 14
3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 14
4. Interaction With Sieve Environment . . . . . . . . . . . . 14
4.1. Base Sieve Environment Items: location and phase . . . . . 14
4.2. New Sieve Environment Items: imapuser and imapemail . . . 14
4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 14
4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 15
4.5. New Sieve Environment Item: changedflags . . . . . . . . . 15
4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Interaction With Sieve Environment . . . . . . . . . . . . 15
4.1. Base Sieve Environment Items: location and phase . . . . . 15
4.2. New Sieve Environment Items: imapuser and imapemail . . . 15
4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 15
4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 16
4.5. New Sieve Environment Item: changedflags . . . . . . . . . 16
4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . 17 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Registration of "imapsieve" IMAP capability . . . . . . . 18 7.1. Registration of "imapsieve" IMAP capability . . . . . . . 19
7.2. Registration of "imapsieve" Sieve extension . . . . . . . 18 7.2. Registration of "imapsieve" Sieve extension . . . . . . . 19
7.3. Registration of Sieve Environment Items . . . . . . . . . 18 7.3. Registration of Sieve Environment Items . . . . . . . . . 19
7.3.1. Registration of Sieve Environment Item: cause . . . . . . 18 7.3.1. Registration of Sieve Environment Item: cause . . . . . . 19
7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 19 7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 20
7.3.3. Registration of Sieve Environment Item: changedflags . . . 19 7.3.3. Registration of Sieve Environment Item: changedflags . . . 20
7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 19 7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 20
7.3.5. Registration of Sieve Environment Item: imapemail . . . . 19 7.3.5. Registration of Sieve Environment Item: imapemail . . . . 20
7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 19 7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 20
7.5. Registration of IMAP METADATA Server Entry Name . . . . . 20 7.5. Registration of IMAP METADATA Server Entry Name . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
Some applications have a need to apply Sieve filters [RFC5228] in Some applications have a need to apply Sieve filters [RFC5228] in
contexts other than initial mail delivery. This is especially true contexts other than initial mail delivery. This is especially true
in diverse service environments, such as when the client is in diverse service environments, such as when the client is
sporadically connected, is connected through a high-latency or high- sporadically connected, is connected through a high-latency or 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,
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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 requires support for IMAP Metadata [RFC5464] and Sieve
Environment [RFC5183] as well, because Metadata is used to associate Environment [RFC5183] as well, because Metadata is used to associate
scripts with IMAP mailboxes and Environment defines an important way scripts with IMAP mailboxes and Environment defines an important way
for Sieve scripts to test the conditions under which they have been for Sieve scripts to test the conditions under which they have been
invoked. invoked.
Because this requires future Sieve extensions to specify their
interactions with this one (see Section 3.12), this document updates
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
issues. This section discusses some of those differences, issues. This section discusses some of those differences,
challenges, and issues. challenges, and issues.
At times other than message delivery, delivery "envelope" information At times other than message delivery, delivery "envelope" information
might not be available. With messages added through IMAP APPEND, might not be available. With messages added through IMAP APPEND,
skipping to change at page 6, line 19 skipping to change at page 6, line 19
An IMAP server advertises support for IMAP events in Sieve through An IMAP server advertises support for IMAP events in Sieve through
the "imapsieve" capability. A server that advertises "imapsieve" is the "imapsieve" capability. A server that advertises "imapsieve" is
claiming to be in compliance with this specification in all aspects. claiming to be in compliance with this specification in all aspects.
The syntax of the "imapsieve" capability string is defined as The syntax of the "imapsieve" capability string is defined as
follows: follows:
capability /= "IMAPSIEVE=" sieveurl-server capability /= "IMAPSIEVE=" sieveurl-server
; <sieveurl-server> is defined in RFC 5804, Section 3 ; <sieveurl-server> is defined in RFC 5804, Section 3
Only one "imapsieve" capability string, specifying one sieveurl- Only one "imapsieve" capability string, specifying one sieveurl-
server, can be present. The sieveurl-server identifies the server, is allowed to be present. The sieveurl-server identifies the
ManageSieve server that clients need to contact for managing Sieve ManageSieve server that clients need to contact for managing Sieve
scripts associated with this IMAP server. scripts associated with this IMAP server.
The corresponding Sieve implementation uses the Sieve capability The corresponding Sieve implementation uses the Sieve capability
string "imapsieve", and Sieve scripts that depend upon the IMAP string "imapsieve", and Sieve scripts that depend upon the IMAP
events MUST include that string in their "required" lists. events MUST include that string in their "required" lists.
Implementations that support IMAP events in Sieve MUST also support Implementations that support IMAP events in Sieve MUST also support
IMAP Metadata [RFC5464] and Sieve Environment [RFC5183], because IMAP Metadata [RFC5464] and Sieve Environment [RFC5183], because
Metadata is used to associate scripts with IMAP mailboxes and Metadata is used to associate scripts with IMAP mailboxes and
skipping to change at page 7, line 49 skipping to change at page 7, line 49
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] Sieve implementation supports the IMAP4Flags extension [RFC5232]
and the 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 a
another script invocation. In any case, implementations MUST take further invocation of the script. In any case, implementations MUST
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.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
skipping to change at page 8, line 26 skipping to change at page 8, line 26
When an applicable event occurs on an IMAP mailbox, if there is an When an applicable event occurs on an IMAP mailbox, if there is an
IMAP metadata entry named "/shared/imapsieve/script" for the mailbox, IMAP metadata entry named "/shared/imapsieve/script" for the mailbox,
that entry is used. If there is not, but there is an IMAP metadata that entry is used. If there is not, but there is an IMAP metadata
entry named "/shared/imapsieve/script" for the server, that entry is entry named "/shared/imapsieve/script" for the server, that entry is
used (providing a way to define a global script for all mailboxes on used (providing a way to define a global script for all mailboxes on
a server). If neither entry exists, then no script will be invoked. a server). If neither entry exists, then no script will be invoked.
If a "/shared/imapsieve/script" metadata entry was selected above, If a "/shared/imapsieve/script" metadata entry was selected above,
its value is used as the name of the Sieve script that will be its value is used as the name of the Sieve script that will be
invoked in response to the IMAP event. If the value is empty, then invoked in response to the IMAP event. If the value is empty, then
no script is run. no script is run. The selection of which metadata entry to use
happens before any examination of the contents of the entry. If the
mailbox entry is selected and is then found to be unusable or empty,
the server entry is not used as a backup: no script is run.
This specifies the mechanism for "activating" a script for a given This specifies the mechanism for "activating" a script for a given
mailbox (or for all mailboxes), but does not specify a mechanism for mailbox (or for all mailboxes), but does not specify a mechanism for
creating, storing, or validating the script. Implementations MUST creating, storing, or validating the script. Implementations MUST
support ManageSieve [RFC5804], and can use the PUTSCRIPT command to support ManageSieve [RFC5804], and can use the PUTSCRIPT command to
store the script without using the SETACTIVE command to activate it. store the script without using the SETACTIVE command to activate it.
Script names used in "/shared/imapsieve/script" metadata entries are Script names used in "/shared/imapsieve/script" metadata entries are
the script names used on the corresponding ManageSieve server. If a the script names used on the corresponding ManageSieve server. If a
"/shared/imapsieve/script" metadata entry contains a script name that "/shared/imapsieve/script" metadata entry contains a script name that
skipping to change at page 10, line 49 skipping to change at page 10, line 49
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, 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 changes, the message is COPIED into the fileinto mailbox, flag changes, the message is COPIED into the fileinto mailbox,
without removing the original. In all cases, fileinto always creates without removing the original. In all cases, fileinto always creates
a new message, separate from the original. a new message, separate from 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); alternatively, it
to have expunges batched, or done by a user. If the server does the might choose to have expunges batched or done by a user. If the
expunge, the effect is as though a client had flagged the message and server does the expunge, the effect is as though a client had flagged
done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. the message and done a UID EXPUNGE (see [RFC4315]) on the affected
Handling it this way allows clients to handle messages consistently, message(s) only. Handling it this way allows clients to handle
and avoids hidden changes that might invalidate their message caches. 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 32 skipping to change at page 11, line 33
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.
Any site policies related to the origination of email have to be
enforced in the submission service, which will apply the same
policies to messages generated by the redirect action as it does to
messages submitted directly by user agents.
It is important to use the redirect action with great caution and
only with the understanding and consent of the user, as it causes a
message to be sent as a side effect of a user action (the storing or
copying of a message, the changing of a flag). The following
examples might represent appropriate use of redirect, if the user
specifically chooses them:
o The user wants messages she marks as "important" (through the
setting of the \Flagged flag) to be redirected to her alternate
email address.
o The user wants messages she files (copies) into her "Funny things
to share" mailbox to be redirected to a few friends she shares
these with.
o The user chooses a feature that takes messages the user copies to
his "Junk" mailbox and redirects them to a spam analysis service.
When the user chooses the feature, the mechanism and privacy
consequences are clearly explained.
But it is unlikely for examples such as these to ever be appropriate,
and the use of redirect in these sorts of scenarios is not advisable.
o Messages being redirected as a result of setting the \Seen flag.
The \Seen flag is set as a result of fetching the message, and
using redirect here is almost certainly too broad.
o Messages being redirected in a server-wide script to a spam
analysis service as a result of a user copying the message to his
"Junk" mailbox.
It would be dangerous and inappropriate for a server script to
redirect messages on behalf of all users, likely without their
understanding or consent. Therefore, the redirect action SHOULD NOT
be used in server-wide scripts.
It is also important to understand that the redirect action will not
have access to user-agent context, such as a setting to digitally
sign or encrypt all outgoing messages, or a setting to include a
particular Reply-To address. Users should be cautioned, when using
this action in their scripts, that this is the case.
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 changes, target mailbox in addition to being redirected. For flag 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); alternatively, it
to have expunges batched, or done by a user. If the server does the might choose to have expunges batched or done by a user. If the
expunge, the effect is as though a client had flagged the message and server does the expunge, the effect is as though a client had flagged
done a UID EXPUNGE (see [RFC4315]) on the affected message(s) only. the message and done a UID EXPUNGE (see [RFC4315]) on the affected
Handling it this way allows clients to handle messages consistently, message(s) only. Handling it this way allows clients to handle
and avoids hidden changes that might invalidate their message caches. 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, MULTIAPPEND, and COPY, the message is
first stored into the target mailbox. If an explicit keep action is first stored into the target mailbox. If an explicit keep action is
also in effect, the discard action now does nothing. Otherwise, the also 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); alternatively, it might choose to have expunges batched or
user. If the server does the expunge, the effect is as though a done by a user. If the server does the expunge, the effect is as
client had flagged the message and done a UID EXPUNGE (see [RFC4315]) though a client had flagged the message and done a UID EXPUNGE (see
on the affected message(s) only. Handling it this way allows clients [RFC4315]) on the affected message(s) only. Handling it this way
to handle messages consistently, and avoids hidden changes that might allows clients to handle messages consistently, and avoids hidden
invalidate their message caches. 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
If the EditHeader extension [RFC5293] is available, it can be used to If the EditHeader extension [RFC5293] is available, it can be used to
make transient changes to header fields, which aren't saved in place, make transient changes to header fields, which aren't saved in place,
such as for "redirect" or "fileinto" actions. Because messages in such as for "redirect" or "fileinto" actions. Because messages in
IMAP mailboxes are immutable, such changes are NOT applicable for the IMAP mailboxes are immutable, such changes are not applicable for the
"keep" acton (explicit or implicit). See Section 3.1. "keep" action (explicit or implicit). See Section 3.1.
3.8. The Setflag, Deleteflag, and Removeflag Actions 3.8. The Setflag, Deleteflag, and Removeflag Actions
Implementations of IMAP events in Sieve MUST also support the Implementations of IMAP events in Sieve MUST also support the
IMAP4Flags extension [RFC5232], and the actions associated with it IMAP4Flags extension [RFC5232], and the actions associated with it
are all applicable to any case that falls under IMAP events in Sieve. are all applicable to any case that falls under IMAP events in Sieve.
It is worth noting also that the "hasflag" test that is defined in It is worth noting also that the "hasflag" test that is defined in
the IMAP4Flags extension might be particularly useful in scripts the IMAP4Flags extension might be particularly useful in scripts
triggered by flag changes ("hasflag" will see the new, changed triggered by flag changes ("hasflag" will see the new, changed
skipping to change at page 13, line 6 skipping to change at page 14, line 6
case, implementations MUST take steps to avoid such loops. case, implementations MUST take steps to avoid such loops.
3.9. MIME Part Tests and Replacement 3.9. MIME Part Tests and Replacement
If the MIME Part Tests extension [RFC5703] is available, all of its If the MIME Part Tests extension [RFC5703] is available, all of its
functions can be used, but any changes made to the message, using the functions can be used, but any changes made to the message, using the
"replace" or "enclose" action, MUST be considered transient, and are "replace" or "enclose" action, MUST be considered transient, and are
only applicable with actions such as "redirect" and "fileinto". only applicable with actions such as "redirect" and "fileinto".
Because messages in IMAP mailboxes are immutable, such changes are Because messages in IMAP mailboxes are immutable, such changes are
NOT applicable for the "keep" acton (explicit or implicit). See not applicable for the "keep" action (explicit or implicit). See
Section 3.1. Section 3.1.
3.10. Spamtest and Virustest 3.10. Spamtest and Virustest
If the Spamtest and Virustest extensions [RFC5235] are available, If the Spamtest and Virustest extensions [RFC5235] are available,
they are applicable in all cases that fall under IMAP events in they are applicable in all cases that fall under IMAP events in
Sieve. Sieve.
3.11. Inapplicable Actions 3.11. Inapplicable Actions
The following actions and extensions are NOT applicable to any case The following actions and extensions are not applicable to any case
that falls under IMAP events in Sieve, because they are specifically that falls under IMAP events in Sieve, because they are specifically
designed to respond to delivery of a new email message. Their designed to respond to delivery of a new email message. Their
appearance in the "require" control or their use in an IMAP event appearance in the "require" control or their use in an IMAP event
MUST result in an error condition that will terminate the Sieve MUST result in an error condition that will terminate the Sieve
script: script:
reject [RFC5228] reject [RFC5228]
ereject [RFC5429] ereject [RFC5429]
vacation [RFC5230] vacation [RFC5230]
Future extensions that are specifically designed to respond to Future extensions that are specifically designed to respond to
delivery of a new email message will likewise not be applicable to delivery of a new email message will likewise not be applicable to
this extension. this extension.
3.12. Future Sieve Actions
As noted above, future extensions that are specifically designed to
respond to delivery of a new email message will not be applicable to
this extension, because this extension does not involve acting at
new-message delivery time.
In general, future extensions to Sieve that define new actions MUST
specify the applicability of those actions to this specification.
4. Interaction With Sieve Environment 4. Interaction With Sieve Environment
4.1. Base Sieve Environment Items: location and phase 4.1. Base Sieve Environment Items: location and phase
The Sieve Environment extension defines a set of standard environment The Sieve Environment extension defines a set of standard environment
items (see [RFC5183], Section 4.1). Two of those items are affected items (see [RFC5183], Section 4.1). Two of those items are affected
when the script is invoked through an IMAP event. when the script is invoked through an IMAP event.
The value of "location" is set to "MS" -- evaluation is being The value of "location" is set to "MS" -- evaluation is being
performed by a Message Store. performed by a Message Store.
 End of changes. 25 change blocks. 
69 lines changed or deleted 138 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/