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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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
Show full document text