Sieve Actions Registry: IANA Registry for Sieve Actions
A new IANA registry that lists every Sieve mail-filtering action and how it interacts with the others.
Melnikov, A. and K. Murchison, "IANA Registry for Sieve Actions", RFC 9122, DOI 10.17487/RFC9122, June 2023, <https://www.rfc-editor.org/info/rfc9122>.
@misc{rfc9122,
series = {Request for Comments},
number = 9122,
howpublished = {RFC 9122},
publisher = {RFC Editor},
doi = {10.17487/RFC9122},
url = {https://www.rfc-editor.org/info/rfc9122},
author = {A. Melnikov and K. Murchison},
title = {{IANA Registry for Sieve Actions}},
pagetotal = 9,
year = 2023,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 9122 Isode Ltd
Category: Standards Track K. Murchison
ISSN: 2070-1721 Fastmail
June 2023
IANA Registry for Sieve Actions
Abstract
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
https://www.rfc-editor.org/info/rfc9122.
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
(https://trustee.ietf.org/license-info) 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
1. Introduction
2. IANA Considerations
2.1. Sieve Actions Registration Template and Procedure
2.2. Initial Sieve Action Registry
3. Security Considerations
4. References
4.1. Normative References
4.2. Informative References
Appendix A. Acknowledgements
Authors' Addresses
1. Introduction
The Sieve Email Filtering Language [RFC5228] 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 [RFC5228] actions in order
to help developers and Sieve extension writers track interactions
between different extensions.
2. IANA Considerations
2.1. Sieve Actions Registration Template and Procedure
IANA has created the "Sieve Actions" registry (see Section 2.9 of
[RFC5228] 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 Section 2.10.1 of [RFC5228]), if any
Cancels Implicit Keep? Flag specifying whether the action cancels
the implicit keep (see Section 2.10.2 of [RFC5228])
Can Use With IMAP Events? Whether or not this action can be used
with IMAP events in Sieve [RFC6785]
Comments: Optional comment or comments
The registration procedure is Expert Review [RFC8126]. 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.
2.2. 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: [RFC5293]
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: [RFC5232] [RFC5229]
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: [RFC6558]
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: [RFC5293]
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: [RFC5228]
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: [RFC5703]
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: [RFC5429]
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: [RFC5703] [RFC5229]
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: [RFC5228] [RFC3894] [RFC5232] [RFC5490] [RFC9042]
[RFC8579]
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: [RFC5228] [RFC5232]
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: [RFC5435] [RFC8580]
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: [RFC5228] [RFC3894] [RFC6009] [RFC6134]
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: [RFC5429]
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: [RFC5232] [RFC5229]
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: [RFC5703]
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: [RFC5229]
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: [RFC5232] [RFC5229]
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: [RFC5230] [RFC6131] [RFC8580]
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
3. 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 (Section 2.2).
4. References
4.1. Normative References
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
January 2008, <https://www.rfc-editor.org/info/rfc5228>.
[RFC6785] Leiba, B., "Support for Internet Message Access Protocol
(IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,
November 2012, <https://www.rfc-editor.org/info/rfc6785>.
4.2. Informative References
[RFC3894] Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, DOI 10.17487/RFC3894, October 2004,
<https://www.rfc-editor.org/info/rfc3894>.
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, DOI 10.17487/RFC5229, January 2008,
<https://www.rfc-editor.org/info/rfc5229>.
[RFC5230] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
Vacation Extension", RFC 5230, DOI 10.17487/RFC5230,
January 2008, <https://www.rfc-editor.org/info/rfc5230>.
[RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags
Extension", RFC 5232, DOI 10.17487/RFC5232, January 2008,
<https://www.rfc-editor.org/info/rfc5232>.
[RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering:
Editheader Extension", RFC 5293, DOI 10.17487/RFC5293,
August 2008, <https://www.rfc-editor.org/info/rfc5293>.
[RFC5429] Stone, A., Ed., "Sieve Email Filtering: Reject and
Extended Reject Extensions", RFC 5429,
DOI 10.17487/RFC5429, March 2009,
<https://www.rfc-editor.org/info/rfc5429>.
[RFC5435] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
Martin, "Sieve Email Filtering: Extension for
Notifications", RFC 5435, DOI 10.17487/RFC5435, January
2009, <https://www.rfc-editor.org/info/rfc5435>.
[RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language --
Extensions for Checking Mailbox Status and Accessing
Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March
2009, <https://www.rfc-editor.org/info/rfc5490>.
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
Tests, Iteration, Extraction, Replacement, and Enclosure",
RFC 5703, DOI 10.17487/RFC5703, October 2009,
<https://www.rfc-editor.org/info/rfc5703>.
[RFC6009] Freed, N., "Sieve Email Filtering: Delivery Status
Notifications and Deliver-By Extensions", RFC 6009,
DOI 10.17487/RFC6009, October 2010,
<https://www.rfc-editor.org/info/rfc6009>.
[RFC6131] George, R. and B. Leiba, "Sieve Vacation Extension:
"Seconds" Parameter", RFC 6131, DOI 10.17487/RFC6131, July
2011, <https://www.rfc-editor.org/info/rfc6131>.
[RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally
Stored Lists", RFC 6134, DOI 10.17487/RFC6134, July 2011,
<https://www.rfc-editor.org/info/rfc6134>.
[RFC6558] Melnikov, A., Leiba, B., and K. Li, "Sieve Extension for
Converting Messages before Delivery", RFC 6558,
DOI 10.17487/RFC6558, March 2012,
<https://www.rfc-editor.org/info/rfc6558>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8579] Bosch, S., "Sieve Email Filtering: Delivering to Special-
Use Mailboxes", RFC 8579, DOI 10.17487/RFC8579, May 2019,
<https://www.rfc-editor.org/info/rfc8579>.
[RFC8580] Murchison, K. and B. Gondwana, "Sieve Extension: File
Carbon Copy (FCC)", RFC 8580, DOI 10.17487/RFC8580, May
2019, <https://www.rfc-editor.org/info/rfc8580>.
[RFC9042] Gondwana, B., Ed., "Sieve Email Filtering: Delivery by
MAILBOXID", RFC 9042, DOI 10.17487/RFC9042, June 2021,
<https://www.rfc-editor.org/info/rfc9042>.
Appendix A. Acknowledgements
Thank you to Barry Leiba, Donald Eastlake, Yoshiro Yoneya, and Murray
Kucherawy for reviews and feedback on this document.
Authors' Addresses
Alexey Melnikov
Isode Ltd
14 Castle Mews
Hampton
TW12 2NP
United Kingdom
Email: Alexey.Melnikov@isode.com
Kenneth Murchison
Fastmail US LLC
Suite 1201
1429 Walnut Street
Philadelphia, PA 19102
United States of America
Email: murch@fastmailteam.com
AI ELI5
On this page
§1Introduction
The Sieve Email Filtering Language (RFC 5228) is described as a popular language for filtering email at final delivery. Its popularity produced many Sieve extensions that can interact with each other in complex ways.
There was no easy way to find all actions defined by Sieve extensions published in RFCs. That made it hard for extension writers and implementers to foresee interactions between actions. This document creates a registry of Sieve actions to fix that.
Lots of people added new tricks to mail filters, and nobody had a full list. Now there is one.
§2.1The Registration Template
IANA has created the Sieve Actions registry. Actions from both RFCs and vendor-specific documentation may be registered, and this is encouraged. Each entry has these fields:
NameandDescriptionof the action.References: documents describing the action. Required for actions in RFCs, optional otherwise.Capabilities: the Sieve capabilities associated with the action.Action Interactions: interactions with other actions, if any (see Section 2.10.1 of RFC 5228).Cancels Implicit Keep?: whether the action cancels the implicit keep (Section 2.10.2 of RFC 5228).Can Use With IMAP Events?: whether it can be used with IMAP events in Sieve (RFC 6785).Comments: optional.
Each entry is like a trading card with the same boxes to fill in: name, what it does, and what it plays well with.
§2.1.1Registration Procedure
The procedure is Expert Review (RFC 8126). The designated expert only checks that the action name matches its documentation, that the description is accurate, that the correct documents are referenced, and that the list of relevant documents is as complete as possible.
The expert cannot reject a registration because of a personal dislike for the document defining an action, and should always err on the side of approving it, even if the documentation is incomplete. The same procedure is used to add a new reference or change the description of an existing entry.
A helper checks that the card is filled in correctly. The helper is not allowed to say no just because they do not like the idea.
§2.2The Initial Registry Contents
The registry starts with these actions: addheader, addflag, convert, deleteheader, discard, enclose, ereject, extracttext, fileinto, keep, notify, redirect, reject, removeflag, replace, set, setflag and vacation. Each entry cites the RFCs that define it, such as RFC 5228 for discard and keep.
An Action Interactions value of N/A means no restriction on using the action with any other action, though implementers still need to read the specifications for surprising behaviors. The Comments field is left out of these entries because none have comments.
The first list has eighteen tricks, from throwing a message away to sending an automatic vacation reply.
| Action | Cancels implicit keep | Usable with IMAP events |
|---|---|---|
| discard | Yes | Yes |
| fileinto | Yes | Yes |
| keep | Yes | Yes |
| redirect | Yes | Yes |
| reject | Yes | No |
| ereject | Yes | No |
| addheader | No | Yes |
| vacation | No | No |
§2.3Notable Interactions
Several entries show why the registry is useful. addheader, deleteheader and convert alter the message, so all subsequent tests and actions apply to the altered message. For enclose and replace, this holds for everything except redirect.
reject and ereject are incompatible with vacation, and are typically not permitted with actions that cause delivery, such as keep, fileinto and redirect. For fileinto and redirect, use of :copy suppresses cancellation of the implicit keep.
Some tricks do not mix. You cannot both refuse a message and say you are on vacation.
§3Security Considerations
The sole purpose of the document is to create the registry, so it creates no new security considerations for Sieve implementations. The RFC says the registry might improve the quality of specifications and implementations, including security aspects, by helping people track interactions between actions.
For security considerations of a particular action, readers should see the RFCs referenced for it in the registry.
A list does not make anything riskier. For the safety rules of one trick, read the paper that describes that trick.