idnits 2.17.1 draft-ietf-sieve-body-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 400 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 35 instances of lines with control characters in the document. ** 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 107: '...The implementation MUST NOT remove any...' RFC 2119 keyword, line 108: '...rom the message, MUST NOT refuse to fi...' RFC 2119 keyword, line 110: '...m outright), and MUST NOT interpret or...' RFC 2119 keyword, line 153: '...ansfer encodings MUST be decoded to pr...' RFC 2119 keyword, line 154: '...ansfer encodings MAY be decoded, omitt...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 283 has weird spacing: '...ription reque...' -- 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 2005) is 7010 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 section? 'SIEVE' on line 321 looks like a reference -- Missing reference section? 'KEYWORDS' on line 314 looks like a reference -- Missing reference section? 'COMPARATOR' on line 68 looks like a reference -- Missing reference section? 'MATCH-TYPE' on line 68 looks like a reference -- Missing reference section? 'BODY-TRANSFORM' on line 68 looks like a reference -- Missing reference section? 'MIME' on line 317 looks like a reference -- Missing reference section? 'UTF-8' on line 324 looks like a reference -- Missing reference section? 'REGEX' on line 211 looks like a reference -- Missing reference section? 'VARIABLES' on line 329 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 15 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: August 2005 Sendmail, Inc. 4 February 2005 6 Sieve Mail Filtering Language: Body Extension 7 9 Status of this memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, or 13 will be disclosed, and any of which I become aware will be disclosed, 14 in accordance with RFC 3668. 16 This document is an Internet-Draft and is subject to all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document defines a new primitive for the "Sieve" email filtering 39 language that tests for the occurrence of one or more strings in the 40 body of an email message. 42 1. Introduction 44 The proposed "body" test checks for the occurrence of one 45 or more strings in the body of an email message. 46 Such a test was initially discussed for the [SIEVE] base 47 document, but was subsequently removed because it was 48 thought to be too costly to implement. 50 Nevertheless, several server vendors have implemented 51 some form of the "body" test. 53 This document reintroduces the "body" test as an extension, 54 and specifies it syntax and semantics. 56 2. Conventions used. 58 Conventions for notations are as in [SIEVE] section 1.1, including 59 use of [KEYWORDS] and "Syntax:" label for the definition of action 60 and tagged arguments syntax. 62 The capability string associated with extension defined in this 63 document is "body". 65 3. Test body 67 Syntax: 68 "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] 69 71 The body test matches text in the body of an email message, 72 that is, anything following the first empty line after the header. 73 (The empty line itself, if present, is not considered to be part 74 of the body.) 76 The COMPARATOR and MATCH-TYPE keyword parameters are defined 77 in [SIEVE]. The BODY-TRANSFORM is a keyword parameter 78 discussed in section 4, below. 80 If a message consists of a header only, not followed by an empty 81 line, all "body" tests fail, including that for an empty string. 83 If a message consists of a header followed only by an empty 84 line with no body lines following it, the message is considered 85 to have an empty string as a body. 87 4. Body Transform 89 Prior to matching text in a message body, "transformations" 90 can be applied that filter and decode certain parts of the body. 91 These transformations are selected by a "BODY-TRANSFORM" 92 keyword parameter. 94 Syntax: 95 ":raw" 96 / ":content" 97 / ":text" 99 The default transformation is :text. 101 4.1 Body Transform ":raw" 103 The ":raw" transform is intended to match against the undecoded 104 body of a message. 106 If the specified body-transform is ":raw", the [MIME] structure of 107 the body is irrelevant. The implementation MUST NOT remove any 108 transfer encoding from the message, MUST NOT refuse to filter 109 messages with syntactic errors (unless the environment it is part 110 of rejects them outright), and MUST NOT interpret or skip MIME 111 headers of enclosed body parts. 113 Example: 115 require "body"; 117 # This will match a message containing the words "MAKE MONEY FAST" 118 # in body or MIME headers other than the outermost RFC 822 header, 119 # but will not match a message containing the words in a 120 # content-transfer-encoded body. 122 if body :raw :contains "MAKE MONEY FAST" { 123 reject; 124 } 126 4.2 Body Transform ":content" 128 If the body transform is ":content", only MIME parts that have 129 the specified content-types are selected for matching. 131 If an individual content type contains a '/' (slash), it 132 specifies a full / pair, and matches only 133 that specific content type. If it is the empty string, all 134 MIME content types are matched. Otherwise, it specifies a 135 only, and any subtype of that type matches it. 137 The search for MIME parts matching the :content specification is 138 recursive and automatically descends into multipart and 139 message/rfc822 MIME parts. Once a MIME part has been identified 140 as suitable for searching, only its direct contents are searched 141 for the key strings. 143 For example, a document with "multipart" major content type only 144 directly contains the text in its epilogue and prologue section; 145 all the user-visible data inside it is directly contained in 146 documents with MIME types other than multipart. 148 (Nevertheless, matches against container types with an empty 149 match string can be useful as tests for the existence of such 150 document parts.) 152 MIME parts encoded in "quoted-printable" or "base64" content 153 transfer encodings MUST be decoded to prior to the match. 154 MIME parts in other transfer encodings MAY be decoded, omitted 155 from the test, or processed as raw data. 157 MIME parts identified as using charsets other than UTF-8 as 158 defined in [UTF-8] SHOULD be converted to UTF-8 prior to the match. 159 A conversion from US-ASCII to UTF-8 MUST be supported. 160 If an implementation does not support conversion of a given 161 charset to UTF-8, it MAY compare against the US-ASCII subset 162 of the transfer-decoded character data instead. Characters from 163 documents tagged with charsets that the local implementation 164 cannot convert to UTF-8 and text from mistagged documents MAY 165 be omitted or processed according to local conventions. 167 Search expressions MUST NOT match across MIME part boundaries. 168 MIME headers of the containing text MUST NOT be included in the 169 data. 171 Example: 172 require ["body", "fileinto"]; 174 # Save any message with any text MIME part that contains the 175 # worlds "missile" or "coordinates" in the "secrets" folder. 177 if body :content "text" :contains ["missile", "coordinates"] { 178 fileinto "secrets"; 179 } 181 # Save any message with an audio/mp3 MIME part in 182 # the "jukebox" folder. 184 if body :content "audio/mp3" :contains "" { 185 fileinto "jukebox"; 186 } 188 4.3 Body Transform ":text" 190 The ":text" body transform matches against the results of 191 an implementation's best effort at extracting UTF-8 encoded 192 text from a message. 194 In simple implementations, :text MAY be treated the same 195 as :content "text". 197 Sophisticated implementations MAY strip mark-up from the text 198 prior to matching, and MAY convert media types other than text 199 to text prior to matching. 201 (For example, they may be able to convert proprietary text 202 editor formats to text or apply optical character recognition 203 algorithms to image data.) 205 5. Interaction with Other Sieve Extensions 207 Any extension that extends the grammar for the COMPARATOR or 208 MATCH-TYPE nonterminals will also affect the implementation of 209 "body". 211 The [REGEX] extension can place a considerable load on a system 212 when applied to whole bodies of messages, especially when 213 implemented naively or used maliciously. 215 Regular and wildcard expressions used with "body" are exempt 216 from the side effects described in [VARIABLES]. That is, they 217 do not set numbered variables ${1}, ${2}... to the input 218 values corresponding to wild card sequences in the matched 219 pattern. However, variable references in the pattern string 220 are evaluated as described in the draft, if the extension 221 is present. 223 6. IANA Considerations 225 The following template specifies the IANA registration of the Sieve 226 extension specified in this document: 228 To: iana@iana.org 229 Subject: Registration of new Sieve extension 231 Capability name: body 232 Capability keyword: body 233 Capability arguments: N/A 234 Standards Track/IESG-approved experimental RFC number: this RFC 235 Person and email address to contact for further information: 237 Jutta Degener 238 jutta@pobox.com 240 This information should be added to the list of sieve extensions 241 given on http://www.iana.org/assignments/sieve-extensions. 243 7. Security Considerations 245 The system MUST be sized and restricted in such a manner that 246 even malicious use of body matching does not deny service to 247 other users of the host system. 249 Filters relying on string matches in the raw body of an email 250 message may be more general than intended. Text matches are no 251 replacement for a virus or spam filtering system. 253 8. Acknowledgments 255 This document has been revised in part based on comments and 256 discussions that took place on and off the SIEVE mailing list. 257 Thanks to Cyrus Daboo, Ned Freed, Simon Josefsson, Mark E. Mallet, 258 Chris Markle, Greg Shapiro, Tim Showalter, Nigel Swinson, 259 and Dowson Tong for reviews and suggestions. 261 9. Authors' Addresses 263 Jutta Degener 264 5245 College Ave, Suite #127 265 Oakland, CA 94618 267 Email: jutta@pobox.com 269 Philip Guenther 270 Sendmail, Inc. 271 6425 Christie Ave, 4th Floor 272 Emeryville, CA 94608 274 Email: guenther@sendmail.com 276 10. Discussion 278 This section will be removed when this document leaves the 279 Internet-Draft stage. 281 This draft is intended as an extension to the Sieve mail filtering 282 language. Sieve extensions are discussed on the MTA Filters mailing 283 list at . Subscription requests can 284 be sent to (send an email 285 message with the word "subscribe" in the body). 287 More information on the mailing list along with a WWW archive of 288 back messages is available at . 290 10.1 Changes from draft-degener-sieve-body-04.txt 291 Renamed to draft-ietf-sieve-body-00.txt; tweaked the title and abstract. 293 Added Philip Guenther as co-author. 295 Split references into normative and informative. Updated [UTF-8] 296 and [VARIABLES] references. 298 Updated IPR boilerplate. 300 10.2 Changes from draft-degener-sieve-body-03.txt 302 Made "body" exempt from variable-setting side effects in the presence 303 of the "variables" extension and wild cards. It's too hard to implement. 305 Removed :binary. It's uglier and less useful than it needs to be 306 to bother. 308 Added IANA section. 310 Appendices 312 Appendix A. Normative References 314 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", RFC 2119, March 1997. 317 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 318 Extensions (MIME) Part One: Format of Internet Message 319 Bodies", RFC 2045, November 1996. 321 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, 322 January 2001. 324 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 325 RFC 3629, November 2003. 327 Appendix B. Informative References 329 [VARIABLES] Homme, K.T., "Sieve Mail Filtering Language: Variables 330 Extension", draft-ietf-sieve-variables-01.txt, February 2005 332 Appendix C. Copyright Statement 334 Copyright (C) The Internet Society (2005). 336 This document is subject to the rights, licenses and restrictions 337 contained in BCP 78, and except as set forth therein, the authors 338 retain all their rights. 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 342 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 343 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 344 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 345 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed 352 to pertain to the implementation or use of the technology 353 described in this document or the extent to which any license 354 under such rights might or might not be available; nor does it 355 represent that it has made any independent effort to identify any 356 such rights. Information on the IETF's procedures with respect to 357 rights in IETF Documents can be found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use 362 of such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository 364 at http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention 367 any copyrights, patents or patent applications, or other 368 proprietary rights that may cover technology that may be required 369 to implement this standard. Please address the information to the 370 IETF at ietf-ipr@ietf.org. 372 Acknowledgement 374 Funding for the RFC Editor function is currently provided by 375 the Internet Society.