draft-ietf-sieve-spamtestbis-00.txt   draft-ietf-sieve-spamtestbis-01.txt 
SIEVE Email Filtering Working C. Daboo SIEVE Email Filtering Working C. Daboo
Group ISAMET, Inc. Group ISAMET, Inc.
Expires: July 20, 2005 Expires: January 19, 2006
SIEVE Email Filtering: Spamtest and Virustest Extensions SIEVE Email Filtering: Spamtest and Virustest Extensions
draft-ietf-sieve-spamtestbis-00 draft-ietf-sieve-spamtestbis-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 20, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The SIEVE email filtering language "spamtest", "spamtestpercent" and The SIEVE email filtering language "spamtest", "spamtestplus" and
"virustest" extensions permit users to use simple, portable commands "virustest" extensions permit users to use simple, portable commands
for spam and virus tests on email messages. Each extension provides for spam and virus tests on email messages. Each extension provides
a new test using matches against numeric 'scores'. It is the a new test using matches against numeric 'scores'. It is the
responsibility of the underlying SIEVE implementation to do the responsibility of the underlying SIEVE implementation to do the
actual checks that result in values returned by the tests. actual checks that result in values returned by the tests.
Change History (to be removed prior to publication as an RFC) Change History (to be removed prior to publication as an RFC)
Changes from -00:
1. Added description of how to check for untested when using
:percent.
2. Changed requires item to 'spamtestplus'.
3. Changed text describing which requires item needs to be present.
Changes from RFC3685: Changes from RFC3685:
1. Added ':percent' argument to spamtest. 1. Added ':percent' argument to spamtest.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. SIEVE Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3. SIEVE Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 General Considerations . . . . . . . . . . . . . . . . . . 4 3.1 General Considerations . . . . . . . . . . . . . . . . . . 4
3.2 Test spamtest . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Test spamtest . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1 spamtest without :percent argument . . . . . . . . . . 4 3.2.1 spamtest without :percent argument . . . . . . . . . . 4
3.2.2 spamtest with :percent argument . . . . . . . . . . . 5 3.2.2 spamtest with :percent argument . . . . . . . . . . . 5
3.3 Test virustest . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Test virustest . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1 spamtestpercent registration . . . . . . . . . . . . . . . 8 5.1 spamtestplus registration . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 10
1. Introduction and Overview 1. Introduction and Overview
SIEVE scripts are frequently being used to do spam and virus SIEVE scripts are frequently being used to do spam and virus
filtering based on either implicit script tests (e.g. tests for filtering based on either implicit script tests (e.g. tests for
'black-listed' senders directly encoded in the SIEVE script), or via 'black-listed' senders directly encoded in the SIEVE script), or via
testing messages modified by some external spam or virus checker that testing messages modified by some external spam or virus checker that
skipping to change at page 3, line 27 skipping to change at page 3, line 27
these headers to do filtering. This requires the script to stay in these headers to do filtering. This requires the script to stay in
synchronisation with the third party tool as it gets updated or synchronisation with the third party tool as it gets updated or
perhaps replaced with another. Thus scripts become tied to specific perhaps replaced with another. Thus scripts become tied to specific
environments, and lose portability. environments, and lose portability.
The purpose of this document is to introduce two SIEVE tests that can The purpose of this document is to introduce two SIEVE tests that can
be used to implement 'generic' tests for spam and viruses in messages be used to implement 'generic' tests for spam and viruses in messages
processed via SIEVE scripts. These tests return a string containing processed via SIEVE scripts. These tests return a string containing
a range of numeric values that indicate the severity of spam or a range of numeric values that indicate the severity of spam or
viruses in a message, or a string that indicates the message has not viruses in a message, or a string that indicates the message has not
passed through any spam or virus checking tools. The spam and virus passed through any spam or virus checking tools, or provides a direct
checks themselves are handled by the underlying SIEVE implementation indication of whether the message has been tested for spam or not.
in whatever manner is appropriate, and the implementation maps the The spam and virus checks themselves are handled by the underlying
results of these checks into the numeric ranges defined by the new SIEVE implementation in whatever manner is appropriate, and the
tests. Thus a SIEVE implementation can have a spam test that implementation maps the results of these checks into the numeric
implicitly checks for third-party spam tool headers and determines ranges defined by the new tests. Thus a SIEVE implementation can
how those map into the spamtest numeric range. have a spam test that implicitly checks for third-party spam tool
headers and determines how those map into the spamtest numeric range.
In order to do numeric comparisons against the returned strings, In order to do numeric comparisons against the returned strings,
server implementations MUST also support the SIEVE relational server implementations MUST also support the SIEVE relational
[RFC3431] extension, in addition to the extensions described here. [RFC3431] extension, in addition to the extensions described here.
All examples below assume the relational extension is present. All examples below assume the relational extension is present.
2. Conventions Used in This Document 2. Conventions Used in This Document
Conventions for notations are as in [RFC3028] section 1.1, including Conventions for notations are as in [RFC3028] section 1.1, including
use of [RFC2119]. use of [RFC2119].
skipping to change at page 4, line 29 skipping to change at page 4, line 30
about the result. Tests can be done using standard string about the result. Tests can be done using standard string
comparators against this text if it helps to refine behaviour, comparators against this text if it helps to refine behaviour,
however this will break portability of the script as the text will however this will break portability of the script as the text will
likely be specific to a particular implementation. likely be specific to a particular implementation.
3.2 Test spamtest 3.2 Test spamtest
Syntax: spamtest [":percent"] [COMPARATOR] [MATCH-TYPE] Syntax: spamtest [":percent"] [COMPARATOR] [MATCH-TYPE]
<value: string> <value: string>
SIEVE implementations that implement the "spamtest" test have an SIEVE implementations that implement the "spamtest" test use an
identifier of "spamtest" for use with the capability mechanism. If identifier of either "spamtest" or "spamtestplus" for use with the
the ":percent" argument is used with any spamtest test, then the capability mechanism.
capability idenitifier "spamtestpercent" MUST be present, and the
"spamtest" capability MUST NOT be present. If the ":percent" argument is not used with any spamtest test, then
one of either the "spamtest" or "spamtestplus" capability identifiers
MUST be present, though both SHOULD NOT be present together.
If the ":percent" argument is used with any spamtest test, then the
"spamtestplus" capability identifier MUST be present, and the
"spamtest" capability identitifer SHOULD NOT be present.
The "spamtest" test evaluates to true if the spamtest result matches The "spamtest" test evaluates to true if the spamtest result matches
the value. The type of match is specified by the optional match the value. The type of match is specified by the optional match
argument, which defaults to ":is" if not specified. argument, which defaults to ":is" if not specified.
3.2.1 spamtest without :percent argument 3.2.1 spamtest without :percent argument
When the ":percent" argument is not present in the "spamtest" test, When the ":percent" argument is not present in the "spamtest" test,
the result of the test is a string starting with a numeric value in the result of the test is a string starting with a numeric value in
the range "0" (zero) through "10", with meanings summarised below: the range "0" (zero) through "10", with meanings summarised below:
spamtest interpretation spamtest interpretation
value value
0 message was not tested for spam 0 message was not tested for spam
1 message was tested and is clear of spam 1 message was tested and is clear of spam
2 - 9 message was tested and has a varying likelihood of 2 - 9 message was tested and has a varying likelihood
containing spam in increasing order of containing spam in increasing order
10 message was tested and definitely contains spam 10 message was tested and definitely contains spam
The underlying SIEVE implementation will map whatever spam check is The underlying SIEVE implementation will map whatever spam check is
done into this numeric range, as appropriate. done into this numeric range, as appropriate.
Examples: Examples:
require ["spamtest", "fileinto", require ["spamtest", "fileinto",
"relational", "comparator-i;ascii-numeric"]; "relational", "comparator-i;ascii-numeric"];
skipping to change at page 5, line 32 skipping to change at page 5, line 40
In this example, any message that has not passed through a spam check In this example, any message that has not passed through a spam check
tool will be filed into the mailbox "INBOX.unclassified". Any tool will be filed into the mailbox "INBOX.unclassified". Any
message with a spamtest value greater than or equal to "3" is filed message with a spamtest value greater than or equal to "3" is filed
into a mailbox called "INBOX.spam-trap" in the user's mailstore. into a mailbox called "INBOX.spam-trap" in the user's mailstore.
3.2.2 spamtest with :percent argument 3.2.2 spamtest with :percent argument
When the ":percent" argument is present in the "spamtest" test, the When the ":percent" argument is present in the "spamtest" test, the
result of the test is a string starting with a numeric value in the result of the test is a string starting with a numeric value in the
range "-1" (minus one) through "100", with meanings summarised below: range "0" (zero) through "100", with meanings summarised below:
spamtest interpretation spamtest interpretation
value value
-1 message was not tested for spam
0 message was tested and is clear of spam 0 message was tested and is clear of spam
1 - 99 message was tested and has a varying likelihood of 1 - 99 message was tested and has a varying likelihood
containing spam in increasing order of containing spam in increasing order
100 message was tested and definitely contains spam 100 message was tested and definitely contains spam
The underlying SIEVE implementation will map whatever spam check is The underlying SIEVE implementation will map whatever spam check is
done into this numeric range, as appropriate. done into this numeric range, as appropriate.
The range of tests for :percent does not include a value to determine
whether the message was not tested for spam. Instead, a test without
the :percent argument can be used to check for that situation, which
is done by testing for the value "0" as described in Section 3.2.1.
Examples: Examples:
require ["spamtestpercent", "fileinto", require ["spamtestplus", "fileinto",
"relational", "comparator-i;ascii-numeric"]; "relational", "comparator-i;ascii-numeric"];
if spamtest :percent :value "eq" if spamtest :value "eq"
:comparator "i;ascii-numeric" "-1" :comparator "i;ascii-numeric" "0"
{ {
fileinto "INBOX.unclassified"; fileinto "INBOX.unclassified";
} }
elsif spamtest :percent :value "ge" elsif spamtest :percent :value "ge"
:comparator "i;ascii-numeric" "30" :comparator "i;ascii-numeric" "30"
{ {
fileinto "INBOX.spam-trap"; fileinto "INBOX.spam-trap";
} }
In this example, any message that has not passed through a spam check In this example, any message that has not passed through a spam check
skipping to change at page 6, line 45 skipping to change at page 7, line 11
The virustest result is a string starting with a numeric value in the The virustest result is a string starting with a numeric value in the
range "0" (zero) through "5", with meanings summarised below: range "0" (zero) through "5", with meanings summarised below:
virustest interpretation virustest interpretation
value value
0 message was not tested for viruses 0 message was not tested for viruses
1 message was tested and contains no known viruses 1 message was tested and contains no known viruses
2 message was tested and contained a known virus 2 message was tested and contained a known virus
which which was replaced with harmless content
was replaced with harmless content
3 message was tested and contained a known virus 3 message was tested and contained a known virus
which which was "cured" such that it is now harmless
was "cured" such that it is now harmless 4 message was tested and possibly contains a
4 message was tested and possibly contains a known known virus
virus 5 message was tested and definately contains a
5 message was tested and definately contains a known known virus
virus
The underlying SIEVE implementation will map whatever virus checks The underlying SIEVE implementation will map whatever virus checks
are done into this numeric range, as appropriate. If the message has are done into this numeric range, as appropriate. If the message has
not been categorised by any virus checking tools, then the virustest not been categorised by any virus checking tools, then the virustest
result is "0". result is "0".
Example: Example:
require ["virustest", "fileinto", require ["virustest", "fileinto",
"relational", "comparator-i;ascii-numeric"]; "relational", "comparator-i;ascii-numeric"];
skipping to change at page 8, line 11 skipping to change at page 8, line 27
Beyond that, the "spamtest" and "virustest" extensions do not raise Beyond that, the "spamtest" and "virustest" extensions do not raise
any security considerations that are not present in the base any security considerations that are not present in the base
[RFC3028] protocol, and these issues are discussed in [RFC3028]. [RFC3028] protocol, and these issues are discussed in [RFC3028].
5. IANA Considerations 5. IANA Considerations
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
extensions specified in this document, that are not already extensions specified in this document, that are not already
registered in [RFC3685]: registered in [RFC3685]:
5.1 spamtestpercent registration 5.1 spamtestplus registration
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: spamtestpercent Capability name: spamtestplus
Capability keyword: spamtest Capability keyword: spamtest
Capability arguments: :percent Capability arguments: :percent
Standards Track/IESG-approved experimental RFC number: this RFC Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information: Person and email address to contact for further information:
Cyrus Daboo Cyrus Daboo
ISAMET, Inc. ISAMET, Inc.
5001 Baum Blvd., Suite 650, 5001 Baum Blvd., Suite 650,
Pittsburgh, PA 15213 Pittsburgh, PA 15213
U.S.A. U.S.A.
skipping to change at page 8, line 40 skipping to change at page 9, line 10
This information should be added to the list of sieve extensions This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
6. References 6. References
6.1 Normative References 6.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language",
3028, January 2001. RFC 3028, January 2001.
[RFC3431] Segmuller, W., "Sieve Extension: Relational Tests", RFC [RFC3431] Segmuller, W., "Sieve Extension: Relational Tests",
3431, December 2002. RFC 3431, December 2002.
[RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest
Extensions", RFC 3685, February 2004. Extensions", RFC 3685, February 2004.
6.2 Informative References 6.2 Informative References
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
Author's Address Author's Address
Cyrus Daboo Cyrus Daboo
ISAMET, Inc. ISAMET, Inc.
5001 Baum Blvd. 5001 Baum Blvd.
Suite 650 Suite 650
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US US
EMail: daboo@isamet.com Email: daboo@isamet.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
Thanks to Tony Hansen, Jutta Degener, Ned Freed, Ashish Gawarikar and Thanks to Tony Hansen, Jutta Degener, Ned Freed, Ashish Gawarikar and
Nigel Swinson for comments and corrections. Nigel Swinson for comments and corrections.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/