idnits 2.17.1 draft-ietf-sieve-mime-loop-08.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 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 910. 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 196 has weird spacing: '... :type parse...' == Line 200 has weird spacing: '...subtype parse...' == Line 204 has weird spacing: '...enttype parse...' == Line 208 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 (November 20, 2008) is 5636 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 165, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 264, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 265, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 265, but not defined == Missing Reference: 'MODIFIER' is mentioned on line 434, but not defined ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 2 errors (**), 0 flaws (~~), 11 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: May 24, 2009 Apple Inc. 6 November 20, 2008 8 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, 9 Replacement and Enclosure 10 draft-ietf-sieve-mime-loop-08 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 May 24, 2009. 37 Abstract 39 This document defines extensions to the Sieve email filtering 40 language to permit analysis and manipulation of the MIME body parts 41 of an email message. 43 Note 45 This document is being discussed on the MTA-FILTERS mailing list, 46 ietf-mta-filters@imc.org. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 52 3. Sieve Loops: Actions "foreverypart" and "break" . . . . . . . 3 53 4. Changes to Sieve Tests . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Test "header" . . . . . . . . . . . . . . . . . . . . . . 4 55 4.2. Test "address" . . . . . . . . . . . . . . . . . . . . . 6 56 4.3. Test "exists" . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Action "replace" . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Action "enclose" . . . . . . . . . . . . . . . . . . . . . . . 9 59 7. Action "extracttext" . . . . . . . . . . . . . . . . . . . . . 10 60 8. Sieve Capability Strings . . . . . . . . . . . . . . . . . . . 10 61 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 11 63 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 11 64 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 12 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 12.1. foreverypart capability . . . . . . . . . . . . . . . . . 14 69 12.2. mime capability . . . . . . . . . . . . . . . . . . . . . 15 70 12.3. replace capability . . . . . . . . . . . . . . . . . . . 15 71 12.4. enclose capability . . . . . . . . . . . . . . . . . . . 15 72 12.5. extracttext capability . . . . . . . . . . . . . . . . . 15 73 13. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 74 13.1. draft-ietf-sieve-mime-08 . . . . . . . . . . . . . . . . 16 75 13.2. draft-ietf-sieve-mime-07 . . . . . . . . . . . . . . . . 16 76 13.3. draft-ietf-sieve-mime-06 . . . . . . . . . . . . . . . . 16 77 13.4. draft-ietf-sieve-mime-05 . . . . . . . . . . . . . . . . 16 78 13.5. draft-ietf-sieve-mime-04 . . . . . . . . . . . . . . . . 17 79 13.6. draft-ietf-sieve-mime-03 . . . . . . . . . . . . . . . . 17 80 13.7. draft-ietf-sieve-mime-02 . . . . . . . . . . . . . . . . 17 81 13.8. draft-ietf-sieve-mime-01 . . . . . . . . . . . . . . . . 17 82 13.9. draft-ietf-sieve-mime-00 . . . . . . . . . . . . . . . . 18 83 13.10. draft-sieve-mime-loop-04 . . . . . . . . . . . . . . . . 18 84 13.11. draft-hansen-sieve-loop-03 . . . . . . . . . . . . . . . 18 85 13.12. draft-hansen-sieve-loop-02 . . . . . . . . . . . . . . . 18 86 13.13. draft-hansen-sieve-loop-01 . . . . . . . . . . . . . . . 19 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 14.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 91 Intellectual Property and Copyright Statements . . . . . . . . . . 21 93 1. Introduction 95 MIME messages ([RFC2045]) are often complex objects, consisting of 96 many parts and sub-parts. This extension defines mechanisms for 97 performing tests on MIME body parts, looping through the MIME body 98 parts, extracting information from a MIME body part, changing the 99 contents of a MIME body part, and enclosing the entire message within 100 a wrapper. 102 2. Conventions Used in This Document 104 Conventions for notations are as in [RFC5228] section 1.1. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Sieve Loops: Actions "foreverypart" and "break" 112 The base Sieve language has no looping mechanism. Given that 113 messages may contain multiple parts, in order to support filters that 114 apply to any and all parts, we introduce a new control command: 115 "foreverypart", which is an iterator that walks though every MIME 116 part of a message, including nested parts, depth first, and applies 117 the commands in the specified block to each of them. The iterator 118 will start with the first MIME part (as its current context) and will 119 execute a command block (Sieve commands enclosed by {...}). Upon 120 completion of this command block, the iterator advances to the next 121 MIME part (as its current context) and executes the same command 122 block again. 124 The iterator can be terminated prematurely by a new Sieve command, 125 "break". 127 Usage: foreverypart [":name" string] block 129 Usage: break [":name" string]; 131 "foreverypart" commands can be nested inside other "foreverypart" 132 commands. When this occurs, the nested "foreverypart" iterates over 133 the MIME parts contained within the MIME part currently being 134 targeted by the nearest enclosing "foreverypart" command. (That is, 135 the inner loop only operates on children of the bodypart currently 136 accessed by the outer loop.) If that MIME part is a terminal MIME 137 part (i.e. does not contain other MIME parts) then the nested 138 "foreverypart" loop is simply ignored. 140 Sieve implementations MAY limit the number of nested loops that occur 141 within one another, however they MUST support at least one nested 142 loop inside another loop. 144 If a name is given to a "break" command, it terminates the closest 145 enclosing loop with the identical matching name. (If a nested 146 "foreverypart" name is the same as a "foreverpart" name in an outer 147 level, the outer level name is hidden.) It is an error if there is 148 no enclosing loop with that name. 150 4. Changes to Sieve Tests 152 This specification extends the base Sieve "header", "address" and 153 "exists" tests to support targeting those tests at a specific MIME 154 part or at all MIME parts in the enclosing scope. 156 4.1. Test "header" 158 The "header" test is extended with the addition of new ":mime" and 159 ":anychild" tagged arguments and their associated options. 161 Usage: header [":mime"] [":anychild"] [MIMEOPTS] 162 [COMPARATOR] [MATCH-TYPE] 163 165 Usage: The definition of [MIMEOPTS] is: 167 Syntax: ":type" / ":subtype" / ":contenttype" / 168 ":param" 170 When the ":mime" tagged argument is present in the "header" test, it 171 will parse the MIME header lines in the message so that tests can be 172 performed on specific elements. 174 When used outside the context of a "foreverypart" iterator, and 175 without an ":anychild" tagged argument, the "header" test will 176 examine only the outer top-level RFC2822 headers of the message. 178 When used inside the context of a "foreverypart" iterator, and 179 without an ":anychild" tagged argument, the "header" test will 180 examine the headers associated with the current MIME part context 181 from the loop. 183 When used outside the context of a "foreverypart" iterator, and with 184 an ":anychild" tagged argument, the "header" test will examine all 185 MIME body parts and return true if any of them satisfies the test. 187 When used inside the context of a "foreverypart" iterator, and with 188 an ":anychild" tagged argument, the "header" test will examine the 189 current MIME part context and all its nested MIME body parts, 190 returning true if any of them satisfies the test. 192 The "header" test with the ":mime" tagged argument can test various 193 aspects of certain structured MIME headers. These options are 194 available: 196 :type parses the header assuming it has the format of a "Content- 197 Type:" MIME header field, and tests the value of the MIME type 198 specified in the header. 200 :subtype parses the header assuming it has the format of a "Content- 201 Type:" MIME header field, and tests the value of the MIME subtype 202 specified in the header. 204 :contenttype parses the header assuming it has the format of a 205 "Content-Type:" MIME header field, and tests the combined value of 206 the MIME type and subtype specified in the header. 208 :param parses the header looking for MIME parameters in the header. 209 The supplied string-list lists the names of any parameters to be 210 tested. If any one named parameter value matches any of the test 211 string values, the test will return true. 213 Example: 215 require ["mime", "fileinto"]; 217 if header :mime :type "Content-Type" "image" 218 { 219 fileinto "INBOX.images"; 220 } 222 In this example, any message that contains a MIME image type part at 223 the top-level is saved to the mailbox "INBOX.images". 225 Example: 227 require ["mime", "fileinto"]; 229 if header :mime :anychild :contenttype 230 "Content-Type" "text/html" 231 { 232 fileinto "INBOX.html"; 233 } 234 In this example, any message that contains any MIME part with a 235 content-type of "text/html" is saved to the mailbox "INBOX.html". 237 Example: 239 require ["mime", "foreverypart", "fileinto"]; 241 foreverypart 242 { 243 if allof ( 244 header :mime :param "filename" :contains 245 "Content-Disposition" "important", 246 header :mime :subtype "Content-Type" "pdf", 247 size :over "100K") 248 { 249 fileinto "INBOX.important"; 250 break; 251 } 252 } 254 In this example, any message that contains a MIME part that has a 255 content-disposition with a filename parameter containing the text 256 "important", has a content-subtype of "pdf" and is bigger than 100 Kb 257 is saved to the mailbox "INBOX.important". 259 4.2. Test "address" 261 The "address" test is extended with the addition of new ":mime" and 262 ":anychild" tagged arguments and their associated options. 264 Usage: address [":mime"] [":anychild"] [COMPARATOR] 265 [ADDRESS-PART] [MATCH-TYPE] 266 268 When the ":mime" tagged argument is present in the "address" test, it 269 will parse the MIME header lines as if they were standard address 270 header lines in a message so that tests can be performed on specific 271 elements. 273 The behavior of the ":anychild" tagged argument and the interaction 274 with the "foreverypart" iterator is the same as for the extended 275 "header" test Section 4.1. 277 That is, 279 the use of "address" with no ":mime" and ":anychild" tagged 280 argument is the test defined in [RFC5228], i.e. it will *only* 281 operate on top level header fields, whether it is inside 282 "foreverypart" or not. 284 the use of "address" with ":mime" and no ":anychild" operates on 285 the current MIME part only (or on the top level header fields, if 286 outside "foreverypart") 288 the use of "address" with ":mime" and ":anychild" operates on the 289 current MIME part and all of its descendants 291 Example: 293 require ["mime", "fileinto"]; 295 if address :mime :is :all "content-from" "tim@example.com" 296 { 297 fileinto "INBOX.part-from-tim"; 298 } 300 In this example, any message that contains a MIME Content-From header 301 at the top-level matching the text "tim@example.com" is saved to the 302 mailbox "INBOX.part-from-time". 304 4.3. Test "exists" 306 The "exists" test is extended with the addition of the new ":mime" 307 and ":anychild" tagged arguments and their associated options. 309 Usage: exists [":mime"] [":anychild"] 311 When the ":mime" tagged argument is present in the "exists" test, the 312 test is extended to check for the existence of MIME headers in MIME 313 parts. 315 The behavior of the ":anychild" tagged argument and the interaction 316 with the "foreverypart" iterator is the same as for the extended 317 "header" test Section 4.1. 319 That is, 321 the use of "exists" with no ":mime" and ":anychild" tagged 322 argument is the test defined in [RFC5228], i.e. it will *only* 323 operate on top level header fields, whether it is inside 324 "foreverypart" or not. 326 the use of "exists" with ":mime" and no ":anychild" operates on 327 the current MIME part only (or on the top level header fields, if 328 outside "foreverypart") 329 the use of "exists" with ":mime" and ":anychild" operates on the 330 current MIME part and all of its descendants 332 Example: 334 require ["mime", "fileinto"]; 336 if exists :mime :anychild "content-md5" 337 { 338 fileinto "INBOX.md5"; 339 } 341 In this example, any message that contains a MIME Content-MD5 header 342 in any MIME part is saved to the mailbox "INBOX.md5". 344 5. Action "replace" 346 Usage: replace [":mime"] [":subject" string] [":from" string] 347 349 The "replace" command is defined to allow a MIME part to be replaced 350 with the text supplied in the command. 352 When used in the context of a "foreverypart" iterator, the MIME part 353 to be replaced is the "current" MIME part. If the current MIME 354 context is a multipart MIME part, the entire multipart MIME part is 355 replaced, which would alter the MIME structure of the message by 356 eliminating all of the children of the multipart part. (Replacing a 357 non-multipart MIME part within a "foreverypart" loop context does not 358 alter the overall message structure.) If the MIME structure is 359 altered, the change takes effect immediately: the "foreverypart" 360 iterator that is executing does not go into the no-longer existing 361 body parts, and subsequent "foreverypart" iterators would use the new 362 message structure. 364 When used outside the context of a "foreverypart" loop, the MIME part 365 to be replaced is the entire message. 367 If the :mime parameter is not specified, the replacement string is a 368 text/plain part in UTF-8. 370 If the :mime parameter is specified, then the replacement string is, 371 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 372 both MIME headers and content. 374 If the entire message is being replaced, the optional ":subject" 375 parameter specifies a subject line to attach to the message that is 376 generated. UTF-8 characters can be used in the string argument; 377 implementations MUST convert the string to [RFC2047] encoded words if 378 and only if non-ASCII characters are present. Implementations MUST 379 preserve the previous Subject header as an Original-Subject header. 380 Implementations MUST preserve all other header fields from the 381 original message with the exception of those relating to the MIME 382 structure that is being replaced. 384 If the entire message is being replaced, the optional ":from" 385 parameter may be used to specify an alternate address to use in the 386 From field of the message that is generated. The string must specify 387 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 388 syntax and generate an error when a syntactically invalid ":from" 389 parameter is specified. Implementations MAY also impose restrictions 390 on what addresses can be specified in a ":from" parameter; it is 391 suggested that values that fail such a validity check simply be 392 ignored rather than causing the replace action to fail. 393 Implementations MUST preserve the previous From header as an 394 Original-From header. 396 If ":mime" is specified and either ":subject" or ":from" is 397 specified, the ":subject:" or ":from" parameter MUST be ignored. 398 This SHOULD be flagged as a compilation error. 400 6. Action "enclose" 402 Usage: enclose <:subject string> <:headers string-list> string 404 A new Sieve action command is defined to allow an entire message to 405 be enclosed as an attachment to a new message. After enclosure, 406 subsequent actions affecting the message header or content, as well 407 as tests operating on the MIME structure or accessing MIME header 408 fields, use the newly created message instead of the original 409 message; this means that any use of a "replace" action or other 410 similar actions should be executed before the "enclose" action. 412 If multiple "enclose" actions are executed by a script, the message 413 is enclosed multiple times. (If a Sieve script desires to choose 414 between different enclosures, or wants to delay the enclosure to the 415 end of the script, it can use variables with appropriate tests. 416 [RFC5229]) 418 This action does not affect messages that are forwarded via a 419 "redirect" action. 421 Specifically, the original message becomes a multipart/mixed message 422 with two parts: a text/plain portion with the string argument as its 423 body, and a message/rfc822 portion with the original message 424 enclosed. The Content-Type: header field becomes multipart/mixed. 425 The optional Subject: header is specified by the :subject argument; 426 if not present the subject will be taken from the enclosed message. 427 Any headers specified by :headers are copied from the old message 428 into the new message. If not specified by :headers, Date: and From: 429 headers should be synthesized to reflect the current date and the 430 user running the Sieve action. 432 7. Action "extracttext" 434 Usage: extracttext [MODIFIER] [":first" number] 436 The "extracttext" action may be used within the context of a 437 "foreverypart" loop. Servers MUST support transcoding of any textual 438 body part into UTF-8 for use with this action. This requires 439 decoding any transfer encoding as well as transcoding from the 440 indicated character set into UTF-8. It stores at most :first 441 characters of the transcoded content of the current MIME body part in 442 the variable identified by varname. If the :first parameter is not 443 present, the whole content of the current MIME body part is stored. 444 In either case the actually stored data MAY be truncated to conform 445 to implementation specific limit on variable length and/or on MIME 446 body part length. If the transfer encoding or character set is 447 unrecognized by the implementation or recognized but invalid, an 448 empty string will result. 450 If "extracttext" is used outside the context of a "foreverypart" 451 loop, the action will set the variable identified by varname to the 452 empty string. This SHOULD be flagged as a compilation error. 454 Modifiers are applied on the extracted text before it is stored in 455 the variable. See [RFC5229] for details. 457 8. Sieve Capability Strings 459 A Sieve implementation that defines the "foreverypart" and "break" 460 actions will advertise the capability string "foreverypart". 462 A Sieve implementation that defines the ":mime" and ":anychild" 463 tagged arguments to the "header", "address" and "exists" commands 464 will advertise the capability string "mime". 466 A Sieve implementation that defines the "replace" action will 467 advertise the capability string "replace". 469 A Sieve implementation that defines the "enclose" action will 470 advertise the capability string "enclose". 472 A Sieve implementation that defines the "extracttext" action will 473 advertise the capability string "extracttext". Note that to be 474 useful, the "extracttext" action also requires the "variables" 475 [RFC5229] and "foreverypart" capabilities. 477 9. Examples 479 9.1. Example 1 481 A Sieve script to replace all the Windows executable attachments in a 482 message would be: 484 require [ "foreverypart", "mime", "replace" ]; 485 foreverypart 486 { 487 if anyof ( 488 header :mime :contenttype :is "Content-Type" "application/exe", 489 header :mime :param "filename" 490 ["Content-Type", "Content-Disposition"] :matches "*.com" ) 491 { 492 replace "Executable attachment removed by user filter"; 493 } 494 } 496 9.2. Example 2 498 A Sieve script to warn the user about executable attachment types 499 would be: 501 require [ "foreverypart", "mime", "enclose" ]; 503 foreverypart 504 { 505 if header :mime :param "filename" 506 ["Content-Type", "Content-Disposition"] :matches 507 ["*.com", "*.exe", "*.vbs", "*.scr", 508 "*.pif", "*.hta", "*.bat", "*.zip" ] 509 { 510 # these attachment types are executable 511 enclose :subject "Warning" :text 512 WARNING! The enclosed message contains executable attachments. 513 These attachments types may contain a computer virus program 514 that can infect your computer and potentially damage your data. 516 Before clicking on these message attachments, you should verify 517 with the sender that this message was sent by them and not a 518 computer virus. 519 . 520 ; 521 break; 522 } 523 } 525 9.3. Example 3 527 A Sieve script to extract subject and text out of messages from the 528 boss: 530 require ["mime", "variables", "extracttext"]; 532 if header :contains "from" "boss@example.org" 533 { 534 # :matches is used to get the value of the Subject header 535 if header :matches "Subject" "*" 536 { 537 set "subject" "${1}"; 538 } 540 # extract the first 100 characters of the first text/* part 541 foreverypart 542 { 543 if header :mime :type :is "Content-Type" "text" 544 { 545 extracttext :first 100 "msgcontent"; 546 break; 547 } 548 } 550 # if it's not a 'for your information' message 551 if not header :contains "subject" "FYI:" 552 { 553 # do something using ${subject} and ${msgcontent} 554 # such as sending a notification using a 555 # notification extension 556 } 557 } 559 10. Acknowledgements 561 Comments from members of the MTA Filters Working Group, in particular 562 Ned Freed, Kjetil Torgrim Homme, Mark Mallett, Alexey Melnikov, Aaron 563 Stone and Nigel Swinson are gratefully acknowledged. 565 11. Security Considerations 567 The "enclose" action creates an entirely new message, as compared to 568 just redirecting or forwarding the existing message. Therefore, any 569 site policies applicable to message submission should be enforced. 571 The looping specification specified here provides easier access to 572 information about the message contents, which may also be achieved 573 through other sieve tests. This is not believed to raise any 574 additional security issues beyond those for the Sieve "envelope" and 575 "body" [I-D.ietf-sieve-body] tests. 577 Any change in message content may interfere with digital signature 578 mechanisms that include that content in the signed material. In 579 particular, using "replace" makes direct changes to the body content 580 and will affect the body hash included in DKIM signatures, or the 581 message signature used for S/MIME or OpenPGP. 583 It is not possible to examine the MIME structure of decrypted content 584 in a multipart/encrypted MIME part. 586 When "enclose" is used on a message containing a multipart/signed 587 MIME part, the SIEVE implementation MUST ensure that the original 588 message is copied octet-for-octet to maintain the validity of the 589 digital signature. 591 The system MUST be sized and restricted in such a manner that even 592 malicious use of mime part matching does not deny service to other 593 users of the host system. 595 All of the security considerations given in the base Sieve 596 specification also apply to these extensions. 598 12. IANA Considerations 600 The Original-Subject: and Original-From: headers are to be registered 601 in the Permanent Message Header Fields table. 603 The following templates specify the IANA registrations of the Sieve 604 extensions specified in this document. This information should be 605 added to the list of sieve extensions given on 606 http://www.iana.org/assignments/sieve-extensions. 608 [[ RFC Editor Note: replace RFC XXXX with a reference to this RFC. ]] 610 12.1. foreverypart capability 612 To: iana@iana.org 613 Subject: Registration of new Sieve extension 615 Capability name: foreverypart 616 Description: adds the "foreverypart" and "break" actions for 617 iterating through MIME parts of a message. 619 RFC number: RFC XXXX 620 Contact address: The Sieve discussion list 621 . 623 12.2. mime capability 625 To: iana@iana.org 626 Subject: Registration of new Sieve extension 628 Capability name: mime 629 Description: adds the ":mime" and ":anychild" tagged arguments to the 630 "header", "address" and "exists" tests. 632 RFC number: RFC XXXX 633 Contact address: The Sieve discussion list 634 . 636 12.3. replace capability 638 To: iana@iana.org 639 Subject: Registration of new Sieve extension 641 Capability name: replace 642 Description: adds the "replace" action for replacing a MIME body part 643 of a message. 645 RFC number: RFC XXXX 646 Contact address: The Sieve discussion list 647 . 649 12.4. enclose capability 651 To: iana@iana.org 652 Subject: Registration of new Sieve extension 653 Capability name: enclose 654 Description: adds the "enclose" action for enclosing a message with a 655 wrapper. 657 RFC number: RFC XXXX 658 Contact address: The Sieve discussion list 659 . 661 12.5. extracttext capability 663 To: iana@iana.org 664 Subject: Registration of new Sieve extension 665 Capability name: extracttext 666 Description: adds the "extracttext" action for extracting text from a 667 MIME body part. 669 RFC number: RFC XXXX 670 Contact address: The Sieve discussion list 671 . 673 13. Change History 675 [[ RFC Editor NOTE: This section is to be removed prior to 676 publication as an RFC. ]] 678 13.1. draft-ietf-sieve-mime-08 680 enhance description of enclose and multiple enclose. 682 Minor nits 684 13.2. draft-ietf-sieve-mime-07 686 List :anychild parameter next to :mime, where it was added. 688 Expand description of "address" and "exists". 690 In replace, discuss interaction of :mime with :subject/:from. 692 In enclose, expand discussion o fmultiple enclosures. 694 Mention compilation error if extracttext is used outside of a 695 foreverypart loop. 697 13.3. draft-ietf-sieve-mime-06 699 Added note to foreverypart about nested identical names hiding outer 700 names. 702 Added notes to Security Considerations section about it not working 703 on multipart/signed sections, and how replace/enclose may affect 704 signatures. 706 13.4. draft-ietf-sieve-mime-05 708 Changed for_every_part to foreverypart, and extract_text to 709 extracttext. 711 Add option :name parameter to foreverypart and break. break :name 712 "string" will break out of closest enclosing foreverypart loop 713 with that name. 715 Clarify nesting a bit more. 717 Minor consistency nit picking. 719 13.5. draft-ietf-sieve-mime-04 721 loops are depth first 723 :anychild clarifications 725 update examples 727 grammar nits 729 transcoding for extract_text 731 13.6. draft-ietf-sieve-mime-03 733 add extraction 735 add security considerations 737 fill in iana considerations 739 13.7. draft-ietf-sieve-mime-02 741 minor syntax glitches in examples 743 Add clarification on "replace" affecting subsequent for_every_part 744 loops? 746 Add IANA considerations for Original-Subject: and Original-From:. 748 Add note on "enclose" creating From: and Date: headers. 750 13.8. draft-ietf-sieve-mime-01 752 what happens when nested for_every_part loop's 754 a "mime" shorthand for testing the type/subtype, without requiring 756 interactions with variables 757 notifications 758 notifications to calendar service 759 address tests, exists tests 760 mimeheader, mimeparameter tests 762 13.9. draft-ietf-sieve-mime-00 764 Changed title and text to emphasize MIME Tests. 766 Changed for.every.part to for_every_part. 768 Added :anychild to mime test. Default is to use the current 769 context or outer envelope; specifying :anychild will look at all 770 children. 772 Added clarifications to replacing parts affecting the structure. 774 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 776 Various other minor nit fixes. 778 13.10. draft-sieve-mime-loop-04 780 update reference for recent published rfcs 782 extract-text now required to do decode transfer encoding and 783 transcode to UTF-8 785 removed editheader reference since its not actually used 787 several text changes as suggested by Nigel Swinson, including re- 788 writes to abstract and introduction 790 13.11. draft-hansen-sieve-loop-03 792 after enclosure, subsequent actions affect newly created message 794 synthesis of Date/From headers by the enclose action is no longer 795 controversial 797 Filled in Security Considerations 799 Picked up extract_text action from draft-ietf-sieve-notify 801 Expanded the IANA considerations section 803 13.12. draft-hansen-sieve-loop-02 805 Update to 3028bis reference. 807 Added 2119 conventions section. 809 Terminology/title tweaks. 811 Added informative references to body and editheader extensions. 813 Added description of nested loops. 815 Replaced mime test by extensions to header, address and exists 816 tests. 818 13.13. draft-hansen-sieve-loop-01 820 Merged with draft-daboo-sieve-mime-00.txt. 822 14. References 824 14.1. Normative References 826 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 827 Extensions (MIME) Part One: Format of Internet Message 828 Bodies", RFC 2045, November 1996. 830 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 831 Part Three: Message Header Extensions for Non-ASCII Text", 832 RFC 2047, November 1996. 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, March 1997. 837 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 838 April 2001. 840 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 841 Language", RFC 5228, January 2008. 843 14.2. Informative References 845 [I-D.ietf-sieve-body] 846 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 847 Extension", draft-ietf-sieve-body-09 (work in progress), 848 March 2008. 850 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 851 RFC 5229, January 2008. 853 Authors' Addresses 855 Tony Hansen 856 AT&T Laboratories 857 200 Laurel Ave. 858 Middletown, NJ 07748 859 USA 861 Email: tony+sieveloop@maillennium.att.com 863 Cyrus Daboo 864 Apple Inc. 865 1 Infinite Loop 866 Cupertino, CA 95014 867 USA 869 Email: cyrus@daboo.name 870 URI: http://www.apple.com/ 872 Full Copyright Statement 874 Copyright (C) The IETF Trust (2008). 876 This document is subject to the rights, licenses and restrictions 877 contained in BCP 78, and except as set forth therein, the authors 878 retain all their rights. 880 This document and the information contained herein are provided on an 881 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 882 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 883 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 884 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 885 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 886 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 888 Intellectual Property 890 The IETF takes no position regarding the validity or scope of any 891 Intellectual Property Rights or other rights that might be claimed to 892 pertain to the implementation or use of the technology described in 893 this document or the extent to which any license under such rights 894 might or might not be available; nor does it represent that it has 895 made any independent effort to identify any such rights. Information 896 on the procedures with respect to rights in RFC documents can be 897 found in BCP 78 and BCP 79. 899 Copies of IPR disclosures made to the IETF Secretariat and any 900 assurances of licenses to be made available, or the result of an 901 attempt made to obtain a general license or permission for the use of 902 such proprietary rights by implementers or users of this 903 specification can be obtained from the IETF on-line IPR repository at 904 http://www.ietf.org/ipr. 906 The IETF invites any interested party to bring to its attention any 907 copyrights, patents or patent applications, or other proprietary 908 rights that may cover technology that may be required to implement 909 this standard. Please address the information to the IETF at 910 ietf-ipr@ietf.org.