idnits 2.17.1 draft-ietf-sieve-mime-loop-02.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, updated by RFC 4748 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. 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 IETF Trust 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 (March 18, 2007) is 6243 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 214, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 215, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 215, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-09) exists of draft-ietf-sieve-body-06 == Outdated reference: A later version (-11) exists of draft-ietf-sieve-editheader-08 Summary: 2 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: September 19, 2007 Apple Computer 6 March 18, 2007 8 SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and 9 Enclosure 10 draft-ietf-sieve-mime-loop-02.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 September 19, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 "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 } 203 } 205 In this example, any message that contains any MIME part with a 206 content-disposition with a filename parameter containing the text 207 "important" is saved to the mailbox "INBOX.important". 209 4.2. Test "address" 211 The "address" test is extended with the addition of a new ":mime" 212 tagged argument, which takes a number of other arguments. 214 Usage: address [:mime] [:anychild] [COMPARATOR] 215 [ADDRESS-PART] [MATCH-TYPE] 216 218 When the ":mime" tagged argument is present in the "address" test, it 219 will parse the MIME header lines as if they were standard address 220 header lines in a message so that tests can be performed on specific 221 elements. 223 The behavior of the ":anychild" tagged argument and the interaction 224 with the "for_every_part" iterator is the same as for the extended 225 "header" test Section 4.1. 227 Example: 229 require ["mime", "fileinto"]; 231 if address :mime :is :all "content-from" "tim@example.com" 232 { 233 fileinto "INBOX.part-from-tim"; 234 } 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.) If the MIME structure is 281 altered, the change takes effect immediately: the "for_every_part" 282 iterator that is executing does not go into the no-longer existing 283 body parts, and subsequent "for_every_part" iterators would use the 284 new message structure. 286 When used outside the context of a "for_every_part" loop, the MIME 287 part to be replaced is the entire message. 289 If the :mime parameter is not specified, the replacement string is a 290 text/plain part. 292 If the :mime parameter is specified, then the replacement string is, 293 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 294 both MIME headers and content. If the optional :mime parameter is 295 not supplied, the reason string is considered to be a UTF-8 string. 297 If the entire message is being replaced, a ":subject" parameter 298 specifies a subject line to attach to the message that is generated. 299 UTF-8 characters can be used in the string argument; implementations 300 MUST convert the string to [RFC2047] encoded words if and only if 301 non-ASCII characters are present. Implementations MUST preserve the 302 previous Subject header as an Original-Subject header. 304 If the entire message is being replaced, a ":from" parameter may be 305 used to specify an alternate address to use in the From field of the 306 message that is generated. The string must specify a valid [RFC2822] 307 mailbox-list. Implementations SHOULD check the syntax and generate 308 an error when a syntactically invalid ":from" parameter is specified. 309 Implementations MAY also impose restrictions on what addresses can be 310 specified in a ":from" parameter; it is suggested that values that 311 fail such a validity check simply be ignored rather than causing the 312 replace action to fail. Implementations MUST preserve the previous 313 From header as an Original-From header. 315 6. Action Enclose 317 Usage: enclose <:subject string> <:headers string-list> string 319 A new SIEVE action command is defined to allow an entire message to 320 be enclosed as an attachment to a new message. NB: The following 321 statement may be controversial: This enclose action takes precedence 322 over all other message modifications, such as "replace". If multiple 323 "enclose" actions are executed by a script, only the text specified 324 on the last one is used when creating the enclosed message. This 325 action does not affect messages that are forwarded via a "redirect" 326 action. 328 Specifically, the original message becomes a multipart/mixed message 329 with two parts: a text/plain portion with the string argument as its 330 body, and a message/rfc822 portion with the original message 331 enclosed. The Content-Type: header field becomes multipart/mixed. 332 The Subject: header is specified by the :subject argument. Any 333 headers specified by :headers are copied from the old message into 334 the new message. NB: The following statement may be controversial: 335 If not specified by :headers, Date: and From: headers should be 336 synthesized to reflect the current date and the user running the 337 SIEVE action. 339 7. SIEVE Capability Strings 341 A SIEVE implementation that defines the "for_every_part" and "break" 342 actions will advertise the capability string "for_every_part". 344 A SIEVE implementation that defines the ":mime" tagged arguments to 345 the "header", "address" and "exists" commands will advertise the 346 capability string "mime". 348 A SIEVE implementation that defines the "replace" action will 349 advertise the capability string "replace". 351 A SIEVE implementation that defines the "enclose" action will 352 advertise the capability string "enclose". 354 8. Examples 356 8.1. Example 1 358 A SIEVE script to replace all the Windows executable attachments in a 359 message would be: 361 require [ "for_every_part", "mime", "replace" ]; 362 for_every_part 363 { 364 if ( anyof ( 365 header :mime :contenttype :is "Content-Type" "application/exe", 366 header :mime :param "filename" 367 ["Content-Type", "Content-Disposition"] :matches "*.com" ) 368 { 369 replace "Executable attachment removed by user filter"; 370 } 371 } 372 8.2. Example 2 374 A SIEVE script to warn the user about executable attachment types 375 would be: 377 require [ "for_every_part", "mime", "enclose" ]; 379 for_every_part 380 { 381 if header :mime :param "filename" 382 ["Content-Type", "Content-Disposition"] :matches 383 ["*.com", "*.exe", "*.vbs", "*.scr", 384 "*.pif", "*.hta", "*.bat", "*.zip" ] 385 { 386 # these attachment types are executable 387 enclose :subject "Warning" " 388 WARNING! The enclosed message contains executable attachments. 389 These attachments types may contain a computer virus program 390 that can infect your computer and potentently damage your data 392 Before clicking on these message attachments, you should verify 393 with the sender that this message was sent by them and not a 394 computer virus. 395 "; 396 break; 397 } 398 } 400 9. Acknowledgements 402 Comments from members of the MTA Filters Working Group, in particular 403 Ned Freed, Nigel Swinson and Mark Mallett, are gratefully 404 acknowledged. 406 10. Security Considerations 408 To be provided 410 11. IANA Considerations 412 The Original-Subject: and Original-From: headers are to be registered 413 in the Permanent Message Header Fields table. 415 12. Change History (to be removed prior to publication as an RFC) 417 12.1. draft-ietf-sieve-mime-02 419 minor syntax glitches in examples 421 Add clarification on "replace" affecting subsequent for_every_part 422 loops? 424 Add IANA considerations for Original-Subject: and Original-From:. 426 Add note on "enclose" creating From: and Date: headers. 428 12.2. draft-ietf-sieve-mime-01 430 what happens when nested for_every_loop's 432 a "mime" shorthand for testing the type/subtype, without requiring 434 interactions with variables 435 notifications 436 notifications to calendar service 437 address tests, exists tests 438 mimeheader, mimeparameter tests 440 12.3. draft-ietf-sieve-mime-00 442 Changed title and text to emphasize MIME Tests. 444 Changed for.every.part to for_every_part. 446 Added :anychild to mime test. Default is to use the current context 447 or outer envelope; specifying :anychild will look at all children. 449 Added clarifications to replacing parts affecting the structure. 451 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 453 Various other minor nit fixes. 455 12.4. draft-hansen-sieve-loop-01 457 Merged with draft-daboo-sieve-mime-00.txt. 459 12.5. draft-hansen-sieve-loop-02 460 Update to 3028bis reference. 462 Added 2119 conventions section. 464 Terminology/title tweaks. 466 Added informative references to body and editheader extensions. 468 Added description of nested loops. 470 Replaced mime test by extensions to header, address and exists 471 tests. 473 13. References 475 13.1. Normative References 477 [I-D.ietf-sieve-3028bis] 478 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 479 Language", draft-ietf-sieve-3028bis-12 (work in progress), 480 February 2007. 482 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 483 Extensions (MIME) Part One: Format of Internet Message 484 Bodies", RFC 2045, November 1996. 486 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 487 Part Three: Message Header Extensions for Non-ASCII Text", 488 RFC 2047, November 1996. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 494 April 2001. 496 13.2. Informative References 498 [I-D.ietf-sieve-body] 499 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 500 Extension", draft-ietf-sieve-body-06 (work in progress), 501 February 2007. 503 [I-D.ietf-sieve-editheader] 504 Guenther, P. and J. Degener, "Sieve Email Filtering: 505 Editheader Extension", draft-ietf-sieve-editheader-08 506 (work in progress), March 2007. 508 Authors' Addresses 510 Tony Hansen 511 AT&T Laboratories 512 200 Laurel Ave. 513 Middletown, NJ 07748 514 USA 516 Email: tony+sieveloop@maillennium.att.com 518 Cyrus Daboo 519 Apple Computer, Inc. 520 1 Infinite Loop 521 Cupertino, CA 95014 522 USA 524 Email: cyrus@daboo.name 525 URI: http://www.apple.com/ 527 Full Copyright Statement 529 Copyright (C) The IETF Trust (2007). 531 This document is subject to the rights, licenses and restrictions 532 contained in BCP 78, and except as set forth therein, the authors 533 retain all their rights. 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 538 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 539 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 540 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 Intellectual Property 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org. 567 Acknowledgment 569 Funding for the RFC Editor function is provided by the IETF 570 Administrative Support Activity (IASA).