draft-ietf-sieve-imap-sieve-07.txt   draft-ietf-sieve-imap-sieve-08.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 10, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: March 14, 2013 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-07 draft-ietf-sieve-imap-sieve-08
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 2, line 33 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 . . . . . . . . . . . . . . . . . . . . 12 3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11
3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 13 3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 12
3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 13 3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12
3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13 3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12
3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 13 3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12
3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 14 3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 13
3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 14 3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 13
3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 14 3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 13
4. Interaction With Sieve Environment . . . . . . . . . . . . 15 4. Interaction With Sieve Environment . . . . . . . . . . . . 14
4.1. Base Sieve Environment Items: location and phase . . . . . 15 4.1. Base Sieve Environment Items: location and phase . . . . . 14
4.2. New Sieve Environment Items: imapuser and imapemail . . . 15 4.2. New Sieve Environment Items: imapuser and imapemail . . . 14
4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 15 4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 14
4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 16 4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 15
4.5. New Sieve Environment Item: changedflags . . . . . . . . . 16 4.5. New Sieve Environment Item: changedflags . . . . . . . . . 15
4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 16 4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Registration of "imapsieve" IMAP capability . . . . . . . 19 7.1. Registration of "imapsieve" IMAP capability . . . . . . . 18
7.2. Registration of "imapsieve" Sieve extension . . . . . . . 19 7.2. Registration of "imapsieve" Sieve extension . . . . . . . 18
7.3. Registration of Sieve Environment Items . . . . . . . . . 19 7.3. Registration of Sieve Environment Items . . . . . . . . . 18
7.3.1. Registration of Sieve Environment Item: cause . . . . . . 19 7.3.1. Registration of Sieve Environment Item: cause . . . . . . 18
7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 20 7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 19
7.3.3. Registration of Sieve Environment Item: changedflags . . . 20 7.3.3. Registration of Sieve Environment Item: changedflags . . . 19
7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 20 7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 19
7.3.5. Registration of Sieve Environment Item: imapemail . . . . 20 7.3.5. Registration of Sieve Environment Item: imapemail . . . . 19
7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 20 7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 19
7.5. Registration of IMAP METADATA Server Entry Name . . . . . 21 7.5. Registration of IMAP METADATA Server Entry Name . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . 23
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 11, line 33 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); alternatively, it (WITHOUT expunging other messages in the mailbox); alternatively, it
might choose to have expunges batched or done by a user. If the 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 server does the expunge, the effect is as though a client had flagged
 End of changes. 8 change blocks. 
80 lines changed or deleted 33 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/