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" 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" 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" 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.

TBD.