| Internet-Draft | IANA registry for Sieve actions | March 2022 |
| Melnikov & Murchison | Expires 8 September 2022 | [Page] |
This document creates a registry of Sieve (RFC 5228) actions in order to help developers and Sieve extension writers track interactions between different extensions.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 September 2022.¶
Copyright (c) 2022 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.¶
Sieve Email Filtering Language [RFC5228] 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 [RFC5228] actions in order to help developers and Sieve extension writers track interactions between different extensions.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
IANA is requested to create a new registry for Sieve actions (see Section 2.9 of [RFC5228] 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:¶
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.¶
| Name | Description | References | Capabilities | Interactions | Cancels Implicit Keep? | Use with IMAP Events? | Comments |
|---|---|---|---|---|---|---|---|
| addheader | Add a header field to the existing message header | [RFC5293] | "editheader" | All subsequent tests and actions apply to the altered message | N | ||
| addflag | Add flags to a list of IMAP flags | [RFC5232], [RFC5229] | "imap4flags", "variables" | N | |||
| convert | Convert body parts from one MIME type to another | [RFC6558] | "convert" | All subsequent tests and actions apply to the altered message | N | ||
| deleteheader | Remove a header field from the existing message header | [RFC5293] | "editheader" | All subsequent tests and actions apply to the altered message | N | ||
| discard | Silently throw away the message | [RFC5228] | Compatible with all other actions | Y | |||
| enclose | Enclose a message as an attachment to a new message | [RFC5703] | "enclose" | All subsequent tests and actions, except "redirect" apply to the altered message | N | ||
| ereject | Refuse delivery of the message | [RFC5429] | "ereject" | Y | N | ||
| extracttext | Store text of a MIME part into a variable | [RFC5703], [RFC5229] | "extracttext", "variables" | N | |||
| fileinto | Deliver the message into the specified mailbox | [RFC5228], [RFC3894], [RFC5232], [RFC5490], [RFC9042], [RFC8579] | "fileinto", "copy", "imap4flags", "mailbox", "mailboxid", "special-use" | Use of :copy suppresses cancelation of implicit keep | Y | ||
| keep | File message into the user's main mailbox | [RFC5228], [RFC5232] | "imap4flags" | Y | |||
| notify | Send a notification to a user | [RFC5435], [RFC8580] | "enotify", "fcc" | N | |||
| redirect | Send (forward) the message to another user | [RFC5228], [RFC3894], [RFC6009], [RFC6134] | "copy", "redirect-dsn", "redirect-deliverby", "extlists" | Use of :copy suppresses cancelation of implicit keep | Y | ||
| reject | Refuse delivery of the message | [RFC5429] | "reject" | Y | N | ||
| removeflag | Remove flags from a list of IMAP flags | [RFC5232], [RFC5229] | "imap4flags", "variables" | N | |||
| replace | Replace a MIME part | [RFC5703] | "replace" | All subsequent tests and actions, except "redirect" apply to the altered message | N | ||
| set | Store a value in a variable | [RFC5229] | "variables" | N | |||
| setflag | Set IMAP system flags or keywords | [RFC5232], [RFC5229] | "imap4flags", "variables" | N | |||
| vacation | Vacation autoresponder | [RFC5230], [RFC6131], [RFC8580] | "vacation", "vacation-seconds", "fcc" | N | N |
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.¶