Sieve Email Filtering: Variables Extension
RFC 5229
Document | Type |
RFC - Proposed Standard
(January 2008; Errata)
Updated by RFC 5173
Updates RFC 5228
|
|
---|---|---|---|
Author | Kjetil Homme | ||
Last updated | 2020-01-21 | ||
Replaces | draft-homme-sieve-variables | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5229 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | daboo@isamet.com, alexey.melnikov@isode.com |
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 implementation should allow this. 3.1. Quoting and Encoded Characters The semantics of quoting using backslash are not changed: backslash quoting is resolved before doing variable substitution. Similarly, encoded character processing (see Section 2.4.2.4 of [SIEVE]) is performed before doing variable substitution, but after quoting. Examples: "${fo\o}" => ${foo} => the expansion of variable foo.Show full document text