One document matched: draft-ietf-lemonade-imap-sieve-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<!-- !ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!-- ?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ? -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc tocindent="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std"
ipr="full3978"
docName="draft-ietf-lemonade-imap-sieve-05">
<front>
<title abbrev="Lemonade-Sieve">Support for Sieve in Internet Message Access Protocol (IMAP4)</title>
<author initials='B.' surname="Leiba" fullname='Barry Leiba'>
<organization>IBM T.J. Watson Research Center</organization>
<address>
<postal>
<street>19 Skyline Drive</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>
<phone>+1 914 784 7941</phone>
<email>leiba@watson.ibm.com</email>
</address>
</author>
<date year="2008"/>
<area>Applications</area>
<workgroup>Lemonade Working Group</workgroup>
<keyword>IMAP</keyword>
<keyword>Sieve</keyword>
<keyword>email</keyword>
<keyword>filtering</keyword>
<abstract>
<t>
Sieve defines an email filtering language that can, in
principle, plug into any point in the processing of an email
message. As defined in the base specification, it plugs into
mail delivery. This document defines how Sieve can plug into
points in the IMAP protocol where messages are created or changed,
adding the option of user-defined or installation-defined
filtering (or, with Sieve extensions, features such as notifications).
</t>
</abstract>
<note title="Note">
<t>
While this document defines extensions to IMAP and Sieve, it is
the work of the Lemonade Working Group (Enhancements to Internet
email to support diverse service environments), and discussion of it
is on the lemonade mailing list at mailto:lemonade@ietf.org.
Subscription requests can be sent to
mailto:lemonade-request@ietf.org?body=subscribe (send an
email message with the word "subscribe" in the body).
A WWW archive of back messages is available at
http://www.ietf.org/mail-archive/web/lemonade/index.html
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<section anchor="overview" title="Overview">
<t>
Some applications have a need to apply <xref target="Sieve"/>
filters in situations other than initial mail delivery. This
is especially true in diverse service environments, such as
when the client is sporadically 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 important, for higher
performance and reliability, to take advantage of server capabilities,
including those provided by Sieve filtering (and Sieve extensions,
such as <xref target="Notify"/>).
</t>
<t>
This specification defines extensions to <xref target="IMAP"/>
to support the invocation of Sieve scripts at times when the
IMAP server creates new messages, or modifies existing ones.
It also defines how Sieve scripts will process these invocations.
Support for IMAPSieve requires support for <xref target="Metadata"/>
as well, since the latter is used to associate scripts with IMAP
mailboxes.
</t>
</section>
<section anchor="conventions" title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in <xref target="Keywds"/>.
</t>
</section>
</section>
<section anchor="imapspec" title='The IMAP "IMAPSieve" Extension'>
<section anchor="capability" title='The "IMAPSieve" Capability String'>
<t>
An IMAP server advertises support for this extension through the
capability string "IMAPSieve" (the string is not case-sensitive,
and is shown here with this capitalization for readability).
A server that advertises IMAPSieve is claiming to be in
compliance with this specification in all aspects.
</t>
<t>
Implementations that support IMAPSieve MUST also support <xref target="Environment"/>,
because the latter defines an important way for Sieve scripts to test
the conditions under which they have been invoked. Notwithstanding this requirement,
scripts that use IMAPSieve must include BOTH capability strings in their required lists.
</t>
</section>
<section anchor="oldfunc" title='Existing IMAP Functions Affected by IMAPSieve'>
<t>
The subsections below describe in detail the IMAP commands and
situations on which IMAPSieve has an effect.
Not all Sieve actions make sense in the case of messages
affected by IMAP commands.
See <xref target="sieveactions"/> for details.
</t>
<t>
It's important to note that since the base Sieve specification (see <xref target="Sieve"/>)
and its extensions define functions for scripts that are invoked during
initial mail delivery, those function definitions are necessarily tailored to
and limited by that context. This document extends those function definitions
for use during IMAP events. By nature of that, Sieve functions, in this
extended context, may behave somewhat differently, though their extended
behaviour will still be consistent with the functions' goals.
</t>
<t>
If more than one message is affected at the same time,
each message triggers the execution of a Sieve script separately.
The scripts MAY be run in parallel.
</t>
<section anchor="imapappend" title='The IMAP APPEND Command'>
<t>
A message may be added to a mailbox through the IMAP APPEND
command. In a server that advertises IMAPSieve, new messages
added in this way MUST trigger the execution of a Sieve script,
subject to the settings defined through Metadata
(see <xref target="metadata-def"/>).
</t>
</section>
<section anchor="imapmultiappend" title='The IMAP MULTIAPPEND Command'>
<t>
If the IMAP server supports the IMAP <xref target="MultiAppend"/>
extension, messages may be added to a mailbox through the IMAP MULTIAPPEND
command. In a server that advertises IMAPSieve, new messages
added in this way MUST trigger the execution of a Sieve script,
as with the APPEND command, also subject to the settings
defined through Metadata.
</t>
</section>
<section anchor="imapcopy" title='The IMAP COPY Command'>
<t>
One or more messages may be added to a mailbox through the IMAP COPY
command. In a server that advertises IMAPSieve, new messages
added in this way MUST trigger the execution of a Sieve script,
subject to the settings defined through Metadata.
</t>
</section>
<section anchor="imapflags" title='Changes to IMAP Message Flags'>
<t>
One or more existing messages can have their flags changed
in a number of ways, including:
<list style="symbols">
<t>The FETCH command (may cause the \Seen flag to be set).</t>
<t>The STORE command (may cause the \Answered, \Deleted,
\Draft, \Flagged, and \Seen flags to be set or reset,
and may cause keywords to be set or reset).</t>
<t>The invocation of a Sieve script on an existing message,
where the Sieve implementation supports the
<xref target="IMAP4Flags"/> extension
and the script uses one of the actions defined in that extension.
</t>
</list>
In a server that advertises IMAPSieve, messages whose flags
are changed in any way (except as explained in the next sentence)
MUST trigger the execution of a Sieve script,
subject to the settings 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 was
itself invoked because of flag changes SHOULD NOT result in
another script invocation. In any case, implementations MUST
take steps to avoid such loops.
</t>
<t>
For flag-change events, the Sieve script will see the message flags
as they are AFTER the changes.
</t>
</section>
<section anchor="imapannotate" title='New or Changed IMAP Message Annotations'>
<t>
If the IMAP server supports the <xref target="Annotate"/> extension,
one or more existing messages can have annotations added or changed
through the ANNOTATE command.
In a server that advertises IMAPSieve, messages getting new or
changed annotations MUST trigger the execution of a Sieve script,
subject to the settings defined through Metadata.
</t>
<t>
For annotation-change events, the Sieve script will see the message annotations
as they are AFTER the changes.
</t>
</section>
</section>
<section anchor="newfunc" title='New Functions Defined by IMAPSieve'>
<section anchor="metadata-def" title='Changes to Metadata'>
<t>
Support for IMAPSieve requires support for <xref target="Metadata"/>
as well, since the latter is used to associate scripts with IMAP
mailboxes.
</t>
<t>
When an applicable event occurs on an IMAP mailbox, if there is an
IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that entry
is used. If there is not, but there is an IMAP metadata entry named
"/IMAPSieve/Script" for the server, that entry is 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.
</t>
<t>
If an "/IMAPSieve/Script" metadata entry was selected above,
the shared value of that metadata name (its "value.shared" attribute) MUST
be the name of the Sieve script that will be invoked in response to
the IMAP event OR the name of another metadata entry, the name prefixed
with "metadata:" (such as "metadata:/IMAPSieve/ScriptContents"), that
contains the actual script in its value.shared attribute.
Note that only the value.shared attribute is used; any value.priv
attributes are ignored.
</t>
<t>
This specifies the mechanism for "activating" a script for
a given mailbox (or for all mailboxes), but does not specify a
mechanism for creating, storing, or validating the script. Implementations
MAY use <xref target="Manage"/> to acomplish this, using the PUTSCRIPT command
to store the script without using the SETACTIVE command to activate it.
In any case, the script name that is specified in the /IMAPSieve/Script metadata
entry is in a form that depends upon how the server handles the storing of
Sieve scripts.
</t>
<t>
Only one Sieve script may currently be defined per mailbox, eliminating the
complexity and possible ambiguity involved with coordinating the
results of multiple scripts. Any sub-filtering is done in the
Sieve script. For example, if it's only necessary to deal with
flag changes, but not with new messages appended or copied, the
Sieve script will still be invoked for all events, and the script
is responsible for checking the event type.
</t>
<t>
The possibility is open for an extensions to add support for multiple
scripts -- for example, per-client scripts on a multi-client user's inbox,
or per-user scripts on a mailbox that is shared among users.
</t>
<t>
Because this metadata name is associated with the mailbox,
there can (and it's expected that there will) be different scripts
associated with events for different mailboxes. Indeed, most
mailboxes will probably invoke no script at all.
</t>
</section>
</section>
</section>
<section anchor="sieveactions" title="Applicable Sieve Actions and Interactions">
<t>
Since some Sieve actions relate specifically to the delivery of
mail, not all actions make sense when the messages are created
by other means or when changes are made to data associated with
existing messages. This section describes how actions in the base
Sieve specification, and those in extensions known at this writing,
relate to this specification.
</t>
<t>
In addition to what is specified here, interactions noted
in the individual specifications apply, and must be considered.
</t>
<section anchor="action-implicitkeep" title="The Implicit Keep">
<t>
For all cases that fall under IMAPSieve, the implicit keep
means that the message is treated as it would have been if no
Sieve script were run. For APPEND, MULTIAPPEND and COPY, the
message is stored into the target mailbox normally. For flag
or annotation changes, the message is left in the mailbox.
</t>
</section>
<section anchor="action-keep" title="The Keep Action">
<t>
The keep action is applicable in all cases that fall under IMAPSieve.
Its behaviour is as described for implicit keep, in <xref target="action-implicitkeep"/>.
</t>
</section>
<section anchor="action-fileinto" title="The Fileinto Action">
<t>
If the Sieve implementation supports the fileinto action,
that action is applicable in all cases that fall under IMAPSieve.
If the <xref target="Copy"/> extension is available and
the :copy option is specified, the implicit keep is retained;
otherwise, fileinto cancels the implicit keep, as specified in
the base Sieve specification.
</t>
<t>
For APPEND, MULTIAPPEND, and COPY, the message is stored into the
fileinto mailbox IN ADDITION TO the original target mailbox. For flag
or annotation changes, the message is COPIED into the fileinto mailbox,
without removing the original.
</t>
<t>
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 invoked).
The implementation MAY then expunge the original message
(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 expunge, the effect is as though a client had flagged the message and done
a UID EXPUNGE (see <xref target="UIDPlus"/>) 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.
</t>
</section>
<section anchor="action-redirect" title="The Redirect Action">
<t>
The redirect action is applicable in all cases that fall under IMAPSieve.
It causes the message to be sent, as specified in the base Sieve
specification, to the designated address.
If the <xref target="Copy"/> extension is available and
the :copy option is specified, the implicit keep is retained;
otherwise, redirect cancels the implicit keep, as specified in
the base Sieve specification.
</t>
<t>
For APPEND, MULTIAPPEND, and COPY, the message is stored into
the target mailbox in addition to being redirected. For flag
or annotation changes, the message remains in its original mailbox.
</t>
<t>
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 invoked).
The implementation MAY then expunge the original message
(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 expunge, the effect is as though a client had flagged the message and done
a UID EXPUNGE (see <xref target="UIDPlus"/>) 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.
</t>
</section>
<section anchor="action-reject" title="The Reject Action">
<t>
The reject action is NOT applicable to any case that falls under IMAPSieve.
Its use MUST result in an error condition that will terminate the Sieve script.
</t>
</section>
<section anchor="action-discard" title="The Discard Action">
<t>
The discard action is applicable in all cases that fall under IMAPSieve.
For APPEND, MULTIAPPEND, and COPY, the message is first stored
into the target mailbox.
If an explicit keep action is also in effect,
the discard action now does nothing. Otherwise,
the original message is then marked with the \Deleted
flag (and a flag-change Sieve script is NOT invoked).
The implementation MAY then expunge the original message
(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 expunge, the effect is as though a client had flagged the message and done
a UID EXPUNGE (see <xref target="UIDPlus"/>) 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.
</t>
</section>
<section anchor="action-notify" title="The Notify Action">
<t>
If the <xref target="Notify"/> extension is available, the
notify action is applicable in all cases that fall under IMAPSieve.
The result is that the requested notification is sent, and that
the message is otherwise handled as it would normally have been.
</t>
</section>
<section anchor="action-addheader" title="The Addheader and Deleteheader Actions">
<t>
Even if the <xref target="EditHeader"/> extension is available,
since messages in IMAP mailboxes are immutable these actions
are NOT applicable.
Use of these MUST result in an error condition that will terminate the Sieve script.
Explanation: Using them for flag or annotation changes
to existing messages would cause the message to be changed.
Using them for APPEND, MULTIAPPEND, and COPY would cause unexpected
differences in the stored copy as compared to what the client
expected, and would make the client's message cache invalid unexpectedly.
</t>
</section>
<section anchor="action-imapflags" title="The Setflag, Deleteflag, and Removeflag Actions">
<t>
If the <xref target="IMAP4Flags"/> extension is available,
the actions associated with it are all applicable to any case that falls under IMAPSieve.
It is worth noting also that the "hasflag" test that is defined in
the IMAP4Flags extension might be particularly useful in scripts triggered
by flag changes ("hasflag" will see the new, changed flags).
The flag changes behave as though a client had
made the change.
</t>
<t>
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 flag changes SHOULD NOT result in
another script invocation. In any case, implementations MUST
take steps to avoid such loops.
</t>
</section>
<section anchor="action-vacation" title="The Vacation Action">
<t>
Even if the <xref target="Vacation"/> extension is available,
the vacation action is NOT applicable to any case that falls under IMAPSieve.
Its use MUST result in an error condition that will terminate the Sieve script.
</t>
</section>
<section anchor="env-imapcause" title="New Sieve Environment Item: cause">
<t>
Implementations MAY invoke different Sieve scripts for the different
conditions described in this document (append, copy, flag changes,
annotation changes). If the actions to be taken are common, and the
implementation supports the <xref target="Include"/> extension,
the common script code can be included as specified there.
</t>
<t>
It may be preferable, though, to use a single script for all these
conditions. To support that, the implementation MUST set the <xref target="Environment"/> item
"cause", which contains the name of the
action that caused the script to be invoked. Its value is one of
the following:
<list style="symbols">
<t>APPEND (for invocations resulting from APPEND or MULTIAPPEND)</t>
<t>COPY (for invocations resulting from COPY)</t>
<t>FLAG (for invocations resulting from flag changes)</t>
<t>ANNOTATE (for invocations resulting from new or changed annotations)</t>
</list>
</t>
</section>
<section anchor="env-imapmailbox" title="New Sieve Environment Item: mailbox">
<t>
The implementation MUST set the <xref target="Environment"/> item
"mailbox" to 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 new messages.
The value of this item is fixed when the script begins, and,
in particular, MUST NOT change as a result of any action, such as
"fileinto".
</t>
</section>
<section anchor="env-imapnewflags" title="New Sieve Environment Item: changedflags">
<t>
If the <xref target="IMAP4Flags"/> extension is available,
AND the script was invoked because of flag changes to an existing message,
the implementation MUST set the <xref target="Environment"/> item
"changedflags" to the 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 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 determine the current value. See example 2 in <xref target="examples"/>
for an example of how this might be used.
</t>
</section>
<section anchor="env-imapnewannotations" title="New Sieve Environment Item: changedannotations">
<t>
If the <xref target="Annotate"/> extension is available,
AND the script was invoked because of annotation changes to an existing message,
the implementation MUST set the <xref target="Environment"/> item
"changedannotations" to the name(s) of the annotation(s) that have changed.
If the script was not invoked because of annotation changes, the value of this item
MUST be the empty string.
</t>
</section>
<section anchor="tests" title="Interaction With Sieve Tests (Comparisons)">
<t>
This extension does not affect the operation of any tests or comparisons.
</t>
</section>
</section>
<section anchor="examples" title="Examples">
<t>
Example 1:<vspace/>
If a new message is added to the "ActionItems" mailbox, a
copy is sent to the address "actionitems@example.com".
<figure>
<artwork>
require ["copy", "environment"];
if anyof (environment :is "cause" "APPEND",
environment :is "cause" "COPY") {
if environment :is "mailbox" "ActionItems" {
redirect :copy "actionitems@example.com";
}
}
</artwork>
</figure>
</t>
<t>
Example 2:<vspace/>
If the script is called for any message with the \Flagged
flag set (tested through the <xref target="IMAP4Flags"/> extension),
a notification is sent using the <xref target="Notify"/> extension.
No notification will be sent, though, if we're called with an
existing message that already had that flag set.
<figure>
<artwork>
require ["nofity", "imap4flags", "variables", "environment"];
if environment :matches "mailbox" "*" {
set "mailbox" "${1}";
}
if allof (hasflag "\\Flagged",
not environment :contains "changedflags" "\\Flagged") {
notify :message "Important message in ${mailbox}";
}
</artwork>
</figure>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
It is possible to introduce script processing loops by having
a Sieve script that is triggered by flag changes use the actions
defined in the <xref target="IMAP4Flags"/> extension.
Implementations MUST take steps to prevent such loops.
One way to avoid this problem is that if a script
is invoked by flag changes, and that script further changes
the flags, those flag changes SHOULD NOT trigger a Sieve script
invocation.
</t>
<t>
Other security considerations are discussed in
<xref target="IMAP"/>, and <xref target="Sieve"/>,
as well as in some of the other extension documents.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<section anchor="iana-1" title="Registration of imapsieve extension">
<t>
The following template specifies the IANA registration of the
Sieve extension specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve extension
<vspace/>
Capability name: imapsieve
<vspace/>
Description: Add Sieve processing for IMAP events.
<vspace/>
RFC number: this RFC
<vspace/>
Contact address: Barry Leiba <leiba@watson.ibm.com>
</t>
<t>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
</t>
</section>
<section anchor="iana-2" title="Registration of environment item: cause">
<t>
The following template specifies the IANA registration of a
sieve environment item specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve environment item
<vspace/>
Item name: cause
<vspace/>
Description:
The name of the action that caused the script to be invoked.
Its value is one of the following:
<list style="symbols">
<t>APPEND (for invocations resulting from APPEND or MULTIAPPEND)</t>
<t>COPY (for invocations resulting from COPY)</t>
<t>FLAG (for invocations resulting from flag changes)</t>
<t>ANNOTATE (for invocations resulting from new or changed annotations)</t>
</list>
<vspace/>
RFC number: this RFC
<vspace/>
Contact address:
<vspace/>
Barry Leiba <leiba@watson.ibm.com>
</t>
<t>
This information should be added to the list of sieve environment
item names given in the <xref target="Environment"/> extension.
</t>
</section>
<section anchor="iana-3" title="Registration of environment item: mailbox">
<t>
The following template specifies the IANA registration of a
sieve environment item specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve environment item
<vspace/>
Item name: mailbox
<vspace/>
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 new messages.
The value of this item is fixed when the script begins, and,
in particular, MUST NOT change as a result of any action, such as
"fileinto".
<vspace/>
RFC number: this RFC
<vspace/>
Contact address:
<vspace/>
Barry Leiba <leiba@watson.ibm.com>
</t>
<t>
This information should be added to the list of sieve environment
item names given in the <xref target="Environment"/> extension.
</t>
</section>
<section anchor="iana-4" title="Registration of environment item: changedflags">
<t>
The following template specifies the IANA registration of a
sieve environment item specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve environment item
<vspace/>
Item name: changedflags
<vspace/>
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 changed.
Otherwise, the value of this item MUST be the empty string.
<vspace/>
RFC number: this RFC
<vspace/>
Contact address:
<vspace/>
Barry Leiba <leiba@watson.ibm.com>
</t>
<t>
This information should be added to the list of sieve environment
item names given in the <xref target="Environment"/> extension.
</t>
</section>
<section anchor="iana-5" title="Registration of environment item: changedannotations">
<t>
The following template specifies the IANA registration of a
sieve environment item specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve environment item
<vspace/>
Item name: changedannotations
<vspace/>
Description:
If the script was invoked because of annotation changes to an existing message,
this contains the name(s) of the annotation(s) that have changed.
Otherwise, the value of this item MUST be the empty string.
<vspace/>
RFC number: this RFC
<vspace/>
Contact address:
<vspace/>
Barry Leiba <leiba@watson.ibm.com>
</t>
<t>
This information should be added to the list of sieve environment
item names given in the <xref target="Environment"/> extension.
</t>
</section>
<section anchor="iana-6" title="Registration of IMAP METADATA mailbox entry name">
<t>
The following template specifies the IANA registration of an
IMAP METADATA entry name specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: IMAP METADATA Registration
<vspace/>
Please register the following IMAP METADATA item:
<vspace/>
[x] Entry [ ] Attribute
<vspace/>
[x] Mailbox [ ] Server
<vspace/>
Name: /IMAPSieve/Script
<vspace/>
Description:
This entry name is used to define mailbox metadata associated
with IMAPSieve events for the associated mailbox. Specifically,
this specifies the Sieve script that will be invoked when IMAP events
occur on the specified mailbox.
<vspace/>
Content-type: text/plain; charset=utf-8
<vspace/>
RFC number: this RFC
<vspace/>
Contact person: Barry Leiba
<vspace/>
Contact email: leiba@watson.ibm.com
</t>
<t>
This information should be added to the list of IMAP METADATA
item names given in the <xref target="Metadata"/> extension.
</t>
</section>
<section anchor="iana-7" title="Registration of IMAP METADATA server entry name">
<t>
The following template specifies the IANA registration of an
IMAP METADATA entry name specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: IMAP METADATA Registration
<vspace/>
Please register the following IMAP METADATA item:
<vspace/>
[x] Entry [ ] Attribute
<vspace/>
[ ] Mailbox [x] Server
<vspace/>
Name: /IMAPSieve/Script
<vspace/>
Description:
This entry name is used to define metadata associated globally
with IMAPSieve events for the associated server. Specifically,
this specifies the Sieve script that will be invoked when IMAP events
occur on any mailbox in the server that does not have its own mailbox-level
/IMAPSieve/Script entry.
<vspace/>
Content-type: text/plain; charset=utf-8
<vspace/>
RFC number: this RFC
<vspace/>
Contact person: Barry Leiba
<vspace/>
Contact email: leiba@watson.ibm.com
</t>
<t>
This information should be added to the list of IMAP METADATA
item names given in the <xref target="Metadata"/> extension.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="Keywds">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="IMAP">
<front>
<title>Internet Message Access Protocol - Version 4rev1</title>
<author initials="M." surname="Crispin" fullname="Mark Crispin">
<organization>University of Washington</organization>
</author>
<date month="March" year="2003" />
</front>
<seriesInfo name="RFC" value="3501" />
</reference>
<reference anchor="Sieve">
<front>
<title>Sieve: An Email Filtering Language</title>
<author initials="P." surname="Guenther" fullname="Philip Guenther" role="editor">
<organization>Sendmail, Inc.</organization>
</author>
<author initials="T." surname="Showalter" fullname="Tim Showalter" role="editor">
<organization />
</author>
<date month="February" year="2007" />
</front>
<seriesInfo name="IESG Evaluation," value="draft-ietf-sieve-3028bis-12" />
</reference>
<reference anchor="Metadata">
<front>
<title>IMAP METADATA Extension</title>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization>Apple</organization>
</author>
<date month="February" year="2007" />
</front>
<seriesInfo name="work in progress," value="draft-daboo-imap-annotatemore-11" />
</reference>
<reference anchor="Environment">
<front>
<title>Sieve Email Filtering: Environment and Ihave Extensions</title>
<author initials="N." surname="Freed" fullname="Ned Freed">
<organization>Sun Microsystems</organization>
</author>
<date month="November" year="2006" />
</front>
<seriesInfo name="work in progress," value="draft-freed-sieve-environment-ihave-00" />
</reference>
<reference anchor="Annotate">
<front>
<title>IMAP ANNOTATE Extension</title>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization></organization>
</author>
<author initials="R." surname="Gellens" fullname="Randall Gellens">
<organization>QUALCOMM Incorporated</organization>
</author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC Editor Queue," value="draft-ietf-imapext-annotate-16" />
</reference>
<reference anchor="IMAP4Flags">
<front>
<title>Sieve Mail Filtering Language: IMAP flag Extension</title>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
<organization>Isode Limited</organization>
</author>
<date month="May" year="2006" />
</front>
<seriesInfo name="RFC Editor Queue," value="draft-ietf-sieve-imapflags-05" />
</reference>
<reference anchor="MultiAppend">
<front>
<title>Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension</title>
<author initials="M." surname="Crispin" fullname="Mark Crispin">
<organization>University of Washington</organization>
</author>
<date month="March" year="2003" />
</front>
<seriesInfo name="RFC" value="3502" />
</reference>
<reference anchor="Copy">
<front>
<title>Sieve Extension: Copying Without Side Effects</title>
<author initials="J." surname="Degener" fullname="Jutta Degener">
<organization>Sendmail, Inc.</organization>
</author>
<date month="October" year="2004" />
</front>
<seriesInfo name="RFC" value="3894" />
</reference>
</references>
<references title="Non-Normative References">
<reference anchor="Manage">
<front>
<title>A Protocol for Remotely Managing Sieve Scripts</title>
<author initials="T." surname="Martin" fullname="Tim Martin">
<organization>Mirapoint, Inc.</organization>
</author>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov" role="editor">
<organization>Isode Limited</organization>
</author>
<date month="November" year="2006" />
</front>
<seriesInfo name="work in progress," value="draft-martin-managesieve-07" />
</reference>
<reference anchor="Notify">
<front>
<title>Sieve Extension: Notifications</title>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov" role="editor">
<organization>Isode Limited</organization>
</author>
<author initials="B." surname="Leiba" fullname="Barry Leiba" role="editor">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<author initials="W." surname="Segmuller" fullname="Wolfgang Segmuller">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<author initials="T." surname="Martin" fullname="Tim Martin">
<organization>Mirapoint, Inc.</organization>
</author>
<date month="February" year="2007" />
</front>
<seriesInfo name="work in progress," value="draft-ietf-sieve-notify-07" />
</reference>
<reference anchor="EditHeader">
<front>
<title>Sieve Email Filtering: Editheader Extension</title>
<author initials="J." surname="Degener" fullname="Jutta Degener">
<organization></organization>
</author>
<author initials="P." surname="Guenther" fullname="Philip Guenther">
<organization>Sendmail, Inc.</organization>
</author>
<date month="November" year="2006" />
</front>
<seriesInfo name="work in progress," value="draft-ietf-sieve-editheader-07" />
</reference>
<reference anchor="Include">
<front>
<title>SIEVE Email Filtering: Include Extension</title>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization></organization>
</author>
<date month="June" year="2006" />
</front>
<seriesInfo name="work in progress," value="draft-daboo-sieve-include-05" />
</reference>
<reference anchor="Vacation">
<front>
<title>Sieve Email Filtering: Vacation Extension</title>
<author initials="T." surname="Showalter" fullname="Tim Showalter">
<organization></organization>
</author>
<author initials="N." surname="Freed" fullname="Ned Freed" role="editor">
<organization>Sun Microsystems</organization>
</author>
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC Editor Queue," value="draft-ietf-sieve-vacation-06" />
</reference>
<reference anchor="UIDPlus">
<front>
<title>Internet Message Access Protocol (IMAP) - UIDPLUS Extension</title>
<author initials="M." surname="Crispin" fullname="Mark Crispin">
<organization>University of Washington</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4315" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 18:43:11 |