rfc-5232

Sieve Email Filtering: Imap4flags Extension

A. Melnikov
date2008-01 streamIETF areaapp wgsieve statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc5232 doi10.17487/RFC5232 errataview
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]

Extracted elements (25)

design-rationale §2

A string containing a space-separated list of flag names is defined as equivalent to a string list of those flags. This design choice is explicitly intended to simplify amalgamation of multiple flag lists in scripts.

email

design-rationale §5

The :flags tagged argument passes only the listed flags to the filed copy; the document explicitly does not dictate whether the Sieve interpreter implements flag setting as an IMAP client or via direct mailstore access, preserving implementation flexibility.

email

design-rationale §4

The hasflag test defaults to ':is' match type with 'i;ascii-casemap' comparator, matching the case-insensitive comparison semantics defined for IMAP flags by RFC 3501, ensuring behavioral consistency with the underlying IMAP protocol.

email

interoperability-note §6

The extension operates only on the message currently being processed by the Sieve interpreter; it does not affect messages generated as side effects of any action or any other message already in the mailstore.

email

interoperability-note §1

The imap4flags extension can be used with or without the 'variables' extension (RFC 5229). When 'variables' is not required, the explicit variable name parameter is prohibited; when it is required, explicit variable names may be used in all flag manipulation actions and tests.

email

interoperability-note §6

The imap4flags extension does not change the implicit keep behavior defined in the base Sieve specification (RFC 5228, Section 2.10.2); the implicit keep uses the current value of the internal variable for flags.

email

interoperability-note §4

The 'relational' extension (RFC 5231) adds a ':count' match type usable with hasflag; the :count of a variable returns the number of distinct flags it contains, and the count of a list of variables is the sum of individual counts.

email

normative-requirement §2 MUST

A Sieve interpreter MUST ignore empty strings (i.e., "") in a list-of-flags parameter.

email

normative-requirement §1 MUST

All conformant implementations MUST implement all three Sieve actions (setflag, addflag, removeflag), the hasflag test, and the :flags tagged argument described in this document.

email

normative-requirement §2 MUST

If a flag validity check fails, the flag MUST be ignored. Any flags that cannot be set in IMAP (such as \Recent) MUST be ignored if included in a flag list.

email

normative-requirement §3.3 MUST

If an implementation does not perform automatic duplicate elimination, it MUST remove all occurrences of the flags specified in the second parameter to removeflag.

email

normative-requirement §3 MUST NOT

Scripts MUST NOT make assumptions about the ordering of flags in lists or the preservation of their case; implementations MAY reorder, change case, or remove duplicates.

email

normative-requirement §2 MUST

Spaces MUST always be allowed as delimiters in flag list strings; multiple spaces between flag names MUST be treated as a single space, and leading and trailing spaces MUST be ignored.

email

normative-requirement §5 MUST

The Sieve interpreter MUST ignore all flags that it cannot store permanently, and MUST NOT treat failure to store any flag as a runtime failure to execute the Sieve script.

email

normative-requirement §2 SHOULD

The Sieve interpreter SHOULD check the list of flags for validity as described by the IMAP ABNF; non-ASCII characters are not allowed in flag names.

email

normative-requirement §3 MUST

When keep/fileinto is used multiple times in a script and duplicate message elimination is performed, the last flag list value MUST win.

email

normative-requirement §1 MUST NOT

When the 'variables' extension is not enabled, the explicit variable name parameter to setflag/addflag/removeflag/hasflag MUST NOT be used and MUST cause an error according to the base Sieve specification.

email

protocol-element §3.2

The addflag action adds flags to an existing flag set without replacing previously set flags; multiple occurrences are treated additively. Usage: addflag [<variablename: string>] <list-of-flags: string-list>.

email

protocol-element §5

The :flags tagged argument to keep and fileinto specifies the flag set to apply when delivering the message to the target mailbox; if omitted, the current value of the internal variable is used. Usage: ':flags' <list-of-flags: string-list>.

email

protocol-element §4

The hasflag test evaluates to true if any of the named variables (or the internal variable if omitted) contains any of the specified flag names. The default match type is ':is' and the default comparator is 'i;ascii-casemap'. Usage: hasflag [MATCH-TYPE] [COMPARATOR] [<variable-list: string-list>] <list-of-flags: string-list>.

email

protocol-element §1

The internal variable is an implicit string variable maintained by the Sieve engine that holds the default set of flags; it starts with an empty value and is used by keep, implicit keep, and fileinto when the :flags tagged argument is not specified.

email

protocol-element §3.3

The removeflag action removes specified flags from an existing flag set; calling it with a flag not previously set is not an error and is ignored. Usage: removeflag [<variablename: string>] <list-of-flags: string-list>.

email

protocol-element §3.1

The setflag action replaces any previously set flags on a variable (or the internal variable if no variable name is specified) with a new list of IMAP system flags or keywords. Usage: setflag [<variablename: string>] <list-of-flags: string-list>.

email

registry §8

This document registers the 'imap4flags' capability name in the IANA Sieve extensions registry, with description 'Adds actions and tests for manipulating IMAP flags', contact [email protected].

email, registry

security-consideration §7

The extension intentionally does not allow setting IMAP flags on an arbitrary message in the IMAP message store; it is scoped exclusively to the message currently being delivered. The document states it introduces no additional security concerns beyond those in RFC 3501, RFC 5228, and RFC 5229.

email, security