Sieve Email Filtering: Variables Extension
RFC 5229

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

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.