rfc-5173

Sieve Email Filtering: Body Extension

J. Degener, P. Guenther
date2008-04 streamIETF areaapp wgsieve statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc5173 doi10.17487/RFC5173
This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]

updates

Extracted elements (20)

design-rationale §1

The 'body' test was initially discussed for the base Sieve document but was subsequently removed because it was thought to be too costly to implement. It is reintroduced here as an optional extension, allowing implementations that can afford the cost to offer the functionality.

email

design-rationale §5.3

The :text transform is intentionally underspecified regarding whether it produces a single string or multiple strings, allowing sophisticated implementations to strip mark-up or convert non-text media types to text prior to matching, while simple implementations may treat it identically to :content "text".

email

interoperability-note §6

Any Sieve extension that extends the grammar for the COMPARATOR or MATCH-TYPE nonterminals will also affect the implementation of the 'body' test, since it uses both of these parameters.

email

normative-requirement §5.2 SHOULD NOT

A NUL octet (character zero) SHOULD NOT cause early termination of the content being compared against when performing :content matching.

email

normative-requirement §5.2 MUST NOT

Each matched MIME part is matched against independently: search expressions MUST NOT match across MIME part boundaries, and MIME headers of the containing part MUST NOT be included in the data.

email

normative-requirement §5.2 MUST

For :content, if the specification matches a message/rfc822 MIME part, only the header of the nested message is searched for key strings; body parts of the nested message are only searched if their content type matches the :content specification.

email

normative-requirement §5.2 MUST

For :content, if the specification matches a multipart MIME part, only the prologue and epilogue sections are searched for key strings; nested parts are only searched if their respective types match the :content specification.

email

normative-requirement §5.2 MUST

Implementations MUST support the "quoted-printable", "base64", "7bit", "8bit", and "binary" content transfer encodings for :content processing. Implementations MUST be capable of converting to UTF-8 the US-ASCII, ISO-8859-1, and the US-ASCII subset of ISO-8859-* character sets.

email

normative-requirement §5.2 MAY

MIME parts that cannot be decoded and converted MAY be treated as plain US-ASCII, omitted, or processed according to local conventions.

email

normative-requirement §5.2 MUST

The search for MIME parts matching the :content specification is recursive and automatically descends into multipart and message/rfc822 MIME parts. The test returns true if any combination of a searched MIME part and key-list argument match.

email

normative-requirement §4 MUST NOT

When a message consists of a header only with no empty line following it, the set of strings to match against is empty and all 'body' tests return false, including those that test for an empty string.

email

normative-requirement §5.1 MUST NOT

When :raw is specified, the implementation MUST NOT remove any transfer encoding from the message, MUST NOT refuse to filter messages with syntactic errors, and MUST treat multipart boundaries or MIME headers of enclosed body parts as part of the content being matched.

email

normative-requirement §6 MUST NOT

Wildcard expressions used with the 'body' test MUST NOT set match variables (${1}, ${2}...) to the input values corresponding to wildcard sequences in the matched pattern, even if the variables extension is present.

email

protocol-element §3

The 'body' test checks for the occurrence of one or more strings in the body of an email message, defined as anything following the first empty line after the header. The capability string for this extension is "body".

email

protocol-element §5

The BODY-TRANSFORM keyword parameter governs how strings to be matched are extracted from the body of the message. Three transforms are defined: :raw, :content, and :text, with :text as the default.

email

protocol-element §5.2

The :content transform matches MIME parts of specified content types independently. Content type matching rules: a type with a slash specifies a full type/subtype pair; without a slash, it specifies only a type and any subtype matches; an empty string matches all MIME content types.

email

protocol-element §5.1

The :raw transform matches against the entire undecoded body of a message as a single item, treating multipart boundaries and MIME headers of enclosed body parts as part of the content being matched rather than as MIME structures to interpret.

email

protocol-element §5.3

The :text transform matches against the results of an implementation's best effort at extracting UTF-8 encoded text from a message. All text extracted from a given non-container MIME part MUST be in the same string. In simple implementations, :text MAY be treated the same as :content "text".

email

registry §7

This document registers a new Sieve extension with IANA: capability name 'body', which provides a test for matching against the body of the message being processed, defined in RFC 5173.

email, registry

security-consideration §8

The system MUST be sized and restricted such that even malicious use of body matching does not deny service to other users of the host system. Body string matching is not a replacement for spam, virus, or other security-related filtering systems.

email, security