Sieve Email Filtering: Environment Extension
Extracted elements (20)
Groups of related environment items defined in an RFC MAY use a common name prefix of the form 'name.' to namespace related items, while vendor-defined items use 'vnd.' to avoid conflicts with standardized names.
The environment test is designed to allow Sieve scripts to behave differently when moved between systems or operated in different contexts, without requiring system-specific script variants. The test fails gracefully on unknown items rather than erroring, so scripts can be written portably.
The ':count' match type from the 'relational' extension (RFC 5231) works with environment tests: the count is 0 if the environment information returned is the empty string, or 1 otherwise.
Extensions designed for interoperable use SHOULD be defined in standards-track or experimental RFCs. Vendor-defined items MUST have a name beginning with the 'vnd.' prefix.
Implementations SHOULD support as many of the initial standard environment items as possible. Additional standardized items can only be defined in standards-track or experimental RFCs.
Items not defined in a standards-track or experimental RFC MUST have a name beginning with the 'vnd.' prefix, followed by the vendor or product name, such as 'vnd.acme.rocket-sled-status'.
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, allowing scripts to handle nonexistent items gracefully.
The 'domain' environment item returns the primary DNS domain associated with the Sieve execution context, usually but not always a proper suffix of the host name.
The 'environment' extension adds a new 'environment' test to Sieve that retrieves a named item of environment information and matches it against a key-list. The test succeeds if a match occurs; the default match type is ':is' and the default comparator is 'i;ascii-casemap'.
The 'host' environment item returns the fully-qualified domain name of the host where the Sieve script is executing.
The 'location' environment item indicates the type of service evaluating the script: 'MTA' (Message Transfer Agent), 'MDA' (Mail Delivery Agent), 'MUA' (Mail User Agent), or 'MS' (Message Store).
The 'name' environment item returns the product name associated with the Sieve interpreter, and 'version' returns the product version, whose meaning is product-specific and should be interpreted in the context of 'name'.
The 'phase' environment item indicates the point relative to final delivery where the script is evaluated: 'pre', 'during', or 'post', referring to processing before, during, and after final delivery.
The 'remote-host' environment item provides the FQDN of the remote SMTP/LMTP/Submission client, if applicable and available; returns the empty string if the information cannot be obtained.
The 'remote-ip' environment item provides the IP address of the remote SMTP/LMTP/Submission client in IPv4-address-literal, IPv6-address-literal, or General-address-literal format as defined in RFC 2821 Section 4.1.3.
Vendor-defined environment items use names beginning with 'vnd.' and are registered with IANA to prevent conflicts, but are not defined by Internet standards or RFCs.
This document establishes a new IANA registry for Sieve environment item names. Items may be registered on a first-come, first-served basis. The registry is initialized with the eight standard items: domain, host, location, name, phase, remote-host, remote-ip, and version.
This document registers the 'environment' capability with IANA in the Sieve extensions registry, enabling Sieve scripts to declare use of the environment extension via the capability string 'environment'.
The environment extension may reveal details about service provider or enterprise infrastructure, such as host names and IP addresses, to scripts that may be crafted by users or attackers.
The 'remote-host' item may be determined via a PTR DNS lookup on the client IP address, which comes from an untrusted source. Testing 'remote-host' against a domain pattern (e.g., '*.example.com') is not a reliable way to verify message origin because anyone controlling PTR records can set them to any domain.