rfc-3685

SIEVE Email Filtering: Spamtest and VirusTest Extensions

C. Daboo

date2004-02 streamIETF wgnon working group statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc3685 doi10.17487/RFC3685

The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]

obsoleted by

rfc-5235 — Sieve Email Filtering: Spamtest and Virustest Extensions

Extracted elements (12)

design-rationale §1

The extensions were introduced because each third-party spam/virus tool has its own header format, forcing users to write tool-specific SIEVE scripts that break portability. By normalizing results to a numeric range, implementations can abstract away tool-specific details and scripts remain portable across environments.

interoperability-note §2.1

Numeric comparison against spamtest/virustest results requires use of the SIEVE relational extension together with the 'i;ascii-numeric' comparator from ACAP, which tests for a numeric value at the start of the string while ignoring any trailing text.

interoperability-note §2.1

Using standard string comparators against the optional free-text portion of spamtest/virustest results may refine behavior but breaks script portability, as that text is implementation-specific.

normative-requirement §3 MUST

Server administrators MUST ensure that virus checking tools are kept up to date to provide reasonable protection for users using the 'virustest' test.

email, security

normative-requirement §1 MUST

Server implementations MUST also support the SIEVE relational extension in addition to the spamtest/virustest extensions, in order to perform numeric comparisons against the returned strings.

protocol-element §2.1

Both spamtest and virustest return a string that starts with a numeric value, followed by an optional space (%x20) character and optional arbitrary text. The additional text may carry implementation-specific details but its use breaks script portability.

protocol-element §2.2

The 'spamtest' test evaluates to true if the spamtest result matches a given value. It returns a string starting with a numeric value in the range '0' through '10', where 0 means not tested, 1 means clear, 2-9 indicate increasing likelihood of spam, and 10 means definitely spam.

email, security

protocol-element §2.3

The 'virustest' test evaluates to true if the virustest result matches a given value. It returns a string starting with a numeric value in the range '0' through '5', where 0 means not tested, 1 means no known viruses, 2 means virus replaced with harmless content, 3 means virus cured, 4 means possibly contains a known virus, and 5 means definitely contains a known virus.

email, security

registry §4.1

The 'spamtest' capability is registered in the IANA Sieve extensions registry with capability keyword 'spamtest' and no capability arguments.

email, registry

registry §4.2

The 'virustest' capability is registered in the IANA Sieve extensions registry with capability keyword 'virustest' and no capability arguments.

email, registry

security-consideration §3 SHOULD

SIEVE implementations SHOULD ensure that 'spamtest' and 'virustest' tests can only occur for messages that have gone through a legitimate spam or virus check process. If checks rely on special headers, the implementation must ensure those headers cannot be spoofed by the sender, preventing false test results.

email, security

security-consideration §3

Users should be made aware that 'virustest' does not provide a 100% reliable way to remove all viruses, and they should continue to exercise caution when dealing with messages of unknown content and origin.

email, security