IANA registry for Sieve actions
Isode Ltd
14 Castle Mews
Hampton
Middlesex
TW12 2NP
UK
Alexey.Melnikov@isode.com
Fastmail US LLC
1429 Walnut Street - Suite 1201
Philadelphia
PA
19102
USA
murch@fastmailteam.com
Sieve
This document creates a registry of Sieve (RFC 5228) actions in order to help developers and
Sieve extension writers track interactions between different extensions.
Sieve Email Filtering Language is a popular email filtering language
used upon final mail delivery. Popularity of Sieve resulted in a myriad of Sieve extensions
that can interact with each other in wonderful and complex ways.
There is currently no easy way to find out all actions defined by Sieve extensions published
in RFCs, which make it quite difficult for Sieve extension writers and Sieve implementation
developers to forsee interactions between Sieve actions.
This document creates a registry of Sieve actions in order to help developers and
Sieve extension writers track interactions between different extensions.
IANA is requested to create a new registry for Sieve actions (see Section 2.9 of
for details on Sieve actions). Registration of both actions specified in IETF Stream RFCs
and vendor specific actions is allowed and encouraged.
The registration template contains:
name of the action;
short description;
references: one or more documents describing the action and
any significant updates to its definition
(this field is required for actions described in RFCs and
is optional otherwise);
name(s) of Sieve capabilit(ies) associated with the Sieve
action being registered;
interactions with other Sieve actions (as described in Section 2.10.1 of ), if any;
flag specifying whether the action cancels the implicit
keep (see Section 2.10.2 of );
whether or not this action can be used with IMAP events in
Sieve ();
optional comment.
Registration procedure for this registry is Expert Review.
The Designated Expert only checks that the name of the action being registered
matches documentation, that the description field is accurate,
that the correct documents are referenced and that the list of
relevant documents is as complete as possible.
The Designated Expert can’t reject a registration based on personal dislike of
the document defining an action and should always err on the side of registering,
even if documentation is not complete.
Addition of a new reference to an existing registration or change to the description field goes through
the same registration procedure as a new registration.
The following table is used to initialize the actions
registry. Note that when "Action Interactions" cell is empty it means that there is no restriction
on use of the corresponding action with any other action, however implementors still need to read
the corresponding specification(s) to see if there is are any surprising behaviour.
Name
Description
References
Capabilities
Action Interactions
Cancels Implicit Keep?
Can use with IMAP Events?
Comments
addheader
Add a header field to the existing message header
"editheader"
All subsequent tests and actions apply to the altered message
No
addflag
Add IMAP flags to a list of IMAP flags that would be set on the message if it gets delivered to a mailbox
,
"imap4flags", "variables"
No
convert
Convert body parts from one MIME type to another
"convert"
All subsequent tests and actions apply to the altered message
No
deleteheader
Remove a header field from the existing message header
"editheader"
All subsequent tests and actions apply to the altered message
No
discard
Silently throw away the message
Yes
enclose
Enclose a message as an attachment to a new message
"enclose"
All subsequent tests and actions, except "redirect" apply
to the altered message
No
ereject
Refuse delivery of the message
"ereject"
Incompatible with "vacation" action. Typically is not permitted with actions that cause mail delivery,
such as "keep", "fileinto", and "redirect".
Yes
No
extracttext
Store text of a MIME part into a variable
,
"extracttext", "variables"
No
fileinto
Deliver the message into the specified mailbox
, ,
, ,
,
"fileinto", "copy", "imap4flags", "mailbox", "mailboxid",
"special-use"
Use of :copy suppresses cancelation of implicit keep
Yes
keep
File message into the user's main mailbox
,
"imap4flags"
Yes
notify
Send a notification to a user
,
"enotify", "fcc"
No
redirect
Send (forward) the message to another user
, ,
,
"copy", "redirect-dsn", "redirect-deliverby", "extlists"
Use of :copy suppresses cancelation of implicit keep
Yes
reject
Refuse delivery of the message
"reject"
Incompatible with "vacation" action. Typically is not permitted with actions that cause mail delivery,
such as "keep", "fileinto", and "redirect".
Yes
No
removeflag
Remove IMAP flags from a list of IMAP flags that would be set on the message if it gets delivered to a mailbox
,
"imap4flags", "variables"
No
replace
Replace a MIME part
"replace"
All subsequent tests and actions, except "redirect" apply
to the altered message
No
set
Store a value in a variable
"variables"
No
setflag
Set IMAP system flags or keywords that would be set on the message if it gets delivered to a mailbox
,
"imap4flags", "variables"
No
vacation
Vacation autoresponder
, ,
"vacation", "vacation-seconds", "fcc"
Incompatible with "reject" and "ereject" actions.
No
No
The sole purpose of this document is to create a new IANA registry,
so it doesn't create new security considerations for Sieve implementations.
The new registry should help Sieve extension writers and Sieve implementors
track interactions between different Sieve actions, so it might improve quality
of specifications and implementations, including security aspects.