rfc-5260

Sieve Email Filtering: Date and Index Extensions

N. Freed
date2008-07 streamIETF wgnon working group statusPROPOSED STANDARD pages13 canonicalhttps://www.rfc-editor.org/rfc/rfc5260 doi10.17487/RFC5260 errataview
This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]

Extracted elements (23)

design-rationale §4

The date test is restricted to a single header field at a time (defaulting to the first occurrence) to simplify the test and keep its meaning clear. The 'index' extension is provided as an explicit opt-in for those needing multi-occurrence access.

email

design-rationale §4.3

The 'julian' date-part uses an integer representation (Modified Julian Day), making i;ascii-numeric almost certainly the best comparator. Other numeric date-parts (year, month, day, hour, minute, second, weekday) use fixed-width string integers compatible with i;octet, i;ascii-casemap, and i;ascii-numeric equivalently.

email

design-rationale §4.3

The 'std11' date-part is provided as a way to obtain date/time values in a format suitable for inclusion in email header fields, not for comparison. The wide range of possible syntaxes makes std11 a poor choice for comparisons, though i;ascii-casemap must be used if comparison is attempted.

email

interoperability-note §4

The date test can only be applied to a single header field at a time; when multiple fields with the same name are present, only the first found is used unless the 'index' extension modifies this behavior. The header and address tests are not subject to this single-field restriction.

email

interoperability-note §6

The :index argument counts only separate header fields, not multiple occurrences within a single field. It cannot be used to select a specific address within an address list inside one header field.

email

interoperability-note §6

When header or address tests specify more than one header field name, all named header fields are counted in the order specified by the header-list for purposes of :index counting.

email

normative-requirement §5 MUST

All currentdate tests within a single Sieve script MUST refer to the same point in time during execution of the script, ensuring consistent behavior across multiple currentdate evaluations.

email

normative-requirement §4.1 MUST

If both :zone and :originalzone arguments are omitted from the date test, the local time zone MUST be used.

email

normative-requirement §4 MAY

Implementations MAY support extraction of date and time information in RFC 2822 or other formats appearing in positions other than the end of a header field. When a field contains more than one date/time value, the last one SHOULD be used.

email

normative-requirement §4 MUST

Implementations MUST support extraction of RFC 2822 date-time information that either constitutes the entire header field value or appears at the end of a header field following a semicolon (e.g., Received:).

email

normative-requirement §4.2 MUST

In the restricted ISO 8601 format used for the 'iso8601' date-part, the letters 'T' and 'Z' MUST be in upper case, and a time zone offset of zero MUST be represented by 'Z' and not '+00:00'.

email

normative-requirement §4.1 MUST NOT

It is an error to specify both :zone and :originalzone in the same date test invocation; only one may be present.

email

normative-requirement §6 MUST NOT

Specifying :last without :index is an error; :last is only valid when accompanied by an :index argument.

email

normative-requirement §4.1 MUST

The time-zone value for the :zone argument MUST be an offset relative to UTC in the format (+/-)4DIGIT, matching RFC 2822 time zone offset syntax rather than ISO 8601 format.

email

protocol-element §5

The 'currentdate' test operates on the date and time when the Sieve script is executed rather than on a value extracted from the message header. It accepts the same :zone and date-part arguments as the date test.

email

protocol-element §4

The 'date' extension introduces a date test that extracts and matches date/time information from RFC 2822 structured header fields. The test shifts the extracted value to a specified time zone, then compares a selected date-part against a key-list using a comparator.

email

protocol-element §4.2

The date-part argument selects a specific component of the extracted date/time value for comparison. Supported values include: year, month, day, date (yyyy-mm-dd), julian (Modified Julian Day), hour, minute, second, time (hh:mm:ss), iso8601, std11, zone, and weekday (0=Sunday through 6=Saturday).

email

protocol-element §6

The 'index' extension adds optional :index <fieldno> and :last tagged arguments to the header, address, and date tests. :index selects a specific occurrence of a header field (counting from 1); :last reverses the count so that 1 denotes the last occurrence.

email

protocol-element §4.2

The 'julian' date-part returns the Modified Julian Day — the number of days since 00:00 UTC on November 17, 1858 (Gregorian), equal to the regular Julian Day minus 2400000.5. Appendix A provides C routines for conversion.

email

registry §8

IANA registration of Sieve capability 'date': grants the date extension the ability to test date and time values in header fields, as defined in RFC 5260.

email, registry

registry §8

IANA registration of Sieve capability 'index': provides a means to limit header and address tests to specific instances when more than one field of a given type is present, as defined in RFC 5260.

email, registry

security-consideration §7

Date and time information in header fields can be easily forged. The Date: field is inserted by the sender and may be altered at any point, while the uppermost Received: field is inserted by the local mail system and is harder for the sender or an intermediary to falsify.

email, security

security-consideration §7

Use of the currentdate test makes script behavior inherently less predictable and harder to analyze, which may have consequences for systems that use script analysis to detect problematic scripts.

email, security