idnits 2.17.1 draft-daboo-sieve-spamtest-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 27 instances of lines with control characters in the document. ** The abstract seems to contain references ([SIEVE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 171 has weird spacing: '...pamtest int...' == Line 216 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 (October 2003) is 7499 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 204, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 204, but not defined ** Obsolete normative reference: RFC 3431 (ref. 'RELATIONAL') (Obsoleted by RFC 5231) ** Obsolete normative reference: RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Daboo 2 Internet Draft: SIEVE Spamtest and Virustest Extensions 3 Document: draft-daboo-sieve-spamtest-04.txt October 2003 5 SIEVE Spamtest and Virustest Extensions 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet- Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society 2003. All Rights Reserved. 32 Abstract 34 The SIEVE mail filtering language [SIEVE] "spamtest" and "virustest" 35 extensions permit users to use simple, portable commands for spam 36 and virus tests on email messages. Each extension provides a new 37 test using matches against numeric 'scores'. It is the 38 responsibility of the underlying SIEVE implementation to do the 39 actual checks that result in values returned by the tests. 41 Change History (to be removed prior to publication as an RFC) 43 Changes from -03 to -04: 44 1 Added IPR boiler plate. 45 2 Re-ordered sections at start to conform to RFC style. 46 3 Eliminated the use of "NIL" for untested value. 47 4 Expanded virus test ranges to indicate additional state. 48 5 Added security consideration requiring admins to keep virus 49 tools up to date 51 Changes from -02 to -03: 52 1 Changed test values to be arbitrary strings with numeric value 53 as first token. 54 2 Changed 'virii' to 'viruses'. 56 Changes from -01 to -02: 57 1 Fixed syntax in examples. 58 2 Updated references section to normative/informative. 60 Changes from -00 to -01: 61 1 Changed so that tests use standard SIEVE syntax. 62 2 Added requirement for relation extension for numeric 63 comparisons. 64 3 Changed spamtest numeric range to 0->10. 66 Table of Contents 68 1 Introduction and Overview . . . . . . . . . . . . . . . . . . 3 69 2 Conventions Used in This Document . . . . . . . . . . . . . . 3 70 3 SIEVE Extensions . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1 General Considerations . . . . . . . . . . . . . . . . . . 4 72 3.2 Test spamtest . . . . . . . . . . . . . . . . . . . . . . 4 73 3.3 Test virustest . . . . . . . . . . . . . . . . . . . . . . 5 74 4 Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 5.1 spamtest registration . . . . . . . . . . . . . . . . . . 7 77 5.2 virustest registration . . . . . . . . . . . . . . . . . . 7 78 6 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 80 6.2 Non-Normative References . . . . . . . . . . . . . . . . 8 81 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 82 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 83 9 Intellectual Property Rights Statement . . . . . . . . . . . . 8 84 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 86 1 Introduction and Overview 88 SIEVE scripts are frequently being used to do spam and virus 89 filtering based on either implicit script tests (e.g. tests for 90 'black-listed' senders directly encoded in the SIEVE script), or via 91 testing messages modified by some external spam or virus checker 92 that handled the message prior to SIEVE. The use of third-party 93 spam and virus checker tools poses a problem since each tool has its 94 own way of indicating the result of its checks. These usually take 95 the form of a header added to the message, the content of which 96 indicates the status using some syntax defined by the particular 97 tool. Each user has to then create their own SIEVE scripts to match 98 the contents of these headers to do filtering. This requires the 99 script to stay in synchronisation with the third party tool as it 100 gets updated or perhaps replaced with another. Thus scripts become 101 tied to specific environments, and lose portability. 103 The purpose of this document is to introduce two SIEVE tests that 104 can be used to implement 'generic' tests for spam and viruses in 105 messages processed via SIEVE scripts. These tests return a string 106 containing a range of numeric values that indicate the severity of 107 spam or viruses in a message, or a string that indicates the message 108 has not passed through any spam or virus checking tools. The spam 109 and virus checks themselves are handled by the underlying SIEVE 110 implementation in whatever manner is appropriate, and the 111 implementation maps the results of these checks into the numeric 112 ranges defined by the new tests. Thus a SIEVE implementation can 113 have a spam test that implicitly checks for third-party spam tool 114 headers and determines how those map into the spamtest numeric 115 range. 117 In order to do numeric comparisons against the returned strings, 118 server implementations MUST also support the SIEVE relational 119 [RELATIONAL] extension, in addition to the extensions described 120 here. All examples below assume the relational extension is 121 present. 123 2 Conventions Used in This Document 125 Conventions for notations are as in [SIEVE] section 1.1, including 126 use of [KEYWORDS]. 128 The term 'spam' is used in this document to refer to unsolicited or 129 unwanted email messages. This document does not attempt to define 130 what exactly constitutes spam, or how it should be identified, or 131 what actions should be taken when detected. 133 The term 'virus' is used in this document to refer to any type of 134 message whose content can cause malicious damage. This document 135 does not attempt to define what exactly constitutes a virus, or how 136 it should be identified, or what actions should be taken when 137 detected. 139 3 SIEVE Extensions 141 3.1 General Considerations 143 The "spamtest" and "virustest" tests described below both return a 144 string that starts with a numeric value, followed by an optional 145 space (%x20) character and optional arbitrary text. The numeric 146 value can be compared to specific values using the SIEVE relational 147 [RELATIONAL] extension in conjunction with the "i;ascii-numeric" 148 comparator [ACAP], which will test for the presence of a numeric 149 value at the start of the string, ignoring any additional text in 150 the string. The additional text can be used to carry implementation 151 specific details about the tests performed and descriptive comments 152 about the result. Tests can be done using standard string 153 comparators against this text if it helps to refine behaviour, 154 however this will break portability of the script as the text will 155 likely be specific to a particular implementation. 157 3.2 Test spamtest 159 Syntax: spamtest [COMPARATOR] [MATCH-TYPE] 161 SIEVE implementations that implement the "spamtest" test have an 162 identifier of "spamtest" for use with the capability mechanism. 164 The "spamtest" test evaluates to true if the spamtest result matches 165 the value. The type of match is specified by the optional match 166 argument, which defaults to ":is" if not specified. 168 The spamtest result is a string starting with a numeric value in the 169 range "0" (zero) through "10", with meanings summarised below: 171 spamtest interpretation 172 value 174 0 message was not tested for spam 175 1 message was tested and is clear of spam 176 2 - 9 message was tested and has a varying likelihood of 177 containing spam in increasing order 178 10 message was tested and definitely contains spam 180 The underlying SIEVE implementation will map whatever spam check is 181 done into this numeric range, as appropriate. 183 Examples: 185 require ["spamtest", "fileinto", 186 "relational", "comparator-i;ascii-numeric"]; 188 if spamtest :value "eq" :comparator "i;ascii-numeric" "0" 189 { 190 fileinto "INBOX.unclassified"; 191 } 192 elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3" 193 { 194 fileinto "INBOX.spam-trap"; 195 } 197 In this example, any message that has not passed through a spam 198 check tool will be filed into the mailbox "INBOX.unclassified". Any 199 message with a spamtest value greater than or equal to "3" is filed 200 into a mailbox called "INBOX.spam-trap" in the user's mailstore. 202 3.3 Test virustest 204 Syntax: virustest [COMPARATOR] [MATCH-TYPE] 206 SIEVE implementations that implement the "virustest" test have an 207 identifier of "virustest" for use with the capability mechanism. 209 The "virustest" test evaluates to true if the virustest result 210 matches the value. The type of match is specified by the optional 211 match argument, which defaults to ":is" if not specified. 213 The virustest result is a string starting with a numeric value in 214 the range "0" (zero) through "5", with meanings summarised below: 216 virustest interpretation 217 value 219 0 message was not tested for viruses 220 1 message was tested and contains no known viruses 221 2 message was tested and contained a known virus which 222 was replaced with harmless content 223 3 message was tested and contained a known virus which 224 was "cured" such that it is now harmless 225 4 message was tested and possibly contains a known virus 226 5 message was tested and definately contains a known virus 228 The underlying SIEVE implementation will map whatever virus checks 229 are done into this numeric range, as appropriate. If the message 230 has not been categorised by any virus checking tools, then the 231 virustest result is "0". 233 Example: 235 require ["virustest", "fileinto", 236 "relational", "comparator-i;ascii-numeric"]; 238 if virustest :value "eq" :comparator "i;ascii-numeric" "0" 239 { 240 fileinto "INBOX.unclassified"; 241 } 242 if virustest :value "eq" :comparator "i;ascii-numeric" "4" 243 { 244 fileinto "INBOX.quarantine"; 245 } 246 elsif virustest :value "eq" :comparator "i;ascii-numeric" "5" 247 { 248 discard; 249 } 251 In this example, any message that has not passed through a virus 252 check tool will be filed into the mailbox "INBOX.unclassified". Any 253 message with a virustest value equal to "4" is filed into a mailbox 254 called "INBOX.quarantine" in the user's mailstore. Any message with 255 a virustest value equal to "5" is discarded (removed) and not 256 delivered to the user's mailstore. 258 4 Security Considerations 260 SIEVE implementations SHOULD ensure that "spamtest" and "virustest" 261 tests can only occur for messages that have gone through a 262 legitimate spam or virus check process. If such checks rely on the 263 addition of special headers to messages, it is the responsibility of 264 the implementation to ensure that such headers cannot be spoofed by 265 the sender, to prevent the implementation from being tricked into 266 returning the wrong result for the test. 268 Server administrators MUST ensure that the virus checking tools are 269 kept up to date, to provide reasonable protection for users using 270 the "virustest" test. Users should be made aware of the fact that 271 the "virustest" test does not provide a 100% reliable way to remove 272 all viruses, and they should continue to exercise caution when 273 dealing with messages of unknown content and origin. 275 Beyond that, the "spamtest" and "virustest" extensions do not raise 276 any security considerations that are not present in the base [SIEVE] 277 protocol, and these issues are discussed in [SIEVE]. 279 5 IANA Considerations 281 The following templates specify the IANA registration of the Sieve 282 extensions specified in this document: 284 5.1 spamtest registration 286 To: iana@iana.org 287 Subject: Registration of new Sieve extension 289 Capability name: spamtest 290 Capability keyword: spamtest 291 Capability arguments: N/A 292 Standards Track/IESG-approved experimental RFC number: this RFC 293 Person and email address to contact for further information: 295 Cyrus Daboo 296 Cyrusoft International, Inc. 297 5001 Baum Blvd., Suite 780, 298 Pittsburgh, PA 15213 299 U.S.A. 301 303 This information should be added to the list of sieve extensions 304 given on http://www.iana.org/assignments/sieve-extensions. 306 5.2 virustest registration 308 To: iana@iana.org 309 Subject: Registration of new Sieve extension 311 Capability name: virustest 312 Capability keyword: virustest 313 Capability arguments: N/A 314 Standards Track/IESG-approved experimental RFC number: this RFC 315 Person and email address to contact for further information: 317 Cyrus Daboo 318 Cyrusoft International, Inc. 319 5001 Baum Blvd., Suite 780, 320 Pittsburgh, PA 15213 321 U.S.A. 323 325 This information should be added to the list of sieve extensions 326 given on http://www.iana.org/assignments/sieve-extensions. 328 6 References 330 6.1 Normative References 332 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", RFC 2119, March 1997. 335 [RELATIONAL] Segmuller, W. "Sieve Extension: Relational Tests", RFC 336 3431, December 2002. 338 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 339 January 2001. 341 6.2 Non-Normative References 343 [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application 344 Configuration Access Protocol", RFC 2244, November 1997. 346 7 Acknowledgments 348 Thanks to Tony Hansen, Jutta Degener, Ned Freed, Ashish Gawarikar 349 and Nigel Swinson for comments and corrections. 351 8 Author's Address 353 Cyrus Daboo 354 Cyrusoft International, Inc. 355 5001 Baum Blvd., Suite 780, 356 Pittsburgh, PA 15213 357 U.S.A. 359 361 9 Intellectual Property Rights Statement 363 The IETF takes no position regarding the validity or scope of any 364 intellectual property or other rights that might be claimed to 365 pertain to the implementation or use of the technology described in 366 this document or the extent to which any license under such rights 367 might or might not be available; neither does it represent that it 368 has made any effort to identify any such rights. Information on the 369 IETF's procedures with respect to rights in standards-track and 370 standards-related documentation can be found in BCP-11. Copies of 371 claims of rights made available for publication and any assurances 372 of licenses to be made available, or the result of an attempt made 373 to obtain a general license or permission for the use of such 374 proprietary rights by implementors or users of this specification 375 can be obtained from the IETF Secretariat. 377 10 Full Copyright Statement 379 Copyright (C) The Internet Society 2003. All Rights Reserved. 381 This document and translations of it may be copied and furnished to 382 others, and derivative works that comment on or otherwise explain it 383 or assist in its implementation may be prepared, copied, published 384 and distributed, in whole or in part, without restriction of any 385 kind, provided that the above copyright notice and this paragraph 386 are included on all such copies and derivative works. However, this 387 document itself may not be modified in any way, such as by removing 388 the copyright notice or references to the Internet Society or other 389 Internet organizations, except as needed for the purpose of 390 developing Internet standards in which case the procedures for 391 copyrights defined in the Internet Standards process must be 392 followed, or as required to translate it into languages other than 393 English. 395 The limited permissions granted above are perpetual and will not be 396 revoked by the Internet Society or its successors or assigns. 398 This document and the information contained herein is provided on an 399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 403 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.