Network Working Group K. Homme
Request for Comments: 5229 University of Oslo
Updates: 5228 January 2008
Category: Standards Track
Sieve Email Filtering: Variables Extension
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
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.
Homme Standards Track [Page 1]
RFC 5229 Sieve: Variables Extension January 2008
1. Introduction
This is an extension to the Sieve language defined by [SIEVE]. It
adds support for storing and referencing named data. The mechanisms
detailed in this document will only apply to Sieve scripts that
include a require clause for the "variables" extension. The require
clauses themselves are not affected by this extension.
Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS] and [ABNF]. The grammar builds on the grammar of
[SIEVE]. In this document, "character" means a character from the
ISO 10646 coded character set [ISO10646], which may consist of
multiple octets coded in [UTF-8], and "variable" is a named reference
to data stored or read back using the mechanisms of this extension.
2. Capability Identifier
The capability string associated with the extension defined in this
document is "variables".
3. Interpretation of Strings
This extension changes the semantics of quoted-string, multi-line-
literal and multi-line-dotstuff found in [SIEVE] to enable the
inclusion of the value of variables.
When a string is evaluated, substrings matching variable-ref SHALL be
replaced by the value of variable-name. Only one pass through the
string SHALL be done. Variable names are case insensitive, so "foo"
and "FOO" refer to the same variable. Unknown variables are replaced
by the empty string.
variable-ref = "${" [namespace] variable-name "}"
namespace = identifier "." *sub-namespace
sub-namespace = variable-name "."
variable-name = num-variable / identifier
num-variable = 1*DIGIT
Examples:
"&%${}!" => unchanged, as the empty string is an illegal
identifier
"${doh!}" => unchanged, as "!" is illegal in identifiers
The variable "company" holds the value "ACME". No other variables
are set.
"${full}" => the empty string
"${company}" => "ACME"
Homme Standards Track [Page 2]
RFC 5229 Sieve: Variables Extension January 2008
"${BAD${Company}" => "${BADACME"
"${President, ${Company} Inc.}"
=> "${President, ACME Inc.}"
The expanded string MUST use the variable values that are current
when control reaches the statement the string is part of.
Strings where no variable substitutions take place are referred to as
constant strings. Future extensions may specify that passing non-
constant strings as arguments to its actions or tests is an error.
Namespaces are meant for future extensions that make internal state
available through variables. These variables SHOULD be put in a
namespace whose first component is the same as its capability string.
Such extensions SHOULD state which, if any, of the variables in its
namespace are modifiable with the "set" action.
References to namespaces without a prior require statement for the
relevant extension MUST cause an error.
Tests or actions in future extensions may need to access the
unexpanded version of the string argument and, e.g., do the expansion
after setting variables in its namespace. The design of the
datatracker.ietf.org