idnits 2.17.1 draft-ietf-sieve-body-06.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 2007) is 6277 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: 'COMPARATOR' is mentioned on line 73, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 73, but not defined == Missing Reference: 'BODY-TRANSFORM' is mentioned on line 73, but not defined == Missing Reference: 'REGEX' is mentioned on line 417, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 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 Intended status: Standards Track Sendmail, Inc. 4 Expires: August 2007 February 2007 5 Updates: RFC-ietf-sieve-variables-08 7 Sieve Email Filtering: Body Extension 8 draft-ietf-sieve-body-06.txt 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines a new command for the "Sieve" email 41 filtering language that tests for the occurrence of one or more 42 strings in the body of an email message. 44 1. Introduction 46 The proposed "body" test checks for the occurrence of one 47 or more strings in the body of an email message. 48 Such a test was initially discussed for the [SIEVE] base 49 document, but was subsequently removed because it was 50 thought to be too costly to implement. 52 Nevertheless, several server vendors have implemented 53 some form of the "body" test. 55 This document reintroduces the "body" test as an extension, 56 and specifies its syntax and semantics. 58 2. Conventions used. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [KEYWORDS]. 64 Conventions for notations are as in [SIEVE] section 1.1, including 65 use of the "Usage:" label for the definition of text and tagged 66 arguments syntax. 68 The capability string associated with the extension defined in 69 this document is "body". 71 3. Test body 73 Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] 74 76 The body test matches text in the body of an email message, that 77 is, anything following the first empty line after the header. 78 (The empty line itself, if present, is not considered to be part 79 of the body.) 81 The COMPARATOR and MATCH-TYPE keyword parameters are defined 82 in [SIEVE]. The BODY-TRANSFORM is a keyword parameter 83 discussed in section 4, below. 85 If a message consists of a header only, not followed by an empty 86 line, all "body" tests return false, including that for an empty 87 string. 89 If a message consists of a header followed only by an empty 90 line with no body lines following it, the message is considered 91 to have an empty string as a body. 93 4. Body Transform 95 Prior to matching text in a message body, "transformations" 96 can be applied that filter and decode certain parts of the body. 97 These transformations are selected by a "BODY-TRANSFORM" 98 keyword parameter. 100 Usage: ":raw" 101 / ":content" 102 / ":text" 104 The default transformation is :text. 106 4.1 Body Transform ":raw" 108 The ":raw" transform is intended to match against the undecoded 109 body of a message. 111 If the specified body-transform is ":raw", the [MIME] structure 112 of the body is irrelevant. The implementation MUST NOT remove 113 any transfer encoding from the message, MUST NOT refuse to filter 114 messages with syntactic errors (unless the environment it is 115 part of rejects them outright), and MUST treat multipart boundaries 116 or the MIME headers of enclosed body parts as part of the text 117 being matched against instead of MIME structures to interpret. 119 Example: 121 require "body"; 123 # This will match a message containing the literal text 124 # "MAKE MONEY FAST" in body parts (ignoring any 125 # content-transfer-encodings) or MIME headers other than 126 # the outermost RFC 2822 header. 128 if body :raw :contains "MAKE MONEY FAST" { 129 discard; 130 } 132 4.2 Body Transform ":content" 134 If the body transform is ":content", only MIME parts that have 135 the specified content-types are selected for matching. 137 If an individual content type begins or ends with a '/' (slash) 138 or contains multiple slashes, it matches no content types. 139 Otherwise, if it contains a slash, then it specifies a full 140 / pair, and matches only that specific content 141 type. If it is the empty string, all MIME content types are 142 matched. Otherwise, it specifies a only, and any subtype 143 of that type matches it. 145 The search for MIME parts matching the :content specification 146 is recursive and automatically descends into multipart and 147 message/rfc822 MIME parts. All MIME parts with matching types 148 are searched for the key strings. The test returns true if any 149 combination of searched MIME part and key-list argument match. 151 If the :content specification matches a multipart MIME part, 152 only the prologue and epilogue sections of the part will be 153 searched for the key strings; the contents of nested parts are 154 only searched if their respective types match the :content 155 specification. 157 If the :content specification matches a message/rfc822 MIME part, 158 only the header of the nested message will be searched for the 159 key strings; the contents of the nested message body parts are 160 only searched if its content-type matches the :content specification. 162 (Matches against container types with an empty match string can 163 be useful as tests for the existence of such parts.) 164 Example: 165 From: Whomever 166 To: Someone 167 Date: Whenever 168 Subject: whatever 169 Content-Type: multipart/mixed; boundary=outer 171 & This is a multi-part message in MIME format. 172 & 173 --outer 174 Content-Type: multipart/alternative; boundary=inner 176 & This is a nested multi-part message in MIME format. 177 & 178 --inner 179 Content-Type: text/plain; charset="us-ascii" 181 $ Hello 182 $ 183 --inner 184 Content-Type: text/html; charset="us-ascii" 186 % Hello 187 % 188 --inner-- 189 & 190 & This is the end of the inner MIME multipart. 191 & 192 --outer 193 Content-Type: message/rfc822 195 ! From: Someone Else 196 ! Subject: hello request 198 $ Please say Hello 199 $ 200 --outer-- 201 & 202 & This is the end of the outer MIME multipart. 204 In the above example, the '&', '$', '%', and '!' characters at 205 the start of a line are used to illustrate what portions of the 206 example message are used in tests: 208 - the lines starting with '&' are the ones that are tested when 209 a 'body :content "multipart" :contains "MIME"' 210 test is executed. 212 - the lines starting with '$' are the ones that are tested when 213 a 'body :content "text/plain" :contains "Hello"' test is 214 executed. 216 - the lines starting with '%' are the ones that are tested when 217 a 'body :content "text/html" :contains "Hello"' test is executed. 219 - the lines starting with '$' or '%' are the ones that are tested 220 when a 'body :content "text" :contains "Hello"' test is executed. 222 - the lines starting with '!' are the ones that are tested when 223 a 'body :content "message/rfc822" :contains "Hello"' test is 224 executed. 226 Comparisons are performed on octets. Implementations decode 227 the content-transfer-encoding and convert text to [UTF-8] as 228 input to the comparator. MIME parts that cannot be decoded and 229 converted MAY be treated as plain US-ASCII, omitted, or processed 230 according to local conventions. A NUL octet (character zero) 231 SHOULD NOT cause early termination of the content being compared 232 against. Implementations MUST support the "quoted-printable", 233 "base64", "7bit", "8bit", and "binary" content transfer encodings. 234 Implementations MUST be capable of converting to UTF-8 the 235 US-ASCII, ISO-8859-1, and the US-ASCII subset of 236 ISO-8859-* character sets. 238 Search expressions MUST NOT match across MIME part boundaries. 239 MIME headers of the containing part MUST NOT be included in the 240 data. 242 Example: 243 require ["body", "fileinto"]; 245 # Save any message with any text MIME part that contains the 246 # words "missile" or "coordinates" in the "secrets" folder. 248 if body :content "text" :contains ["missile", "coordinates"] { 249 fileinto "secrets"; 250 } 252 # Save any message with an audio/mp3 MIME part in 253 # the "jukebox" folder. 255 if body :content "audio/mp3" :contains "" { 256 fileinto "jukebox"; 257 } 259 4.3 Body Transform ":text" 261 The ":text" body transform matches against the results of 262 an implementation's best effort at extracting UTF-8 encoded 263 text from a message. 265 In simple implementations, :text MAY be treated the same 266 as :content "text". 268 Sophisticated implementations MAY strip mark-up from the text 269 prior to matching, and MAY convert media types other than text 270 to text prior to matching. 272 (For example, they may be able to convert proprietary text 273 editor formats to text or apply optical character recognition 274 algorithms to image data.) 276 Example: 277 require ["body", "fileinto"]; 279 # Save messages mentioning the project schedule in the 280 # project/schedule folder. 281 if body :text :contains "project schedule" { 282 fileinto "project/schedule"; 283 } 285 5. Interaction with Other Sieve Extensions 287 Any extension that extends the grammar for the COMPARATOR or 288 MATCH-TYPE nonterminals will also affect the implementation of 289 "body". 291 Wildcard expressions used with "body" are exempt from the side 292 effects described in [VARIABLES]. That is, they MUST NOT set 293 match variables (${1}, ${2}...) to the input values corresponding 294 to wild card sequences in the matched pattern. However, if the 295 extension is present, variable references in the key strings or 296 content type strings are evaluated as described in the draft. 298 6. IANA Considerations 300 The following template specifies the IANA registration of the Sieve 301 extension specified in this document: 303 To: iana@iana.org 304 Subject: Registration of new Sieve extension 306 Capability name: body 307 Description: adds the 'body' test for matching against the 308 the body of the message being processed 309 RFC number: this RFC 310 Contact Address: Jutta Degener 312 This information should be added to the list of sieve extensions 313 given on http://www.iana.org/assignments/sieve-extensions. 315 7. Security Considerations 317 The system MUST be sized and restricted in such a manner that 318 even malicious use of body matching does not deny service to 319 other users of the host system. 321 Filters relying on string matches in the raw body of an email 322 message may be more general than intended. Text matches are no 323 replacement for a spam, virus, or other security related 324 filtering system. 326 8. Acknowledgments 328 This document has been revised in part based on comments and 329 discussions that took place on and off the SIEVE mailing list. 330 Thanks to Cyrus Daboo, Ned Freed, Bob Johannessen, Simon Josefsson, 331 Mark E. Mallett, Chris Markle, Alexey Melnikov, Ken Murchison, 332 Greg Shapiro, Tim Showalter, Nigel Swinson, and Dowson Tong for 333 reviews and suggestions. 335 9. Authors' Addresses 337 Jutta Degener 338 5245 College Ave, Suite #127 339 Oakland, CA 94618 341 Email: jutta@pobox.com 343 Philip Guenther 344 Sendmail, Inc. 345 6425 Christie Ave, 4th Floor 346 Emeryville, CA 94608 348 Email: guenther@sendmail.com 350 10. Discussion 352 This section will be removed when this document leaves the 353 Internet-Draft stage. 355 This draft is intended as an extension to the Sieve mail filtering 356 language. Sieve extensions are discussed on the MTA Filters mailing 357 list at . Subscription requests can 358 be sent to (send an email 359 message with the word "subscribe" in the body). 361 More information on the mailing list along with a WWW archive of 362 back messages is available at . 364 10.1 Changes from draft-ietf-sieve-body-05.txt 366 Updated boilerplate to match RFC 4748. 368 Added "Intended-Status: Standards Track" and 369 "Updates: draft-ietf-sieve-variables-08" 371 Change the references from appendices to sections. 372 Update [SIEVE] reference. 374 10.2 Changes from draft-ietf-sieve-body-04.txt 376 Changed 'reject' to 'discard' in the example. 378 Removed reference to regex draft. 380 Update copyright boilerplate. 382 10.3 Changes from draft-ietf-sieve-body-03.txt 384 Update IANA registration to match 3028bis. 386 Added direct boilerplate for [KEYWORDS]. 388 10.4 Changes from draft-ietf-sieve-body-02.txt 390 Updated charset conversion to match draft-ietf-sieve-3028bis-06.txt. 392 Change "Syntax:" to "Usage:". 394 Updated references. 396 10.5 Changes from draft-ietf-sieve-body-01.txt 398 Updated charset conversion requirements to match those in 399 draft-ietf-sieve-3028bis-03.txt for headers. 401 10.6 Changes from draft-ietf-sieve-body-00.txt 403 Updated IPR boilerplate to RFC 3978/3979. 405 Many prose corrections in response to WGLC comments. Of particular 406 note: 407 - made clear that :raw treats MIME boundaries and headers as 408 text to be matched against 409 - corrected description in comment of :raw example 410 - clarified the interpretation of invalid content-types in 411 :content 412 - gave precise description of what gets matched when :content 413 is used with message/rfc822 or any multipart type, as well 414 as a comprehensive example 415 - include an example of :text 416 - tightened wording of interaction with [VARIABLES] 417 - added informative reference to [REGEX] 419 10.7 Changes from draft-degener-sieve-body-04.txt 421 Renamed to draft-ietf-sieve-body-00.txt; tweaked the title and 422 abstract. 424 Added Philip Guenther as co-author. 426 Split references into normative and informative. Updated [UTF-8] 427 and [VARIABLES] references. 429 Updated IPR boilerplate. 431 10.8 Changes from draft-degener-sieve-body-03.txt 433 Made "body" exempt from variable-setting side effects in the 434 presence of the "variables" extension and wild cards. It's too 435 hard to implement. 437 Removed :binary. It's uglier and less useful than it needs to be 438 to bother. 440 Added IANA section. 442 11. Normative References 444 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 15, RFC 2119, March 1997. 447 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 448 Extensions (MIME) Part One: Format of Internet Message 449 Bodies", RFC 2045, November 1996. 451 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 452 Language", draft-ietf-sieve-3028bis-12, February 2007. 454 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 455 10646", RFC 3629, November 2003. 457 12. Informative References 459 [VARIABLES] Homme, K. T., "Sieve Extension: Variables", 460 draft-ietf-sieve-variables-08.txt, December 2005. 462 Full Copyright Statement 464 Copyright (C) The IETF Trust (2007). 466 This document is subject to the rights, licenses and restrictions 467 contained in BCP 78, and except as set forth therein, the authors 468 retain all their rights. 470 This document and the information contained herein are provided on an 471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 473 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 474 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 475 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 478 Intellectual Property 480 The IETF takes no position regarding the validity or scope of any 481 Intellectual Property Rights or other rights that might be claimed to 482 pertain to the implementation or use of the technology described in 483 this document or the extent to which any license under such rights 484 might or might not be available; nor does it represent that it has 485 made any independent effort to identify any such rights. Information 486 on the procedures with respect to rights in RFC documents can be 487 found in BCP 78 and BCP 79. 489 Copies of IPR disclosures made to the IETF Secretariat and any 490 assurances of licenses to be made available, or the result of an 491 attempt made to obtain a general license or permission for the use of 492 such proprietary rights by implementers or users of this 493 specification can be obtained from the IETF on-line IPR repository at 494 http://www.ietf.org/ipr. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights that may cover technology that may be required to implement 499 this standard. Please address the information to the IETF at 500 ietf-ipr@ietf.org. 502 Acknowledgement 504 Funding for the RFC Editor function is currently provided by the IETF 505 Administrative Support Activity (IASA). 507 ------- End of Forwarded Message