IANA Registry for Sieve Actions Isode Ltd
14 Castle Mews Hampton TW12 2NP United Kingdom Alexey.Melnikov@isode.com
Fastmail US LLC
Suite 1201 1429 Walnut Street Philadelphia PA 19102 United States of America murch@fastmailteam.com
art extra Sieve The Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery. This document creates a registry for Sieve actions to help developers and Sieve extension writers track interactions between different extensions.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2023 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. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  IANA Considerations
    • .  Sieve Actions Registration Template and Procedure
    • .  Initial Sieve Action Registry
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • .  Acknowledgements
  • Authors' Addresses
Introduction The Sieve Email Filtering Language is a popular email filtering language used upon final mail delivery. The popularity of Sieve resulted in a myriad of Sieve extensions that can interact with each other in wonderful and complex ways. Currently, there is no easy way to find out all actions defined by Sieve extensions published in RFCs, which makes it quite difficult for Sieve extension writers and Sieve implementation developers to foresee interactions between Sieve actions. This document creates a registry for Sieve actions in order to help developers and Sieve extension writers track interactions between different extensions.
IANA Considerations
Sieve Actions Registration Template and Procedure IANA has created the "Sieve Actions" registry (see for details on Sieve actions). Registration of actions specified in both RFCs and vendor-specific documentation is allowed and encouraged. The registration template contains the following:
Name:
Name of the action
Description:
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)
Capabilities:
Name of one or more Sieve capabilities associated with the Sieve action being registered
Action Interactions:
Interactions with other Sieve actions (as described in ), if any
Cancels Implicit Keep?
Flag specifying whether the action cancels the implicit keep (see )
Can Use With IMAP Events?
Whether or not this action can be used with IMAP events in Sieve
Comments:
Optional comment or comments
The registration procedure is Expert Review . The designated expert only checks that the name of the action being registered matches documentation, the description field is accurate, the correct documents are referenced, and the list of relevant documents is as complete as possible. The designated expert can't reject a registration because of a personal dislike for the document defining an action and should always err on the side of approving the registration, even if documentation is not complete. The same registration procedure is used to add a new reference or to change the description field of an existing registration.
Initial Sieve Action Registry The following registrations are used to initialize the "Sieve Actions" registry. Note that when the relevant "Action Interactions" entry is marked "N/A", it means that there is no restriction on use of the corresponding action with any other action; however, implementors still need to read the one or more corresponding specifications to determine if there are any surprising behaviors. Also note that the "Comments" field of the IANA registration template is omitted from these registrations, as none of them currently have any comments.
Name:
addheader
Description:
Add a header field to the existing message header
References:
Capabilities:
"editheader"
Action Interactions:
All subsequent tests and actions apply to the altered message
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
addflag
Description:
Add IMAP flags to a list of IMAP flags that would be set on the message if it gets delivered to a mailbox
References:
Capabilities:
"imap4flags", "variables"
Action Interactions:
N/A
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
convert
Description:
Convert body parts from one MIME type to another
References:
Capabilities:
"convert"
Action Interactions:
All subsequent tests and actions apply to the altered message
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
deleteheader
Description:
Remove a header field from the existing message header
References:
Capabilities:
"editheader"
Action Interactions:
All subsequent tests and actions apply to the altered message
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
discard
Description:
Silently throw away the message
References:
Capabilities:
N/A
Action Interactions:
N/A
Cancels Implicit Keep?
Yes
Can Use with IMAP Events?
Yes
Name:
enclose
Description:
Enclose a message as an attachment to a new message
References:
Capabilities:
"enclose"
Action Interactions:
All subsequent tests and actions except "redirect" apply to the altered message
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
ereject
Description:
Refuse delivery of the message
References:
Capabilities:
"ereject"
Action Interactions:
This action is incompatible with the "vacation" action. Typically is not permitted with actions that cause mail delivery, such as "keep", "fileinto", and "redirect"
Cancels Implicit Keep?
Yes
Can Use with IMAP Events?
No
Name:
extracttext
Description:
Store text of a MIME part into a variable
References:
Capabilities:
"extracttext", "variables"
Action Interactions:
N/A
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
fileinto
Description:
Deliver the message into the specified mailbox
References:
Capabilities:
"fileinto", "copy", "imap4flags", "mailbox", "mailboxid", "special-use"
Action Interactions:
Use of :copy suppresses cancellation of implicit keep
Cancels Implicit Keep?
Yes
Can Use with IMAP Events?
Yes
Name:
keep
Description:
File the message into the user's main mailbox
References:
Capabilities:
"imap4flags"
Action Interactions:
N/A
Cancels Implicit Keep?
Yes
Can Use with IMAP Events?
Yes
Name:
notify
Description:
Send a notification to a user
References:
Capabilities:
"enotify", "fcc"
Action Interactions:
N/A
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
redirect
Description:
Send (forward) the message to another user
References:
Capabilities:
"copy", "redirect-dsn", "redirect-deliverby", "extlists"
Action Interactions:
Use of :copy suppresses cancellation of implicit keep
Cancels Implicit Keep?
Yes
Can Use with IMAP Events?
Yes
Name:
reject
Description:
Refuse delivery of the message
References:
Capabilities:
"reject"
Action Interactions:
This action is incompatible with the "vacation" action. Typically is not permitted with actions that cause mail delivery, such as "keep", "fileinto", and "redirect"
Cancels Implicit Keep?
Yes
Can Use with IMAP Events?
No
Name:
removeflag
Description:
Remove IMAP flags from a list of IMAP flags that would be set on the message if it gets delivered to a mailbox
References:
Capabilities:
"imap4flags", "variables"
Action Interactions:
N/A
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
replace
Description:
Replace a MIME part
References:
Capabilities:
"replace"
Action Interactions:
All subsequent tests and actions except "redirect" apply to the altered message
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
set
Description:
Store a value in a variable
References:
Capabilities:
"variables"
Action Interactions:
N/A
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
setflag
Description:
Set IMAP system flags or keywords that would be set on the message if it gets delivered to a mailbox
References:
Capabilities:
"imap4flags", "variables"
Action Interactions:
N/A
Cancels Implicit Keep?
No
Can Use with IMAP Events?
Yes
Name:
vacation
Description:
Implement a vacation autoresponder
References:
Capabilities:
"vacation", "vacation-seconds", "fcc"
Action Interactions:
This action is incompatible with "reject" and "ereject" actions
Cancels Implicit Keep?
No
Can Use with IMAP Events?
No
Security Considerations The sole purpose of this document is to create the "Sieve Actions" registry; therefore, 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; therefore, it might improve the quality of specifications and implementations, including security aspects. For security considerations related to particular actions, see the one or more RFCs referenced for the action in question in the "Sieve Actions" registry ().
References Normative References Sieve: An Email Filtering Language This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK] Support for Internet Message Access Protocol (IMAP) Events in Sieve 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 IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK] Informative References Sieve Extension: Copying Without Side Effects The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior. This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS-TRACK] Sieve Email Filtering: Variables Extension In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK] Sieve Email Filtering: Vacation Extension This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK] Sieve Email Filtering: Imap4flags Extension Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK] Sieve Email Filtering: Editheader Extension This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. [STANDARDS-TRACK] Sieve Email Filtering: Reject and Extended Reject Extensions This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028. A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible. The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. [STANDARDS-TRACK] Sieve Email Filtering: Extension for Notifications Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK] The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK] Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK] Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively. The "redirect-dsn" and "redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK] Sieve Vacation Extension: "Seconds" Parameter This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. [STANDARDS-TRACK] Sieve Extension: Externally Stored Lists The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server. This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK] Sieve Extension for Converting Messages before Delivery This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK] Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Sieve Email Filtering: Delivering to Special-Use Mailboxes The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute. Sieve Extension: File Carbon Copy (FCC) The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively. Sieve Email Filtering: Delivery by MAILBOXID The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming. This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes.
Acknowledgements Thank you to , , , and for reviews and feedback on this document.
Authors' Addresses Isode Ltd
14 Castle Mews Hampton TW12 2NP United Kingdom Alexey.Melnikov@isode.com
Fastmail US LLC
Suite 1201 1429 Walnut Street Philadelphia PA 19102 United States of America murch@fastmailteam.com