idnits 2.17.1 draft-ietf-sieve-body-05.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 on line 14. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '...t. The implementation MUST NOT remove...' RFC 2119 keyword, line 112: '...rom the message, MUST NOT refuse to fi...' RFC 2119 keyword, line 114: '...m outright), and MUST treat multipart ...' RFC 2119 keyword, line 228: '... converted MAY be treated as plain U...' RFC 2119 keyword, line 230: '... SHOULD NOT cause early termination ...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [KEYWORDS], but that reference does not seem to mention RFC 2119 either. -- 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 (November 2006) is 6371 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? 'SIEVE' on line 442 looks like a reference -- Missing reference section? 'KEYWORDS' on line 435 looks like a reference -- Missing reference section? 'COMPARATOR' on line 72 looks like a reference -- Missing reference section? 'MATCH-TYPE' on line 72 looks like a reference -- Missing reference section? 'BODY-TRANSFORM' on line 72 looks like a reference -- Missing reference section? 'MIME' on line 438 looks like a reference -- Missing reference section? 'UTF-8' on line 445 looks like a reference -- Missing reference section? 'VARIABLES' on line 450 looks like a reference -- Missing reference section? 'REGEX' on line 406 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jutta Degener 2 Internet Draft Philip Guenther 3 Expires: May 2007 Sendmail, Inc. 4 November 2006 6 Sieve Email Filtering: Body Extension 7 draft-ietf-sieve-body-05.txt 9 Status of this memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The IETF Trust (2006). 37 Abstract 39 This document defines a new command for the "Sieve" email 40 filtering language that tests for the occurrence of one or more 41 strings in the body of an email message. 43 1. Introduction 45 The proposed "body" test checks for the occurrence of one 46 or more strings in the body of an email message. 47 Such a test was initially discussed for the [SIEVE] base 48 document, but was subsequently removed because it was 49 thought to be too costly to implement. 51 Nevertheless, several server vendors have implemented 52 some form of the "body" test. 54 This document reintroduces the "body" test as an extension, 55 and specifies its syntax and semantics. 57 2. Conventions used. 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [KEYWORDS]. 63 Conventions for notations are as in [SIEVE] section 1.1, including 64 use of the "Usage:" label for the definition of text and tagged 65 arguments syntax. 67 The capability string associated with the extension defined in 68 this document is "body". 70 3. Test body 72 Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] 73 75 The body test matches text in the body of an email message, that 76 is, anything following the first empty line after the header. 77 (The empty line itself, if present, is not considered to be part 78 of the body.) 80 The COMPARATOR and MATCH-TYPE keyword parameters are defined 81 in [SIEVE]. The BODY-TRANSFORM is a keyword parameter 82 discussed in section 4, below. 84 If a message consists of a header only, not followed by an empty 85 line, all "body" tests return false, including that for an empty 86 string. 88 If a message consists of a header followed only by an empty 89 line with no body lines following it, the message is considered 90 to have an empty string as a body. 92 4. Body Transform 94 Prior to matching text in a message body, "transformations" 95 can be applied that filter and decode certain parts of the body. 96 These transformations are selected by a "BODY-TRANSFORM" 97 keyword parameter. 99 Usage: ":raw" 100 / ":content" 101 / ":text" 103 The default transformation is :text. 105 4.1 Body Transform ":raw" 107 The ":raw" transform is intended to match against the undecoded 108 body of a message. 110 If the specified body-transform is ":raw", the [MIME] structure 111 of the body is irrelevant. The implementation MUST NOT remove 112 any transfer encoding from the message, MUST NOT refuse to filter 113 messages with syntactic errors (unless the environment it is 114 part of rejects them outright), and MUST treat multipart boundaries 115 or the MIME headers of enclosed body parts as part of the text 116 being matched against instead of MIME structures to interpret. 118 Example: 120 require "body"; 122 # This will match a message containing the literal text 123 # "MAKE MONEY FAST" in body parts (ignoring any 124 # content-transfer-encodings) or MIME headers other than 125 # the outermost RFC 2822 header. 127 if body :raw :contains "MAKE MONEY FAST" { 128 discard; 129 } 131 4.2 Body Transform ":content" 133 If the body transform is ":content", only MIME parts that have 134 the specified content-types are selected for matching. 136 If an individual content type begins or ends with a '/' (slash) 137 or contains multiple slashes, it matches no content types. 138 Otherwise, if it contains a slash, then it specifies a full 139 / pair, and matches only that specific content 140 type. If it is the empty string, all MIME content types are 141 matched. Otherwise, it specifies a only, and any subtype 142 of that type matches it. 144 The search for MIME parts matching the :content specification 145 is recursive and automatically descends into multipart and 146 message/rfc822 MIME parts. All MIME parts with matching types 147 are searched for the key strings. The test returns true if any 148 combination of searched MIME part and key-list argument match. 150 If the :content specification matches a multipart MIME part, 151 only the prologue and epilogue sections of the part will be 152 searched for the key strings; the contents of nested parts are 153 only searched if their respective types match the :content 154 specification. 156 If the :content specification matches a message/rfc822 MIME part, 157 only the header of the nested message will be searched for the 158 key strings; the contents of the nested message body parts are 159 only searched if its content-type matches the :content specification. 161 (Matches against container types with an empty match string can 162 be useful as tests for the existence of such parts.) 163 Example: 164 From: Whomever 165 To: Someone 166 Date: Whenever 167 Subject: whatever 168 Content-Type: multipart/mixed; boundary=outer 170 & This is a multi-part message in MIME format. 171 & 172 --outer 173 Content-Type: multipart/alternative; boundary=inner 175 & This is a nested multi-part message in MIME format. 176 & 177 --inner 178 Content-Type: text/plain; charset="us-ascii" 180 $ Hello 181 $ 182 --inner 183 Content-Type: text/html; charset="us-ascii" 185 % Hello 186 % 187 --inner-- 188 & 189 & This is the end of the inner MIME multipart. 190 & 191 --outer 192 Content-Type: message/rfc822 194 ! From: Someone Else 195 ! Subject: hello request 197 $ Please say Hello 198 $ 199 --outer-- 200 & 201 & This is the end of the outer MIME multipart. 203 In the above example, the '&', '$', '%', and '!' characters at 204 the start of a line are used to illustrate what portions of the 205 example message are used in tests: 207 - the lines starting with '&' are the ones that are tested when 208 a 'body :content "multipart" :contains "MIME"' 209 test is executed. 211 - the lines starting with '$' are the ones that are tested when 212 a 'body :content "text/plain" :contains "Hello"' test is 213 executed. 215 - the lines starting with '%' are the ones that are tested when 216 a 'body :content "text/html" :contains "Hello"' test is executed. 218 - the lines starting with '$' or '%' are the ones that are tested 219 when a 'body :content "text" :contains "Hello"' test is executed. 221 - the lines starting with '!' are the ones that are tested when 222 a 'body :content "message/rfc822" :contains "Hello"' test is 223 executed. 225 Comparisons are performed on octets. Implementations decode 226 the content-transfer-encoding and convert text to [UTF-8] as 227 input to the comparator. MIME parts that cannot be decoded and 228 converted MAY be treated as plain US-ASCII, omitted, or processed 229 according to local conventions. A NUL octet (character zero) 230 SHOULD NOT cause early termination of the content being compared 231 against. Implementations MUST support the "quoted-printable", 232 "base64", "7bit", "8bit", and "binary" content transfer encodings. 233 Implementations MUST be capable of converting to UTF-8 the 234 US-ASCII, ISO-8859-1, and the US-ASCII subset of 235 ISO-8859-* character sets. 237 Search expressions MUST NOT match across MIME part boundaries. 238 MIME headers of the containing part MUST NOT be included in the 239 data. 241 Example: 242 require ["body", "fileinto"]; 244 # Save any message with any text MIME part that contains the 245 # words "missile" or "coordinates" in the "secrets" folder. 247 if body :content "text" :contains ["missile", "coordinates"] { 248 fileinto "secrets"; 249 } 251 # Save any message with an audio/mp3 MIME part in 252 # the "jukebox" folder. 254 if body :content "audio/mp3" :contains "" { 255 fileinto "jukebox"; 256 } 258 4.3 Body Transform ":text" 260 The ":text" body transform matches against the results of 261 an implementation's best effort at extracting UTF-8 encoded 262 text from a message. 264 In simple implementations, :text MAY be treated the same 265 as :content "text". 267 Sophisticated implementations MAY strip mark-up from the text 268 prior to matching, and MAY convert media types other than text 269 to text prior to matching. 271 (For example, they may be able to convert proprietary text 272 editor formats to text or apply optical character recognition 273 algorithms to image data.) 275 Example: 276 require ["body", "fileinto"]; 278 # Save messages mentioning the project schedule in the 279 # project/schedule folder. 280 if body :text :contains "project schedule" { 281 fileinto "project/schedule"; 282 } 284 5. Interaction with Other Sieve Extensions 286 Any extension that extends the grammar for the COMPARATOR or 287 MATCH-TYPE nonterminals will also affect the implementation of 288 "body". 290 Wildcard expressions used with "body" are exempt from the side 291 effects described in [VARIABLES]. That is, they MUST NOT set 292 match variables (${1}, ${2}...) to the input values corresponding 293 to wild card sequences in the matched pattern. However, if the 294 extension is present, variable references in the key strings or 295 content type strings are evaluated as described in the draft. 297 6. IANA Considerations 299 The following template specifies the IANA registration of the Sieve 300 extension specified in this document: 302 To: iana@iana.org 303 Subject: Registration of new Sieve extension 305 Capability name: body 306 Description: adds the 'body' test for matching against the 307 the body of the message being processed 308 RFC number: this RFC 309 Contact Address: Jutta Degener 311 This information should be added to the list of sieve extensions 312 given on http://www.iana.org/assignments/sieve-extensions. 314 7. Security Considerations 316 The system MUST be sized and restricted in such a manner that 317 even malicious use of body matching does not deny service to 318 other users of the host system. 320 Filters relying on string matches in the raw body of an email 321 message may be more general than intended. Text matches are no 322 replacement for a spam, virus, or other security related 323 filtering system. 325 8. Acknowledgments 327 This document has been revised in part based on comments and 328 discussions that took place on and off the SIEVE mailing list. 329 Thanks to Cyrus Daboo, Ned Freed, Bob Johannessen, Simon Josefsson, 330 Mark E. Mallett, Chris Markle, Alexey Melnikov, Ken Murchison, 331 Greg Shapiro, Tim Showalter, Nigel Swinson, and Dowson Tong for 332 reviews and suggestions. 334 9. Authors' Addresses 336 Jutta Degener 337 5245 College Ave, Suite #127 338 Oakland, CA 94618 340 Email: jutta@pobox.com 342 Philip Guenther 343 Sendmail, Inc. 344 6425 Christie Ave, 4th Floor 345 Emeryville, CA 94608 347 Email: guenther@sendmail.com 349 10. Discussion 351 This section will be removed when this document leaves the 352 Internet-Draft stage. 354 This draft is intended as an extension to the Sieve mail filtering 355 language. Sieve extensions are discussed on the MTA Filters mailing 356 list at . Subscription requests can 357 be sent to (send an email 358 message with the word "subscribe" in the body). 360 More information on the mailing list along with a WWW archive of 361 back messages is available at . 363 10.1 Changes from draft-ietf-sieve-body-04.txt 365 Changed 'reject' to 'discard' in the example. 367 Removed reference to regex draft. 369 Update copyright boilerplate. 371 10.2 Changes from draft-ietf-sieve-body-03.txt 373 Update IANA registration to match 3028bis. 375 Added direct boilerplate for [KEYWORDS]. 377 10.3 Changes from draft-ietf-sieve-body-02.txt 379 Updated charset conversion to match draft-ietf-sieve-3028bis-06.txt. 381 Change "Syntax:" to "Usage:". 383 Updated references. 385 10.4 Changes from draft-ietf-sieve-body-01.txt 387 Updated charset conversion requirements to match those in 388 draft-ietf-sieve-3028bis-03.txt for headers. 390 10.5 Changes from draft-ietf-sieve-body-00.txt 392 Updated IPR boilerplate to RFC 3978/3979. 394 Many prose corrections in response to WGLC comments. Of particular 395 note: 396 - made clear that :raw treats MIME boundaries and headers as 397 text to be matched against 398 - corrected description in comment of :raw example 399 - clarified the interpretation of invalid content-types in 400 :content 401 - gave precise description of what gets matched when :content 402 is used with message/rfc822 or any multipart type, as well 403 as a comprehensive example 404 - include an example of :text 405 - tightened wording of interaction with [VARIABLES] 406 - added informative reference to [REGEX] 408 10.6 Changes from draft-degener-sieve-body-04.txt 410 Renamed to draft-ietf-sieve-body-00.txt; tweaked the title and 411 abstract. 413 Added Philip Guenther as co-author. 415 Split references into normative and informative. Updated [UTF-8] 416 and [VARIABLES] references. 418 Updated IPR boilerplate. 420 10.7 Changes from draft-degener-sieve-body-03.txt 422 Made "body" exempt from variable-setting side effects in the 423 presence of the "variables" extension and wild cards. It's too 424 hard to implement. 426 Removed :binary. It's uglier and less useful than it needs to be 427 to bother. 429 Added IANA section. 431 Appendices 433 Appendix A. Normative References 435 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", RFC 2119, March 1997. 438 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 439 Extensions (MIME) Part One: Format of Internet Message 440 Bodies", RFC 2045, November 1996. 442 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 443 Language", draft-ietf-sieve-3028bis-10, November 2006. 445 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 446 10646", RFC 3629, November 2003. 448 Appendix B. Informative References 450 [VARIABLES] Homme, K. T., "Sieve Extension: Variables", 451 draft-ietf-sieve-variables-08.txt, December 2005. 453 Copyright Statement 455 Copyright (C) The IETF Trust (2006). 457 This document is subject to the rights, licenses and restrictions 458 contained in BCP 78, and except as set forth therein, the authors 459 retain all their rights. 461 This document and the information contained herein are provided 462 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 463 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 464 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 465 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 466 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 467 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 468 OR FITNESS FOR A PARTICULAR PURPOSE 470 Intellectual Property 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use 484 of such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository 486 at http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention 489 any copyrights, patents or patent applications, or other 490 proprietary rights that may cover technology that may be required 491 to implement this standard. Please address the information to the 492 IETF at ietf-ipr@ietf.org. 494 Acknowledgement 496 Funding for the RFC Editor function is currently provided by 497 the Internet Society.