< draft-ietf-lemonade-imap-sieve-05.txt   draft-ietf-lemonade-imap-sieve-06.txt >
Lemonade Working Group B. Leiba Lemonade Working Group B. Leiba
Internet-Draft IBM T.J. Watson Research Center Internet-Draft Huawei Technologies
Intended status: Standards Track February 21, 2008 Intended status: Standards Track July 11, 2009
Expires: August 24, 2008 Expires: January 12, 2010
Support for Sieve in Internet Message Access Protocol (IMAP4) Support for Sieve in Internet Message Access Protocol (IMAP4)
draft-ietf-lemonade-imap-sieve-05 draft-ietf-lemonade-imap-sieve-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2008. This Internet-Draft will expire on January 12, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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).
Note Note
While this document defines extensions to IMAP and Sieve, it is the This document defines extensions to IMAP and Sieve. For now, it is
work of the Lemonade Working Group (Enhancements to Internet email to the work of the Lemonade Working Group (Enhancements to Internet
support diverse service environments), and discussion of it is on the email to support diverse service environments), but it will be moved
lemonade mailing list at mailto:lemonade@ietf.org. Subscription to the Sieve working group at some point.
requests can be sent to
mailto:lemonade-request@ietf.org?body=subscribe (send an email 1. Discussion of this document should be taken to the Sieve mailing
message with the word "subscribe" in the body). A WWW archive of list at mailto:ietf-mta-filters@imc.org
back messages is available at
http://www.ietf.org/mail-archive/web/lemonade/index.html 2. Subscription requests can be sent to
mailto:ietf-mta-filters-request@imc.org?body=subscribe (send an
email message with the word "subscribe" in the body).
3. A WWW archive of back messages is available at
http://www.ietf.org/mail-archive/web/sieve/index.html
4. Older messages, which were posted to the lemonade mailing list,
are archived at
http://www.ietf.org/mail-archive/web/lemonade/index.html
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Conventions used in this document . . . . . . . . . . . . 6 1.2. Conventions used in this document . . . . . . . . . . . . 6
2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 7 2. The IMAP "IMAPSieve" Extension . . . . . . . . . . . . . . 7
2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 7 2.1. The "IMAPSieve" Capability String . . . . . . . . . . . . 7
2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 7 2.2. Existing IMAP Functions Affected by IMAPSieve . . . . . . 7
2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7 2.2.1. The IMAP APPEND Command . . . . . . . . . . . . . . . . . 7
2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7 2.2.2. The IMAP MULTIAPPEND Command . . . . . . . . . . . . . . . 7
2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 8 2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 8
2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 8 2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 8
2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8 2.2.5. New or Changed IMAP Message Annotations . . . . . . . . . 8
2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 9 2.3. New Functions Defined by IMAPSieve . . . . . . . . . . . . 9
2.3.1. Changes to Metadata . . . . . . . . . . . . . . . . . . . 9 2.3.1. Changes to Metadata . . . . . . . . . . . . . . . . . . . 9
3. Applicable Sieve Actions and Interactions . . . . . . . . 10 3. Applicable Sieve Actions and Interactions . . . . . . . . 11
3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10 3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 11
3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10 3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 11
3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10 3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 11
3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11 3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 12
3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 11 3.5. The Reject Action . . . . . . . . . . . . . . . . . . . . 12
3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 11 3.6. The Discard Action . . . . . . . . . . . . . . . . . . . . 12
3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 12 3.7. The Notify Action . . . . . . . . . . . . . . . . . . . . 13
3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 12 3.8. The Addheader and Deleteheader Actions . . . . . . . . . . 13
3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12 3.9. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13
3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 12 3.10. The Vacation Action . . . . . . . . . . . . . . . . . . . 14
3.11. New Sieve Environment Item: cause . . . . . . . . . . . . 12 3.11. Spamtest . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.12. New Sieve Environment Item: mailbox . . . . . . . . . . . 13 3.12. New Sieve Environment Item: cause . . . . . . . . . . . . 14
3.13. New Sieve Environment Item: changedflags . . . . . . . . . 13 3.13. New Sieve Environment Item: mailbox . . . . . . . . . . . 14
3.14. New Sieve Environment Item: changedannotations . . . . . . 13 3.14. New Sieve Environment Item: changedflags . . . . . . . . . 15
3.15. Interaction With Sieve Tests (Comparisons) . . . . . . . . 14 3.15. New Sieve Environment Item: changedannotations . . . . . . 15
3.16. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . 16 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . 17
6.1. Registration of imapsieve extension . . . . . . . . . . . 17
6.2. Registration of environment item: cause . . . . . . . . . 17
6.3. Registration of environment item: mailbox . . . . . . . . 17
6.4. Registration of environment item: changedflags . . . . . . 18
6.5. Registration of environment item: changedannotations . . . 18
6.6. Registration of IMAP METADATA mailbox entry name . . . . . 19
6.7. Registration of IMAP METADATA server entry name . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 6.1. Registration of imapsieve extension . . . . . . . . . . . 18
7.2. Non-Normative References . . . . . . . . . . . . . . . . . 21 6.2. Registration of environment item: cause . . . . . . . . . 18
6.3. Registration of environment item: mailbox . . . . . . . . 18
6.4. Registration of environment item: changedflags . . . . . . 19
6.5. Registration of environment item: changedannotations . . . 19
6.6. Registration of IMAP METADATA mailbox entry name . . . . . 20
6.7. Registration of IMAP METADATA server entry name . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Non-Normative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . 24
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
Some applications have a need to apply [Sieve] filters in situations Some applications have a need to apply [Sieve] filters in situations
other than initial mail delivery. This is especially true in diverse other than initial mail delivery. This is especially true in diverse
service environments, such as when the client is sporadically service environments, such as when the client is sporadically
connected, is connected through a high-latency or high-cost channel, connected, is connected through a high-latency or high-cost channel,
or is on a limited-function device. For such clients, it may be very or is on a limited-function device. For such clients, it may be very
skipping to change at page 6, line 25 skipping to change at page 6, line 25
of server capabilities, including those provided by Sieve filtering of server capabilities, including those provided by Sieve filtering
(and Sieve extensions, such as [Notify]). (and Sieve extensions, such as [Notify]).
This specification defines extensions to [IMAP] to support the This specification defines extensions to [IMAP] to support the
invocation of Sieve scripts at times when the IMAP server creates new invocation of Sieve scripts at times when the IMAP server creates new
messages, or modifies existing ones. It also defines how Sieve messages, or modifies existing ones. It also defines how Sieve
scripts will process these invocations. Support for IMAPSieve scripts will process these invocations. Support for IMAPSieve
requires support for [Metadata] as well, since the latter is used to requires support for [Metadata] as well, since the latter is used to
associate scripts with IMAP mailboxes. associate scripts with IMAP mailboxes.
[[anchor1: General note: Sieve was designed to work at final
delivery, and makes many assumptions about the context. Will those
assumptions break this environment without our realizing it fully?]]
[[anchor2: Note about identity: We might want to use Sieve to impose
fine-grained access controls. In final delivery, there's no identity
for the "filer". Here, there is: the logged-in IMAP user. How do we
get at that identity?]]
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [Keywds]. be interpreted as described in [Keywds].
2. The IMAP "IMAPSieve" Extension 2. The IMAP "IMAPSieve" Extension
2.1. The "IMAPSieve" Capability String 2.1. The "IMAPSieve" Capability String
skipping to change at page 8, line 44 skipping to change at page 8, line 44
script loops, flag changes that are made as a result of a script that script loops, flag changes that are made as a result of a script that
was itself invoked because of flag changes SHOULD NOT result in was itself invoked because of flag changes SHOULD NOT result in
another script invocation. In any case, implementations MUST take another script invocation. In any case, implementations MUST take
steps to avoid such loops. steps to avoid such loops.
For flag-change events, the Sieve script will see the message flags For flag-change events, the Sieve script will see the message flags
as they are AFTER the changes. as they are AFTER the changes.
2.2.5. New or Changed IMAP Message Annotations 2.2.5. New or Changed IMAP Message Annotations
[[anchor3: Sieve has no way to get the annotations, so is there
really value in being told about annotation changes here? Maybe push
that into a sieve-annotations extension later.]]
If the IMAP server supports the [Annotate] extension, one or more If the IMAP server supports the [Annotate] extension, one or more
existing messages can have annotations added or changed through the existing messages can have annotations added or changed through the
ANNOTATE command. In a server that advertises IMAPSieve, messages ANNOTATE command. In a server that advertises IMAPSieve, messages
getting new or changed annotations MUST trigger the execution of a getting new or changed annotations MUST trigger the execution of a
Sieve script, subject to the settings defined through Metadata. Sieve script, subject to the settings defined through Metadata.
For annotation-change events, the Sieve script will see the message For annotation-change events, the Sieve script will see the message
annotations as they are AFTER the changes. annotations as they are AFTER the changes.
2.3. New Functions Defined by IMAPSieve 2.3. New Functions Defined by IMAPSieve
skipping to change at page 11, line 7 skipping to change at page 12, line 7
invoked). The implementation MAY then expunge the original message invoked). The implementation MAY then expunge the original message
(WITHOUT expunging other messages in the mailbox), or it MAY choose (WITHOUT expunging other messages in the mailbox), or it MAY choose
to have expunges batched, or done by a user. If the server does the to have expunges batched, or done by a user. If the server does the
expunge, the effect is as though a client had flagged the message and expunge, the effect is as though a client had flagged the message and
done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only. done a UID EXPUNGE (see [UIDPlus]) on the affected message(s) only.
Handling it this way allows clients to handle messages consistently, Handling it this way allows clients to handle messages consistently,
and avoids hidden changes that might invalidate their message caches. and avoids hidden changes that might invalidate their message caches.
3.4. The Redirect Action 3.4. The Redirect Action
[[anchor4: Redirect assumes message can be submitted as is - not a
valid assumption in this context. What do we do if the decision is
"redirect" and there's not enough information to do it? Also, some
have been concerned about, say, a flag change that has the Sieve
effect of forwarding the message somewhere. Perhaps we should just
forbid redirect.]]
The redirect action is applicable in all cases that fall under The redirect action is applicable in all cases that fall under
IMAPSieve. It causes the message to be sent, as specified in the IMAPSieve. It causes the message to be sent, as specified in the
base Sieve specification, to the designated address. If the [Copy] base Sieve specification, to the designated address. If the [Copy]
extension is available and the :copy option is specified, the extension is available and the :copy option is specified, the
implicit keep is retained; otherwise, redirect cancels the implicit implicit keep is retained; otherwise, redirect cancels the implicit
keep, as specified in the base Sieve specification. 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
target mailbox in addition to being redirected. For flag or target mailbox in addition to being redirected. For flag or
annotation changes, the message remains in its original mailbox. annotation changes, the message remains in its original mailbox.
skipping to change at page 12, line 14 skipping to change at page 13, line 17
3.7. The Notify Action 3.7. The Notify Action
If the [Notify] extension is available, the notify action is If the [Notify] extension is available, the notify action is
applicable in all cases that fall under IMAPSieve. The result is applicable in all cases that fall under IMAPSieve. The result is
that the requested notification is sent, and that the message is that the requested notification is sent, and that the message is
otherwise handled as it would normally have been. otherwise handled as it would normally have been.
3.8. The Addheader and Deleteheader Actions 3.8. The Addheader and Deleteheader Actions
[[anchor5: Should editheader be allowed to change header fields that
aren't saved in place, such as for redirect or fileinto? Editheader
would still have to be banned for "keep", but not otherwise.]]
Even if the [EditHeader] extension is available, since messages in Even if the [EditHeader] extension is available, since messages in
IMAP mailboxes are immutable these actions are NOT applicable. Use IMAP mailboxes are immutable these actions are NOT applicable. Use
of these MUST result in an error condition that will terminate the of these MUST result in an error condition that will terminate the
Sieve script. Explanation: Using them for flag or annotation changes Sieve script. Explanation: Using them for flag or annotation changes
to existing messages would cause the message to be changed. Using to existing messages would cause the message to be changed. Using
them for APPEND, MULTIAPPEND, and COPY would cause unexpected them for APPEND, MULTIAPPEND, and COPY would cause unexpected
differences in the stored copy as compared to what the client differences in the stored copy as compared to what the client
expected, and would make the client's message cache invalid expected, and would make the client's message cache invalid
unexpectedly. unexpectedly.
3.9. The Setflag, Deleteflag, and Removeflag Actions 3.9. The Setflag, Deleteflag, and Removeflag Actions
[[anchor6: Should this just require imap4flags? Some implementors
have said they wouldn't bother with it without the ability to
manipulate flags. And what values of flags does it see -- before or
after the change? If it changes them, can it see the originals? Can
it reset changes?]]
If the [IMAP4Flags] extension is available, the actions associated If the [IMAP4Flags] extension is available, the actions associated
with it are all applicable to any case that falls under IMAPSieve. with it are all applicable to any case that falls under IMAPSieve.
It is worth noting also that the "hasflag" test that is defined in It is worth noting also that the "hasflag" test that is defined in
the IMAP4Flags extension might be particularly useful in scripts the IMAP4Flags extension might be particularly useful in scripts
triggered by flag changes ("hasflag" will see the new, changed triggered by flag changes ("hasflag" will see the new, changed
flags). The flag changes behave as though a client had made the flags). The flag changes behave as though a client had made the
change. change.
As explained above, in order to avoid script loops flag changes that As explained above, in order to avoid script loops flag changes that
are made as a result of a script that was itself invoked because of are made as a result of a script that was itself invoked because of
flag changes SHOULD NOT result in another script invocation. In any flag changes SHOULD NOT result in another script invocation. In any
case, implementations MUST take steps to avoid such loops. case, implementations MUST take steps to avoid such loops.
3.10. The Vacation Action 3.10. The Vacation Action
Even if the [Vacation] extension is available, the vacation action is Even if the [Vacation] extension is available, the vacation action is
NOT applicable to any case that falls under IMAPSieve. Its use MUST NOT applicable to any case that falls under IMAPSieve. Its use MUST
result in an error condition that will terminate the Sieve script. result in an error condition that will terminate the Sieve script.
3.11. New Sieve Environment Item: cause 3.11. Spamtest
[Spamtest] [[anchor7: We need to say something about the spamtest/
virustest extension. We need to be able to scan appended messages.
And we can't use headers to communicate spam status, because the
message is immutable. What should we say here?]]
3.12. New Sieve Environment Item: cause
Implementations MAY invoke different Sieve scripts for the different Implementations MAY invoke different Sieve scripts for the different
conditions described in this document (append, copy, flag changes, conditions described in this document (append, copy, flag changes,
annotation changes). If the actions to be taken are common, and the annotation changes). If the actions to be taken are common, and the
implementation supports the [Include] extension, the common script implementation supports the [Include] extension, the common script
code can be included as specified there. code can be included as specified there.
It may be preferable, though, to use a single script for all these It may be preferable, though, to use a single script for all these
conditions. To support that, the implementation MUST set the conditions. To support that, the implementation MUST set the
[Environment] item "cause", which contains the name of the action [Environment] item "cause", which contains the name of the action
skipping to change at page 13, line 20 skipping to change at page 14, line 41
o APPEND (for invocations resulting from APPEND or MULTIAPPEND) o APPEND (for invocations resulting from APPEND or MULTIAPPEND)
o COPY (for invocations resulting from COPY) o COPY (for invocations resulting from COPY)
o FLAG (for invocations resulting from flag changes) o FLAG (for invocations resulting from flag changes)
o ANNOTATE (for invocations resulting from new or changed o ANNOTATE (for invocations resulting from new or changed
annotations) annotations)
3.12. New Sieve Environment Item: mailbox 3.13. New Sieve Environment Item: mailbox
The implementation MUST set the [Environment] item "mailbox" to the The implementation MUST set the [Environment] item "mailbox" to the
name of the mailbox that the affected message is in, in the case of 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 the script new messages. The value of this item is fixed when the script
begins, and, in particular, MUST NOT change as a result of any begins, and, in particular, MUST NOT change as a result of any
action, such as "fileinto". action, such as "fileinto".
3.13. New Sieve Environment Item: changedflags 3.14. New Sieve Environment Item: changedflags
If the [IMAP4Flags] extension is available, AND the script was If the [IMAP4Flags] extension is available, AND the script was
invoked because of flag changes to an existing message, the invoked because of flag changes to an existing message, the
implementation MUST set the [Environment] item "changedflags" to the implementation MUST set the [Environment] item "changedflags" to the
name(s) of the flag(s) that have changed. If the script was not name(s) of the flag(s) that have changed. If the script was not
invoked because of flag changes, the value of this item MUST be the invoked because of flag changes, the value of this item MUST be the
empty string. The script will not know from this item whether the empty string. The script will not know from this item whether the
flags have been set or reset, but it can use the "hasflag" test to flags have been set or reset, but it can use the "hasflag" test to
determine the current value. See example 2 in Section 4 for an determine the current value. See example 2 in Section 4 for an
example of how this might be used. example of how this might be used.
3.14. New Sieve Environment Item: changedannotations 3.15. New Sieve Environment Item: changedannotations
If the [Annotate] extension is available, AND the script was invoked If the [Annotate] extension is available, AND the script was invoked
because of annotation changes to an existing message, the because of annotation changes to an existing message, the
implementation MUST set the [Environment] item "changedannotations" implementation MUST set the [Environment] item "changedannotations"
to the name(s) of the annotation(s) that have changed. If the script to the name(s) of the annotation(s) that have changed. If the script
was not invoked because of annotation changes, the value of this item was not invoked because of annotation changes, the value of this item
MUST be the empty string. MUST be the empty string.
3.15. Interaction With Sieve Tests (Comparisons) 3.16. Interaction With Sieve Tests (Comparisons)
This extension does not affect the operation of any tests or This extension does not affect the operation of any tests or
comparisons. comparisons.
4. Examples 4. 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".
skipping to change at page 15, line 27 skipping to change at page 16, line 27
} }
} }
Example 2: Example 2:
If the script is called for any message with the \Flagged flag set If the script is called for any message with the \Flagged flag set
(tested through the [IMAP4Flags] extension), a notification is sent (tested through the [IMAP4Flags] extension), a notification is sent
using the [Notify] extension. No notification will be sent, though, using the [Notify] extension. No notification will be sent, though,
if we're called with an existing message that already had that flag if we're called with an existing message that already had that flag
set. set.
require ["nofity", "imap4flags", "variables", "environment"]; require ["notify", "imap4flags", "variables", "environment"];
if environment :matches "mailbox" "*" { if environment :matches "mailbox" "*" {
set "mailbox" "${1}"; set "mailbox" "${1}";
} }
if allof (hasflag "\\Flagged", if allof (hasflag "\\Flagged",
not environment :contains "changedflags" "\\Flagged") { not environment :contains "changedflags" "\\Flagged") {
notify :message "Important message in ${mailbox}"; notify :message "Important message in ${mailbox}";
} }
skipping to change at page 17, line 17 skipping to change at page 18, line 17
6.1. Registration of imapsieve extension 6.1. Registration of imapsieve extension
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
extension specified in this document: extension specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: imapsieve Capability name: imapsieve
Description: Add Sieve processing for IMAP events. Description: Add Sieve processing for IMAP events.
RFC number: this RFC RFC number: this RFC
Contact address: Barry Leiba <leiba@watson.ibm.com> Contact address: Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve extensions This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
6.2. Registration of environment item: cause 6.2. Registration of environment item: cause
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
skipping to change at page 17, line 44 skipping to change at page 18, line 44
o COPY (for invocations resulting from COPY) o COPY (for invocations resulting from COPY)
o FLAG (for invocations resulting from flag changes) o FLAG (for invocations resulting from flag changes)
o ANNOTATE (for invocations resulting from new or changed o ANNOTATE (for invocations resulting from new or changed
annotations) annotations)
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <leiba@watson.ibm.com> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the [Environment] extension.
6.3. Registration of environment item: mailbox 6.3. Registration of environment item: mailbox
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: mailbox Item name: mailbox
Description: The name of the mailbox that the affected message is in, Description: The name of the mailbox that the affected message is in,
in the case of existing messages, or is targeted to be stored into, in the case of existing messages, or is targeted to be stored into,
in the case of new messages. The value of this item is fixed when in the case of new messages. The value of this item is fixed when
the script begins, and, in particular, MUST NOT change as a result of the script begins, and, in particular, MUST NOT change as a result of
any action, such as "fileinto". any action, such as "fileinto".
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <leiba@watson.ibm.com> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the [Environment] extension.
6.4. Registration of environment item: changedflags 6.4. Registration of environment item: changedflags
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: changedflags Item name: changedflags
Description: If the script was invoked because of flag changes to an Description: If the script was invoked because of flag changes to an
existing message, this contains the name(s) of the flag(s) that have existing message, this contains the name(s) of the flag(s) that have
changed. Otherwise, the value of this item MUST be the empty string. changed. Otherwise, the value of this item MUST be the empty string.
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <leiba@watson.ibm.com> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the [Environment] extension.
6.5. Registration of environment item: changedannotations 6.5. Registration of environment item: changedannotations
The following template specifies the IANA registration of a sieve The following template specifies the IANA registration of a sieve
environment item specified in this document: environment item specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve environment item Subject: Registration of new Sieve environment item
Item name: changedannotations Item name: changedannotations
Description: If the script was invoked because of annotation changes Description: If the script was invoked because of annotation changes
to an existing message, this contains the name(s) of the to an existing message, this contains the name(s) of the
annotation(s) that have changed. Otherwise, the value of this item annotation(s) that have changed. Otherwise, the value of this item
MUST be the empty string. MUST be the empty string.
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
Barry Leiba <leiba@watson.ibm.com> Barry Leiba <barryleiba@computer.org>
This information should be added to the list of sieve environment This information should be added to the list of sieve environment
item names given in the [Environment] extension. item names given in the [Environment] extension.
6.6. Registration of IMAP METADATA mailbox entry name 6.6. Registration of IMAP METADATA mailbox entry name
The following template specifies the IANA registration of an IMAP The following template specifies the IANA registration of an IMAP
METADATA entry name specified in this document: METADATA entry name specified in this document:
To: iana@iana.org To: iana@iana.org
skipping to change at page 19, line 26 skipping to change at page 20, line 26
[x] Entry [ ] Attribute [x] Entry [ ] Attribute
[x] Mailbox [ ] Server [x] Mailbox [ ] Server
Name: /IMAPSieve/Script Name: /IMAPSieve/Script
Description: This entry name is used to define mailbox metadata Description: This entry name is used to define mailbox metadata
associated with IMAPSieve events for the associated mailbox. associated with IMAPSieve events for the associated mailbox.
Specifically, this specifies the Sieve script that will be invoked Specifically, this specifies the Sieve script that will be invoked
when IMAP events occur on the specified mailbox. when IMAP events occur on the specified mailbox.
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
RFC number: this RFC RFC number: this RFC
Contact person: Barry Leiba Contact person: Barry Leiba
Contact email: leiba@watson.ibm.com Contact email: barryleiba@computer.org
This information should be added to the list of IMAP METADATA item This information should be added to the list of IMAP METADATA item
names given in the [Metadata] extension. names given in the [Metadata] extension.
6.7. Registration of IMAP METADATA server entry name 6.7. Registration of IMAP METADATA server entry name
The following template specifies the IANA registration of an IMAP The following template specifies the IANA registration of an IMAP
METADATA entry name specified in this document: METADATA entry name specified in this document:
To: iana@iana.org To: iana@iana.org
skipping to change at page 19, line 50 skipping to change at page 20, line 50
[ ] Mailbox [x] Server [ ] Mailbox [x] Server
Name: /IMAPSieve/Script Name: /IMAPSieve/Script
Description: This entry name is used to define metadata associated Description: This entry name is used to define metadata associated
globally with IMAPSieve events for the associated server. globally with IMAPSieve events for the associated server.
Specifically, this specifies the Sieve script that will be invoked Specifically, this specifies the Sieve script that will be invoked
when IMAP events occur on any mailbox in the server that does not when IMAP events occur on any mailbox in the server that does not
have its own mailbox-level /IMAPSieve/Script entry. have its own mailbox-level /IMAPSieve/Script entry.
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
RFC number: this RFC RFC number: this RFC
Contact person: Barry Leiba Contact person: Barry Leiba
Contact email: leiba@watson.ibm.com Contact email: barryleiba@computer.org
This information should be added to the list of IMAP METADATA item This information should be added to the list of IMAP METADATA item
names given in the [Metadata] extension. names given in the [Metadata] extension.
7. References 7. References
7.1. Normative References 7.1. Normative References
[Annotate] [Annotate]
Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", RFC Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension",
Editor Queue, draft-ietf-imapext-annotate-16, August 2006. RFC 5257, June 2008.
[Copy] Degener, J., "Sieve Extension: Copying Without Side [Copy] Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, October 2004. Effects", RFC 3894, October 2004.
[Environment] [Environment]
Freed, N., "Sieve Email Filtering: Environment and Ihave Freed, N., "Sieve Email Filtering: Environment Extension",
Extensions", work in RFC 5183, May 2008.
progress, draft-freed-sieve-environment-ihave-00,
November 2006.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[IMAP4Flags] [IMAP4Flags]
Melnikov, A., "Sieve Mail Filtering Language: IMAP flag Melnikov, A., "Sieve Mail Filtering Language: IMAP flag
Extension", RFC Editor Extension", RFC 5232, January 2008.
Queue, draft-ietf-sieve-imapflags-05, May 2006.
[Keywds] Bradner, S., "Key words for use in RFCs to Indicate [Keywds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[Metadata] [Metadata]
Daboo, C., "IMAP METADATA Extension", work in Daboo, C., "The IMAP METADATA Extension", RFC 5464,
progress, draft-daboo-imap-annotatemore-11, February 2007. February 2009.
[MultiAppend] [MultiAppend]
Crispin, M., "Internet Message Access Protocol (IMAP) - Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003. MULTIAPPEND Extension", RFC 3502, March 2003.
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", IESG Filtering Language", RFC 5228, January 2008.
Evaluation, draft-ietf-sieve-3028bis-12, February 2007.
7.2. Non-Normative References 7.2. Non-Normative References
[EditHeader] [EditHeader]
Degener, J. and P. Guenther, "Sieve Email Filtering: Degener, J. and P. Guenther, "Sieve Email Filtering:
Editheader Extension", work in Editheader Extension", RFC 5293, August 2008.
progress, draft-ietf-sieve-editheader-07, November 2006.
[Include] Daboo, C., "SIEVE Email Filtering: Include Extension", [Include] Daboo, C. and A. Stone, "SIEVE Email Filtering: Include
work in progress, draft-daboo-sieve-include-05, June 2006. Extension", work in progress, draft-ietf-sieve-include-02,
May 2009.
[Manage] Martin, T. and A. Melnikov, Ed., "A Protocol for Remotely [Manage] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", work in Managing Sieve Scripts", RFC editor
progress, draft-martin-managesieve-07, November 2006. queue, draft-ietf-sieve-managesieve-09, January 2009.
[Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
Martin, "Sieve Extension: Notifications", work in Martin, "Sieve Email Filtering: Extension for
progress, draft-ietf-sieve-notify-07, February 2007. Notifications", RFC 5435, January 2009.
[Spamtest]
Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extensions", RFC 5235, January 2008.
[UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) - [UIDPlus] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS Extension", RFC 4315, December 2005. UIDPLUS Extension", RFC 4315, December 2005.
[Vacation] [Vacation]
Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
Vacation Extension", RFC Editor Vacation Extension", RFC 5230, January 2008.
Queue, draft-ietf-sieve-vacation-06, February 2006.
Author's Address Author's Address
Barry Leiba Barry Leiba
IBM T.J. Watson Research Center Huawei Technologies
19 Skyline Drive
Hawthorne, NY 10532
US
Phone: +1 914 784 7941
Email: leiba@watson.ibm.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF Phone: +1 646 827 0648
Administrative Support Activity (IASA). Email: barryleiba@computer.org
 End of changes. 41 change blocks. 
136 lines changed or deleted 137 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/