idnits 2.17.1 draft-ietf-sieve-spamtestbis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 403. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 163 has weird spacing: '...pamtest int...' == Line 201 has weird spacing: '...pamtest int...' == Line 249 has weird spacing: '...rustest inte...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2005) is 7035 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'COMPARATOR' is mentioned on line 236, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 236, but not defined ** Obsolete normative reference: RFC 3028 (Obsoleted by RFC 5228, RFC 5429) ** Obsolete normative reference: RFC 3431 (Obsoleted by RFC 5231) ** Obsolete normative reference: RFC 3685 (Obsoleted by RFC 5235) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIEVE Email Filtering Working C. Daboo 2 Group ISAMET, Inc. 3 Internet-Draft January 19, 2005 4 Expires: July 20, 2005 6 SIEVE Email Filtering: Spamtest and Virustest Extensions 7 draft-ietf-sieve-spamtestbis-00 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 20, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The SIEVE email filtering language "spamtest", "spamtestpercent" and 43 "virustest" extensions permit users to use simple, portable commands 44 for spam and virus tests on email messages. Each extension provides 45 a new test using matches against numeric 'scores'. It is the 46 responsibility of the underlying SIEVE implementation to do the 47 actual checks that result in values returned by the tests. 49 Change History (to be removed prior to publication as an RFC) 51 Changes from RFC3685: 52 1. Added ':percent' argument to spamtest. 54 Table of Contents 56 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. SIEVE Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1 General Considerations . . . . . . . . . . . . . . . . . . 4 60 3.2 Test spamtest . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2.1 spamtest without :percent argument . . . . . . . . . . 4 62 3.2.2 spamtest with :percent argument . . . . . . . . . . . 5 63 3.3 Test virustest . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 5.1 spamtestpercent registration . . . . . . . . . . . . . . . 8 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 69 6.2 Informative References . . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 71 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 Intellectual Property and Copyright Statements . . . . . . . . 10 74 1. Introduction and Overview 76 SIEVE scripts are frequently being used to do spam and virus 77 filtering based on either implicit script tests (e.g. tests for 78 'black-listed' senders directly encoded in the SIEVE script), or via 79 testing messages modified by some external spam or virus checker that 80 handled the message prior to SIEVE. The use of third-party spam and 81 virus checker tools poses a problem since each tool has its own way 82 of indicating the result of its checks. These usually take the form 83 of a header added to the message, the content of which indicates the 84 status using some syntax defined by the particular tool. Each user 85 has to then create their own SIEVE scripts to match the contents of 86 these headers to do filtering. This requires the script to stay in 87 synchronisation with the third party tool as it gets updated or 88 perhaps replaced with another. Thus scripts become tied to specific 89 environments, and lose portability. 91 The purpose of this document is to introduce two SIEVE tests that can 92 be used to implement 'generic' tests for spam and viruses in messages 93 processed via SIEVE scripts. These tests return a string containing 94 a range of numeric values that indicate the severity of spam or 95 viruses in a message, or a string that indicates the message has not 96 passed through any spam or virus checking tools. The spam and virus 97 checks themselves are handled by the underlying SIEVE implementation 98 in whatever manner is appropriate, and the implementation maps the 99 results of these checks into the numeric ranges defined by the new 100 tests. Thus a SIEVE implementation can have a spam test that 101 implicitly checks for third-party spam tool headers and determines 102 how those map into the spamtest numeric range. 104 In order to do numeric comparisons against the returned strings, 105 server implementations MUST also support the SIEVE relational 106 [RFC3431] extension, in addition to the extensions described here. 107 All examples below assume the relational extension is present. 109 2. Conventions Used in This Document 111 Conventions for notations are as in [RFC3028] section 1.1, including 112 use of [RFC2119]. 114 The term 'spam' is used in this document to refer to unsolicited or 115 unwanted email messages. This document does not attempt to define 116 what exactly constitutes spam, or how it should be identified, or 117 what actions should be taken when detected. 119 The term 'virus' is used in this document to refer to any type of 120 message whose content can cause malicious damage. This document does 121 not attempt to define what exactly constitutes a virus, or how it 122 should be identified, or what actions should be taken when detected. 124 3. SIEVE Extensions 126 3.1 General Considerations 128 The "spamtest" and "virustest" tests described below both return a 129 string that starts with a numeric value, followed by an optional 130 space (%x20) character and optional arbitrary text. The numeric 131 value can be compared to specific values using the SIEVE relational 132 [RFC3431] extension in conjunction with the "i;ascii-numeric" 133 comparator [RFC2244], which will test for the presence of a numeric 134 value at the start of the string, ignoring any additional text in the 135 string. The additional text can be used to carry implementation 136 specific details about the tests performed and descriptive comments 137 about the result. Tests can be done using standard string 138 comparators against this text if it helps to refine behaviour, 139 however this will break portability of the script as the text will 140 likely be specific to a particular implementation. 142 3.2 Test spamtest 144 Syntax: spamtest [":percent"] [COMPARATOR] [MATCH-TYPE] 145 147 SIEVE implementations that implement the "spamtest" test have an 148 identifier of "spamtest" for use with the capability mechanism. If 149 the ":percent" argument is used with any spamtest test, then the 150 capability idenitifier "spamtestpercent" MUST be present, and the 151 "spamtest" capability MUST NOT be present. 153 The "spamtest" test evaluates to true if the spamtest result matches 154 the value. The type of match is specified by the optional match 155 argument, which defaults to ":is" if not specified. 157 3.2.1 spamtest without :percent argument 159 When the ":percent" argument is not present in the "spamtest" test, 160 the result of the test is a string starting with a numeric value in 161 the range "0" (zero) through "10", with meanings summarised below: 163 spamtest interpretation 164 value 166 0 message was not tested for spam 167 1 message was tested and is clear of spam 168 2 - 9 message was tested and has a varying likelihood of 169 containing spam in increasing order 171 10 message was tested and definitely contains spam 173 The underlying SIEVE implementation will map whatever spam check is 174 done into this numeric range, as appropriate. 176 Examples: 178 require ["spamtest", "fileinto", 179 "relational", "comparator-i;ascii-numeric"]; 181 if spamtest :value "eq" :comparator "i;ascii-numeric" "0" 182 { 183 fileinto "INBOX.unclassified"; 184 } 185 elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3" 186 { 187 fileinto "INBOX.spam-trap"; 188 } 190 In this example, any message that has not passed through a spam check 191 tool will be filed into the mailbox "INBOX.unclassified". Any 192 message with a spamtest value greater than or equal to "3" is filed 193 into a mailbox called "INBOX.spam-trap" in the user's mailstore. 195 3.2.2 spamtest with :percent argument 197 When the ":percent" argument is present in the "spamtest" test, the 198 result of the test is a string starting with a numeric value in the 199 range "-1" (minus one) through "100", with meanings summarised below: 201 spamtest interpretation 202 value 204 -1 message was not tested for spam 205 0 message was tested and is clear of spam 206 1 - 99 message was tested and has a varying likelihood of 207 containing spam in increasing order 208 100 message was tested and definitely contains spam 210 The underlying SIEVE implementation will map whatever spam check is 211 done into this numeric range, as appropriate. 213 Examples: 215 require ["spamtestpercent", "fileinto", 216 "relational", "comparator-i;ascii-numeric"]; 218 if spamtest :percent :value "eq" 219 :comparator "i;ascii-numeric" "-1" 220 { 221 fileinto "INBOX.unclassified"; 222 } 223 elsif spamtest :percent :value "ge" 224 :comparator "i;ascii-numeric" "30" 225 { 226 fileinto "INBOX.spam-trap"; 227 } 229 In this example, any message that has not passed through a spam check 230 tool will be filed into the mailbox "INBOX.unclassified". Any 231 message with a spamtest value greater than or equal to "30" is filed 232 into a mailbox called "INBOX.spam-trap" in the user's mailstore. 234 3.3 Test virustest 236 Syntax: virustest [COMPARATOR] [MATCH-TYPE] 237 239 SIEVE implementations that implement the "virustest" test have an 240 identifier of "virustest" for use with the capability mechanism. 242 The "virustest" test evaluates to true if the virustest result 243 matches the value. The type of match is specified by the optional 244 match argument, which defaults to ":is" if not specified. 246 The virustest result is a string starting with a numeric value in the 247 range "0" (zero) through "5", with meanings summarised below: 249 virustest interpretation 250 value 252 0 message was not tested for viruses 253 1 message was tested and contains no known viruses 254 2 message was tested and contained a known virus 255 which 256 was replaced with harmless content 257 3 message was tested and contained a known virus 258 which 259 was "cured" such that it is now harmless 260 4 message was tested and possibly contains a known 261 virus 262 5 message was tested and definately contains a known 263 virus 265 The underlying SIEVE implementation will map whatever virus checks 266 are done into this numeric range, as appropriate. If the message has 267 not been categorised by any virus checking tools, then the virustest 268 result is "0". 270 Example: 272 require ["virustest", "fileinto", 273 "relational", "comparator-i;ascii-numeric"]; 275 if virustest :value "eq" :comparator "i;ascii-numeric" "0" 276 { 277 fileinto "INBOX.unclassified"; 278 } 279 if virustest :value "eq" :comparator "i;ascii-numeric" "4" 280 { 281 fileinto "INBOX.quarantine"; 282 } 283 elsif virustest :value "eq" :comparator "i;ascii-numeric" "5" 284 { 285 discard; 286 } 288 In this example, any message that has not passed through a virus 289 check tool will be filed into the mailbox "INBOX.unclassified". Any 290 message with a virustest value equal to "4" is filed into a mailbox 291 called "INBOX.quarantine" in the user's mailstore. Any message with 292 a virustest value equal to "5" is discarded (removed) and not 293 delivered to the user's mailstore. 295 4. Security Considerations 297 SIEVE implementations SHOULD ensure that "spamtest" and "virustest" 298 tests can only occur for messages that have gone through a legitimate 299 spam or virus check process. If such checks rely on the addition of 300 special headers to messages, it is the responsibility of the 301 implementation to ensure that such headers cannot be spoofed by the 302 sender, to prevent the implementation from being tricked into 303 returning the wrong result for the test. 305 Server administrators MUST ensure that the virus checking tools are 306 kept up to date, to provide reasonable protection for users using the 307 "virustest" test. Users should be made aware of the fact that the 308 "virustest" test does not provide a 100% reliable way to remove all 309 viruses, and they should continue to exercise caution when dealing 310 with messages of unknown content and origin. 312 Beyond that, the "spamtest" and "virustest" extensions do not raise 313 any security considerations that are not present in the base 314 [RFC3028] protocol, and these issues are discussed in [RFC3028]. 316 5. IANA Considerations 318 The following template specifies the IANA registration of the Sieve 319 extensions specified in this document, that are not already 320 registered in [RFC3685]: 322 5.1 spamtestpercent registration 324 To: iana@iana.org 325 Subject: Registration of new Sieve extension 327 Capability name: spamtestpercent 328 Capability keyword: spamtest 329 Capability arguments: :percent 330 Standards Track/IESG-approved experimental RFC number: this RFC 331 Person and email address to contact for further information: 333 Cyrus Daboo 334 ISAMET, Inc. 335 5001 Baum Blvd., Suite 650, 336 Pittsburgh, PA 15213 337 U.S.A. 339 341 This information should be added to the list of sieve extensions 342 given on http://www.iana.org/assignments/sieve-extensions. 344 6. References 346 6.1 Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 352 3028, January 2001. 354 [RFC3431] Segmuller, W., "Sieve Extension: Relational Tests", RFC 355 3431, December 2002. 357 [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest 358 Extensions", RFC 3685, February 2004. 360 6.2 Informative References 362 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 363 Configuration Access Protocol", RFC 2244, November 1997. 365 Author's Address 367 Cyrus Daboo 368 ISAMET, Inc. 369 5001 Baum Blvd. 370 Suite 650 371 Pittsburgh, PA 15213 372 US 374 EMail: daboo@isamet.com 376 Appendix A. Acknowledgments 378 Thanks to Tony Hansen, Jutta Degener, Ned Freed, Ashish Gawarikar and 379 Nigel Swinson for comments and corrections. 381 Intellectual Property Statement 383 The IETF takes no position regarding the validity or scope of any 384 Intellectual Property Rights or other rights that might be claimed to 385 pertain to the implementation or use of the technology described in 386 this document or the extent to which any license under such rights 387 might or might not be available; nor does it represent that it has 388 made any independent effort to identify any such rights. Information 389 on the procedures with respect to rights in RFC documents can be 390 found in BCP 78 and BCP 79. 392 Copies of IPR disclosures made to the IETF Secretariat and any 393 assurances of licenses to be made available, or the result of an 394 attempt made to obtain a general license or permission for the use of 395 such proprietary rights by implementers or users of this 396 specification can be obtained from the IETF on-line IPR repository at 397 http://www.ietf.org/ipr. 399 The IETF invites any interested party to bring to its attention any 400 copyrights, patents or patent applications, or other proprietary 401 rights that may cover technology that may be required to implement 402 this standard. Please address the information to the IETF at 403 ietf-ipr@ietf.org. 405 Disclaimer of Validity 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 Copyright Statement 417 Copyright (C) The Internet Society (2005). This document is subject 418 to the rights, licenses and restrictions contained in BCP 78, and 419 except as set forth therein, the authors retain all their rights. 421 Acknowledgment 423 Funding for the RFC Editor function is currently provided by the 424 Internet Society.