rfc-5233

Sieve Email Filtering: Subaddress Extension

K. Murchison

date2008-01 streamIETF areaapp wgsieve statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc5233 doi10.17487/RFC5233 errataview

On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+[email protected]"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]

obsoletes

rfc-3598 — Sieve Email Filtering -- Subaddress Extension

Extracted elements (11)

design-rationale §4

The ':user' and ':detail' address parts are intentionally subject to the same rules and restrictions as the standard address parts defined in RFC 5228 Section 2.7.4, ensuring consistency with the base Sieve language.

interoperability-note §4

If the separator character sequence occurs more than once in the local-part, the logic used to split the address is implementation-defined and usually dependent on the format used by the encompassing mail system.

interoperability-note §4

The envelope 'to' address is the preferred address to examine for subaddress information when sorting messages by recipient, as it is the definitive reason a message is processed by a given sieve script. Mailing lists, aliases, and virtual domains may make the envelope the only reliable source of detail information.

interoperability-note §4

Using the subaddress extension on foreign addresses (such as the envelope 'from' address or originator header fields) may lead to inconsistent or incorrect results because subaddress encoding is site- and implementation-specific.

normative-requirement §4 MUST

Implementations MUST make sure that the encoding method used for detailed addresses matches that which is used and/or allowed by the encompassing mail system, otherwise unexpected results might occur.

protocol-element §4

The ':detail' argument specifies the detail sub-part of the local-part of an address. If no detail sub-part is encoded, the address fails to match any specified keys; a zero-length detail sub-part resolves to the empty string.

protocol-element §3

The 'subaddress' capability string identifies this Sieve extension. Test commands acting on addresses may take optional tagged arguments ':user' and ':detail' to specify which sub-part of the local-part is examined.

protocol-element §4

The ':user' argument specifies the user sub-part of the local-part of an address. If the address contains no detail sub-part, ':user' specifies the entire left side of the address, equivalent to ':localpart'.

registry §5

This document registers the 'subaddress' Sieve extension with IANA, replacing the registration from RFC 3598. The capability adds ':user' and ':detail' address parts for use with address and envelope tests.

email, registry

security-consideration §6

Security considerations are deferred to RFC 5228. This extension is believed not to introduce any additional security concerns beyond those already discussed in the base Sieve specification.

email, security

wire-format §4

The ADDRESS-PART syntax element from RFC 5228 Section 2.7.4 is augmented to include ':user' and ':detail': ADDRESS-PART =/ ':user' / ':detail'. These parts decompose the local-part around an implementation-defined separator character sequence.