Sieve Email Filtering: Environment Extension
RFC 5183
Document | Type |
RFC - Proposed Standard
(May 2008; No errata)
Was draft-freed-sieve-environment (individual in app area)
|
|
---|---|---|---|
Author | Ned Freed | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5183 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Chris Newman | ||
IESG note | Alexey Melnikov is document shepherd | ||
Send notices to | alexey.melnikov@isode.com |
Network Working Group N. Freed Request for Comments: 5183 Sun Microsystems Category: Standards Track May 2008 Sieve Email Filtering: Environment 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 This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. 1. Introduction Sieve [RFC5228] is a language for filtering email messages at or around the time of final delivery. It is designed to be implementable on either a mail client or mail server. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol [RFC3501] servers, as it has no user-controlled loops or the ability to run external programs. Although Sieve is intended to be independent of access protocol, mail architecture, and operating system, in some cases it is useful to allow scripts to access information about their execution context. The "environment" extension provides a new environment test that can be used to implement scripts that behave differently when moved from one system to another, when messages arrive from different remote sources or when otherwise operated in different contexts. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Freed Standards Track [Page 1] RFC 5183 Sieve Environment Extension May 2008 The terms used to describe the various components of the Sieve language are taken from Section 1.1 of [RFC5228]. This document refers to the ABNF productions IPv4-address-literal, IPv6-address-literal, and General-address-literal defined in Section 4.1.3 of [RFC2821]. The location item makes use of standard terms for email service components. Additional information and background on these terms can be found in [EMAIL-ARCH]. 3. Capability Identifiers The capability string associated with the extension defined in this document is "environment". 4. Environment Test Usage: environment [COMPARATOR] [MATCH-TYPE] <name: string> <key-list: string-list> The environment test retrieves the item of environment information specified by the name string and matches it to the values specified in the key-list argument. The test succeeds if a match occurs. The type of match defaults to ":is" and the default comparator is "i;ascii-casemap". The current message is not a direct source of information for the environment test; the item of information specified by the name string is extracted from the script's operating environment and the key-list argument comes from the script. The environment test MUST fail unconditionally if the specified information item does not exist. A script MUST NOT fail with an error if the item does not exist. This allows scripts to be written that handle nonexistent items gracefully. In particular, the test: if environment :contains "item" "" { ... } only succeeds if "item" is known to the implementation, and always succeeds if it is. The "relational" extension [RFC5231] adds a match type called ":count". The count of an environment test is 0 if the environment information returned is the empty string, or 1 otherwise. Freed Standards Track [Page 2] RFC 5183 Sieve Environment Extension May 2008 Environment items can be standardized or vendor-defined. An IANA registry is defined for both types of items. Extensions designed for interoperable use SHOULD be defined in standards track or experimental RFCs. 4.1. Initial Standard Environment Items The initial set of standardized environment items is as follows: "domain" => The primary DNS domain associated with the Sieve execution context, usually but not always a proper suffix of the host name. "host" => The fully-qualified domain name of the host whereShow full document text