idnits 2.17.1 draft-ietf-sieve-mime-loop-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 542. ** 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. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 150 has weird spacing: '... :type parse...' == Line 154 has weird spacing: '...subtype parse...' == Line 158 has weird spacing: '...enttype parse...' == Line 162 has weird spacing: '... :param parse...' -- 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 22, 2006) is 6395 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: 'MIMEOPTS' is mentioned on line 123, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 213, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 214, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 214, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-09 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-09) exists of draft-ietf-sieve-body-04 == Outdated reference: A later version (-11) exists of draft-ietf-sieve-editheader-06 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Hansen 3 Internet-Draft AT&T Laboratories 4 Intended status: Standards Track C. Daboo 5 Expires: April 25, 2007 Apple Computer 6 October 22, 2006 8 SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and 9 Enclosure 10 draft-ietf-sieve-mime-loop-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 25, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The SIEVE email filtering language has no way to examine individual 44 MIME parts or any way to manipulate those individual parts. However, 45 being able to filter based on MIME content is important. This 46 document defines extensions for these needs. 48 Note 50 This document is being discussed on the MTA-FILTERS mailing list, 51 ietf-mta-filters@imc.org. 53 1. Introduction 55 SIEVE scripts are used to make decisions about the disposition of an 56 email message. The base SIEVE specification, 57 [I-D.ietf-sieve-3028bis], defines operators for looking at the 58 message headers, such as addresses and the subject. Other extensions 59 provide access to the body of the message ([I-D.ietf-sieve-body]), or 60 allow you to manipulate the header of the message 61 ([I-D.ietf-sieve-editheader]). But none of these extensions take 62 into account that MIME messages ([RFC2045]) are often complex 63 objects, consisting of many parts and sub-parts. This extension 64 defines mechanisms for performing tests on MIME body parts, looping 65 through the MIME body parts, changing the contents of a MIME body 66 part, and enclosing the message with a wrapper. 68 2. Conventions Used in This Document 70 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 71 1.1. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. SIEVE Loops 79 The base SIEVE language has no looping mechanism. Given that 80 messages may contain multiple parts, in order to support filters that 81 apply to any and all parts, we introduce a new control command: 82 "for_every_part", which is an iterator that walks though every MIME 83 part of a message, including nested parts, and applies the commands 84 in the specified block to each of them. The iterator will start with 85 the first MIME part (as its current context) and will execute a 86 command block (SIEVE commands enclosed by { ...}). Upon completion 87 of this command block, the iterator advances to the next MIME part 88 (as its current context) and executes the same command block again. 90 The iterator can be terminated prematurely by a new SIEVE command, 91 "break". 93 Usage: for_every_part block 95 Usage: break; 97 "for_every_part" commands can be nested inside other "for_every_part" 98 commands. When this occurs, the nested "for_every_part" iterates 99 over the MIME parts contained within the MIME part current being 100 targeted by the nearest enclosing "for_every_part" command. If that 101 MIME part is a terminal MIME part (i.e. does not contain other MIME 102 parts) then the nested "for_every_loop" is simply ignored. 104 SIEVE implementations MAY limit the number of nested loops that occur 105 within one another, however they MUST support at least one nested 106 loop inside another loop. 108 4. Changes to SIEVE tests 110 This specification extends the base SIEVE "header", "address" and 111 "exists" tests to support targeting those tests at a specific MIME 112 part or at all MIME parts in the enclosing scope. 114 4.1. Test "header" 116 The "header" test is extended with the addition of a new ":mime" 117 tagged argument, which takes a number of other arguments. 119 Usage: header [:mime] [:anychild] [MIMEOPTS] 120 [COMPARATOR] [MATCH-TYPE] 121 123 Usage: The definition of [MIMEOPTS] is: 125 Syntax: ":type" / ":subtype" / ":contenttype" / 126 ":param" 128 When the ":mime" tagged argument is present in the "header" test, it 129 will parse the MIME header lines in a message so that tests can be 130 performed on specific elements. 132 If the ":anychild" tagged argument is NOT specified: 134 o If used within the context of a "for_every_part" iterator, the 135 "header" test will examine the headers associated with the current 136 MIME part context from the loop. 138 o If used outside the context of a "for_every_part" iterator, the 139 "header" test will examine only the outer, top-level, headers of 140 the message. 142 If the ":anychild" tagged argument IS specified, the "header" test 143 will examine all MIME body parts and return true if any of them 144 satisfies the test. 146 The "header" test with the ":mime" tagged argument can test various 147 aspects of certain structed MIME headers. These options are 148 available: 150 :type parses the header assuming it has the format of a "Content- 151 Type:" MIME header field, and tests the value of the MIME type 152 specified in the header. 154 :subtype parses the header assuming it has the format of a "Content- 155 Type:" MIME header field, and tests the value of the MIME subtype 156 specified in the header. 158 :contenttype parses the header assuming it has the format of a 159 "Content-Type:" MIME header field, and tests the combined value of 160 the MIME type and subtype specified in the header. 162 :param parses the header looking for MIME parameters in the header. 163 The supplied string-list lists the names of any parameters to be 164 tested. If any one named parameter value matches the test string 165 value, the test will return true. 167 Example: 169 require ["mime", "fileinto"]; 171 if header :mime :type :comparator "Content-Type" "image" 172 { 173 fileinto "INBOX.images"; 174 } 176 In this example, any message that contains a MIME image type part at 177 the top-level is saved to the mailbox "INBOX.images". 179 Example: 181 require ["mime", "fileinto"]; 183 if header :mime :anychild :contenttype :comparator 184 "Content-Type" "text/html" 185 { 186 fileinto "INBOX.html"; 187 } 188 In this example, any message that contains any MIME part with a 189 content-type of "text/html" is saved to the mailbox "INBOX.html". 191 Example: 193 require ["mime", "for_every_part", "fileinto"]; 195 for_every_part 196 { 197 if header :mime :param "filename" :comparator 198 "Content-Disposition" "important" 199 { 200 fileinto "INBOX.important"; 201 break; 202 } 204 In this example, any message that contains any MIME part with a 205 content-disposition with a filename parameter containing the text 206 "important" is saved to the mailbox "INBOX.important". 208 4.2. Test "address" 210 The "address" test is extended with the addition of a new ":mime" 211 tagged argument, which takes a number of other arguments. 213 Usage: address [:mime] [:anychild] [COMPARATOR] 214 [ADDRESS-PART] [MATCH-TYPE] 215 217 When the ":mime" tagged argument is present in the "address" test, it 218 will parse the MIME header lines as if they were standard address 219 header lines in a message so that tests can be performed on specific 220 elements. 222 The behavior of the ":anychild" tagged argument and the interaction 223 with the "for_every_part" iterator is the same as for the extended 224 "header" test Section 4.1. 226 Example: 228 require ["mime", "fileinto"]; 230 if address :mime :is :all "content-from" "tim@example.com" 231 { 232 fileinto "INBOX.part-from-tim"; 233 } 235 In this example, any message that contains a MIME Content-From header 236 at the top-level matching the text "tim@example.com" is saved to the 237 mailbox "INBOX.part-from-time". 239 4.3. Test "exists" 241 The "exists" test is extended with the addition of a new ":mime" 242 tagged argument, which takes one other argument. 244 Usage: exists [:mime] [:anychild] 246 When the ":mime" tagged argument is present in the "exists" test, the 247 test is extended to check for the existence of MIME headers in MIME 248 parts. 250 The behavior of the ":anychild" tagged argument and the interaction 251 with the "for_every_part" iterator is the same as for the extended 252 "header" test Section 4.1. 254 Example: 256 require ["mime", "fileinto"]; 258 if exists :mime :anychild "content-md5" 259 { 260 fileinto "INBOX.md5"; 261 } 263 In this example, any message that contains a MIME Content-MD5 header 264 in any MIME part is saved to the mailbox "INBOX.md5". 266 5. Action Replace 268 Usage: replace [:mime] [:subject string] [:from string] 269 271 The "replace" command is defined to allow a MIME part to be replaced 272 with the text supplied in the command. 274 When used in the context of a "for_every_part" iterator, the MIME 275 part to be replaced is the "current" MIME part. If the current MIME 276 context is a multipart MIME part, the entire multipart MIME part is 277 replaced, which would alter the MIME structure of the message by 278 eliminating all of the children of the multipart part. (Replacing a 279 non-multipart MIME part within a "for_every_part" loop context does 280 not alter the overall message structure.) 282 When used outside the context of a "for_every_part" loop, the MIME 283 part to be replaced is the entire message. 285 If the :mime parameter is not specified, the replacement string is a 286 text/plain part. 288 If the :mime parameter is specified, then the replacement string is, 289 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 290 both MIME headers and content. If the optional :mime parameter is 291 not supplied, the reason string is considered to be a UTF-8 string. 293 If the entire message is being replaced, a ":subject" parameter 294 specifies a subject line to attach to the message that is generated. 295 UTF-8 characters can be used in the string argument; implementations 296 MUST convert the string to [RFC2047] encoded words if and only if 297 non-ASCII characters are present. Implementations MUST preserve the 298 previous Subject header as an Original-Subject header. 300 If the entire message is being replaced, a ":from" parameter may be 301 used to specify an alternate address to use in the From field of the 302 message that is generated. The string must specify a valid [RFC2822] 303 mailbox-list. Implementations SHOULD check the syntax and generate 304 an error when a syntactically invalid ":from" parameter is specified. 305 Implementations MAY also impose restrictions on what addresses can be 306 specified in a ":from" parameter; it is suggested that values that 307 fail such a validity check simply be ignored rather than causing the 308 vacation action to fail. Implementations MUST preserve the previous 309 From header as an Original-From header. 311 6. Action Enclose 313 Usage: enclose <:subject string> <:headers string-list> string 315 A new SIEVE action command is defined to allow an entire message to 316 be enclosed as an attachment to a new message. This enclose action 317 takes precedence over all other message modifications, such as 318 "replace". If multiple "enclose" actions are executed by a script, 319 only the text specified on the last one is used when creating the 320 enclosed message. This action does not affect messages that are 321 forwarded via a "redirect" action. 323 Specifically, the original message becomes a multipart/mixed message 324 with two parts: a text/plain portion with the string argument as its 325 body, and a message/rfc822 portion with the original message 326 enclosed. The Content-Type: header field becomes multipart/mixed. 327 The Subject: header is specified by the :subject argument. Any 328 headers specified by :headers are copied from the old message into 329 the new message. 331 7. SIEVE Capability Strings 333 A SIEVE implementation that defines the "for_every_part" and "break" 334 actions will advertise the capability string "for_every_part". 336 A SIEVE implementation that defines the ":mime" tagged arguments to 337 the "header", "address" and "exists" commands will advertise the 338 capability string "mime". 340 A SIEVE implementation that defines the "replace" action will 341 advertise the capability string "replace". 343 A SIEVE implementation that defines the "enclose" action will 344 advertise the capability string "enclose". 346 8. Examples 348 8.1. Example 1 350 A SIEVE script to replace all the Windows executable attachments in a 351 message would be: 353 require [ "for_every_part", "mime", "replace" ]; 354 for_every_part 355 { 356 if ( anyof ( header :mime :subtype :is "Content-Type" "exe", 357 header :mime :param "filename" 358 ["Content-Type" "Content-Disposition"] :matches "*.com" ) 359 { 360 replace "Executable attachment removed by user filter"; 361 } 362 } 364 8.2. Example 2 366 A SIEVE script to warn the user about executable attachment types 367 would be: 369 require [ "for_every_part", "mime", "enclose" ]; 371 for_every_part 372 { 373 if header :mime :param "filename" 374 ["Content-Type" "Content-Disposition"] :matches 375 ["*.com", "*.exe", "*.vbs", "*.scr", 376 "*.pif", "*.hta", "*.bat", "*.zip" ] 377 { 378 # these attachment types are executable 379 enclose :subject "Warning" " 380 WARNING! The enclosed message contains executable attachments. 381 These attachments types may contain a computer virus program 382 that can infect your computer and potentently damage your data 384 Before clicking on these message attachments, you should verify 385 with the sender that this message was sent by them and not a 386 computer virus. 387 "; 388 break; 389 } 390 } 392 9. Acknowledgements 394 Comments from members of the MTA Filters Working Group, in particular 395 Ned Freed, Nigel Swinson and Mark Mallett, are gratefully 396 acknowledged. 398 10. Security Considerations 400 To be provided 402 11. IANA Considerations 404 To be provided 406 12. Change History (to be removed prior to publication as an RFC) 408 12.1. draft-ietf-sieve-mime-01 410 what happens when nested for_every_loop's 412 a "mime" shorthand for testing the type/subtype, without requiring 413 interactions with variables notifications notifications to calendar 414 service address tests, exists tests mimeheader, mimeparameter tests 416 12.2. draft-ietf-sieve-mime-00 418 Changed title and text to emphasize MIME Tests. 420 Changed for.every.part to for_every_part. 422 Added :anychild to mime test. Default is to use the current context 423 or outer envelope; specifying :anychild will look at all children. 425 Added clarifications to replacing parts affecting the structure. 427 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 429 Various other minor nit fixes. 431 12.3. draft-hansen-sieve-loop-01 433 Merged with draft-daboo-sieve-mime-00.txt. 435 12.4. draft-hansen-sieve-loop-02 437 Update to 3028bis reference. 439 Added 2119 conventions section. 441 Terminology/title tweaks. 443 Added informative references to body and editheader extensions. 445 Added description of nested loops. 447 Replaced mime test by extensions to header, address and exists 448 tests. 450 13. References 452 13.1. Normative References 454 [I-D.ietf-sieve-3028bis] 455 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 456 Language", draft-ietf-sieve-3028bis-09 (work in progress), 457 August 2006. 459 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 460 Extensions (MIME) Part One: Format of Internet Message 461 Bodies", RFC 2045, November 1996. 463 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 464 Part Three: Message Header Extensions for Non-ASCII Text", 465 RFC 2047, November 1996. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 471 April 2001. 473 13.2. Informative References 475 [I-D.ietf-sieve-body] 476 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 477 Extension", draft-ietf-sieve-body-04 (work in progress), 478 August 2006. 480 [I-D.ietf-sieve-editheader] 481 Guenther, P. and J. Degener, "Sieve Email Filtering: 482 Editheader Extension", draft-ietf-sieve-editheader-06 483 (work in progress), August 2006. 485 Authors' Addresses 487 Tony Hansen 488 AT&T Laboratories 489 200 Laurel Ave. 490 Middletown, NJ 07748 491 USA 493 Email: tony+sieveloop@maillennium.att.com 495 Cyrus Daboo 496 Apple Computer, Inc. 497 1 Infinite Loop 498 Cupertino, CA 95014 499 USA 501 Email: cyrus@daboo.name 502 URI: http://www.apple.com/ 504 Full Copyright Statement 506 Copyright (C) The Internet Society (2006). 508 This document is subject to the rights, licenses and restrictions 509 contained in BCP 78, and except as set forth therein, the authors 510 retain all their rights. 512 This document and the information contained herein are provided on an 513 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 514 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 515 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 516 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 517 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 518 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 520 Intellectual Property 522 The IETF takes no position regarding the validity or scope of any 523 Intellectual Property Rights or other rights that might be claimed to 524 pertain to the implementation or use of the technology described in 525 this document or the extent to which any license under such rights 526 might or might not be available; nor does it represent that it has 527 made any independent effort to identify any such rights. Information 528 on the procedures with respect to rights in RFC documents can be 529 found in BCP 78 and BCP 79. 531 Copies of IPR disclosures made to the IETF Secretariat and any 532 assurances of licenses to be made available, or the result of an 533 attempt made to obtain a general license or permission for the use of 534 such proprietary rights by implementers or users of this 535 specification can be obtained from the IETF on-line IPR repository at 536 http://www.ietf.org/ipr. 538 The IETF invites any interested party to bring to its attention any 539 copyrights, patents or patent applications, or other proprietary 540 rights that may cover technology that may be required to implement 541 this standard. Please address the information to the IETF at 542 ietf-ipr@ietf.org. 544 Acknowledgment 546 Funding for the RFC Editor function is provided by the IETF 547 Administrative Support Activity (IASA).