idnits 2.17.1 draft-ietf-sieve-mime-loop-07.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 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 898. 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 195 has weird spacing: '... :type parse...' == Line 199 has weird spacing: '...subtype parse...' == Line 203 has weird spacing: '...enttype parse...' == Line 207 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 3, 2008) is 5652 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 164, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 263, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 264, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 264, but not defined == Missing Reference: 'MODIFIER' is mentioned on line 430, 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 7, 2009 Apple Inc. 6 November 3, 2008 8 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, 9 Replacement and Enclosure 10 draft-ietf-sieve-mime-loop-07 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 7, 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-07 . . . . . . . . . . . . . . . . 16 75 13.2. draft-ietf-sieve-mime-06 . . . . . . . . . . . . . . . . 16 76 13.3. draft-ietf-sieve-mime-05 . . . . . . . . . . . . . . . . 16 77 13.4. draft-ietf-sieve-mime-04 . . . . . . . . . . . . . . . . 16 78 13.5. draft-ietf-sieve-mime-03 . . . . . . . . . . . . . . . . 17 79 13.6. draft-ietf-sieve-mime-02 . . . . . . . . . . . . . . . . 17 80 13.7. draft-ietf-sieve-mime-01 . . . . . . . . . . . . . . . . 17 81 13.8. draft-ietf-sieve-mime-00 . . . . . . . . . . . . . . . . 17 82 13.9. draft-sieve-mime-loop-04 . . . . . . . . . . . . . . . . 18 83 13.10. draft-hansen-sieve-loop-03 . . . . . . . . . . . . . . . 18 84 13.11. draft-hansen-sieve-loop-02 . . . . . . . . . . . . . . . 18 85 13.12. draft-hansen-sieve-loop-01 . . . . . . . . . . . . . . . 19 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 14.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Intellectual Property and Copyright Statements . . . . . . . . . . 21 92 1. Introduction 94 MIME messages ([RFC2045]) are often complex objects, consisting of 95 many parts and sub-parts. This extension defines mechanisms for 96 performing tests on MIME body parts, looping through the MIME body 97 parts, extracting information from a MIME body part, changing the 98 contents of a MIME body part, and enclosing the entire message within 99 a wrapper. 101 2. Conventions Used in This Document 103 Conventions for notations are as in [RFC5228] section 1.1. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Sieve Loops: Actions "foreverypart" and "break" 111 The base Sieve language has no looping mechanism. Given that 112 messages may contain multiple parts, in order to support filters that 113 apply to any and all parts, we introduce a new control command: 114 "foreverypart", which is an iterator that walks though every MIME 115 part of a message, including nested parts, depth first, and applies 116 the commands in the specified block to each of them. The iterator 117 will start with the first MIME part (as its current context) and will 118 execute a command block (Sieve commands enclosed by {...}). Upon 119 completion of this command block, the iterator advances to the next 120 MIME part (as its current context) and executes the same command 121 block again. 123 The iterator can be terminated prematurely by a new Sieve command, 124 "break". 126 Usage: foreverypart [":name" string] block 128 Usage: break [":name" string]; 130 "foreverypart" commands can be nested inside other "foreverypart" 131 commands. When this occurs, the nested "foreverypart" iterates over 132 the MIME parts contained within the MIME part currently being 133 targeted by the nearest enclosing "foreverypart" command. (That is, 134 the inner loop only operates on children of the bodypart currently 135 accessed by the outer loop.) If that MIME part is a terminal MIME 136 part (i.e. does not contain other MIME parts) then the nested 137 "foreverypart" loop is simply ignored. 139 Sieve implementations MAY limit the number of nested loops that occur 140 within one another, however they MUST support at least one nested 141 loop inside another loop. 143 If a name is given to a "break" command, it terminates the closest 144 enclosing loop with the identical matching name. (If a nested 145 "foreverypart" name is the same as a "foreverpart" name in an outer 146 level, the outer level name is hidden.) It is an error if there is 147 no enclosing loop with that name. 149 4. Changes to Sieve Tests 151 This specification extends the base Sieve "header", "address" and 152 "exists" tests to support targeting those tests at a specific MIME 153 part or at all MIME parts in the enclosing scope. 155 4.1. Test "header" 157 The "header" test is extended with the addition of new ":mime" and 158 ":anychild" tagged arguments and its associated options. 160 Usage: header [":mime"] [":anychild"] [MIMEOPTS] 161 [COMPARATOR] [MATCH-TYPE] 162 164 Usage: The definition of [MIMEOPTS] is: 166 Syntax: ":type" / ":subtype" / ":contenttype" / 167 ":param" 169 When the ":mime" tagged argument is present in the "header" test, it 170 will parse the MIME header lines in the message so that tests can be 171 performed on specific elements. 173 When used outside the context of a "foreverypart" iterator, and 174 without an ":anychild" tagged argument, the "header" test will 175 examine only the outer top-level RFC2822 headers of the message. 177 When used inside the context of a "foreverypart" iterator, and 178 without an ":anychild" tagged argument, the "header" test will 179 examine the headers associated with the current MIME part context 180 from the loop. 182 When used outside the context of a "foreverypart" iterator, and with 183 an ":anychild" tagged argument, the "header" test will examine all 184 MIME body parts and return true if any of them satisfies the test. 186 When used inside the context of a "foreverypart" iterator, and with 187 an ":anychild" tagged argument, the "header" test will examine the 188 current MIME part context and all its nested MIME body parts, 189 returning true if any of them satisfies the test. 191 The "header" test with the ":mime" tagged argument can test various 192 aspects of certain structured MIME headers. These options are 193 available: 195 :type parses the header assuming it has the format of a "Content- 196 Type:" MIME header field, and tests the value of the MIME type 197 specified in the header. 199 :subtype parses the header assuming it has the format of a "Content- 200 Type:" MIME header field, and tests the value of the MIME subtype 201 specified in the header. 203 :contenttype parses the header assuming it has the format of a 204 "Content-Type:" MIME header field, and tests the combined value of 205 the MIME type and subtype specified in the header. 207 :param parses the header looking for MIME parameters in the header. 208 The supplied string-list lists the names of any parameters to be 209 tested. If any one named parameter value matches any of the test 210 string values, the test will return true. 212 Example: 214 require ["mime", "fileinto"]; 216 if header :mime :type "Content-Type" "image" 217 { 218 fileinto "INBOX.images"; 219 } 221 In this example, any message that contains a MIME image type part at 222 the top-level is saved to the mailbox "INBOX.images". 224 Example: 226 require ["mime", "fileinto"]; 228 if header :mime :anychild :contenttype 229 "Content-Type" "text/html" 230 { 231 fileinto "INBOX.html"; 232 } 233 In this example, any message that contains any MIME part with a 234 content-type of "text/html" is saved to the mailbox "INBOX.html". 236 Example: 238 require ["mime", "foreverypart", "fileinto"]; 240 foreverypart 241 { 242 if allof ( 243 header :mime :param "filename" :contains 244 "Content-Disposition" "important", 245 header :mime :subtype "Content-Type" "pdf", 246 size :over "100K") 247 { 248 fileinto "INBOX.important"; 249 break; 250 } 251 } 253 In this example, any message that contains a MIME part that has a 254 content-disposition with a filename parameter containing the text 255 "important", has a content-subtype of "pdf" and is bigger than 100 Kb 256 is saved to the mailbox "INBOX.important". 258 4.2. Test "address" 260 The "address" test is extended with the addition of new ":mime" and 261 ":anychild" tagged arguments and their associated options. 263 Usage: address [":mime"] [":anychild"] [COMPARATOR] 264 [ADDRESS-PART] [MATCH-TYPE] 265 267 When the ":mime" tagged argument is present in the "address" test, it 268 will parse the MIME header lines as if they were standard address 269 header lines in a message so that tests can be performed on specific 270 elements. 272 The behavior of the ":anychild" tagged argument and the interaction 273 with the "foreverypart" iterator is the same as for the extended 274 "header" test Section 4.1. 276 That is, 278 the use of "address" with no ":mime" and ":anychild" tagged 279 argument is the test defined in [RFC5228], i.e. it will *only* 280 operate on top level header fields, whether it is inside 281 "foreverypart" or not. 283 the use of "address" with ":mime" and no ":anychild" operates on 284 the current MIME part only (or on the top level header fields, if 285 outside "foreverypart") 287 the use of "address" with ":mime" and ":anychild" operates on the 288 current MIME part and all of its descendants 290 Example: 292 require ["mime", "fileinto"]; 294 if address :mime :is :all "content-from" "tim@example.com" 295 { 296 fileinto "INBOX.part-from-tim"; 297 } 299 In this example, any message that contains a MIME Content-From header 300 at the top-level matching the text "tim@example.com" is saved to the 301 mailbox "INBOX.part-from-time". 303 4.3. Test "exists" 305 The "exists" test is extended with the addition of the new ":mime" 306 and ":anychild" tagged arguments, which takes one other argument. 308 Usage: exists [":mime"] [":anychild"] 310 When the ":mime" tagged argument is present in the "exists" test, the 311 test is extended to check for the existence of MIME headers in MIME 312 parts. 314 The behavior of the ":anychild" tagged argument and the interaction 315 with the "foreverypart" iterator is the same as for the extended 316 "header" test Section 4.1. 318 That is, 320 the use of "exists" with no ":mime" and ":anychild" tagged 321 argument is the test defined in [RFC5228], i.e. it will *only* 322 operate on top level header fields, whether it is inside 323 "foreverypart" or not. 325 the use of "exists" with ":mime" and no ":anychild" operates on 326 the current MIME part only (or on the top level header fields, if 327 outside "foreverypart") 328 the use of "exists" with ":mime" and ":anychild" operates on the 329 current MIME part and all of its descendants 331 Example: 333 require ["mime", "fileinto"]; 335 if exists :mime :anychild "content-md5" 336 { 337 fileinto "INBOX.md5"; 338 } 340 In this example, any message that contains a MIME Content-MD5 header 341 in any MIME part is saved to the mailbox "INBOX.md5". 343 5. Action "replace" 345 Usage: replace [":mime"] [":subject" string] [":from" string] 346 348 The "replace" command is defined to allow a MIME part to be replaced 349 with the text supplied in the command. 351 When used in the context of a "foreverypart" iterator, the MIME part 352 to be replaced is the "current" MIME part. If the current MIME 353 context is a multipart MIME part, the entire multipart MIME part is 354 replaced, which would alter the MIME structure of the message by 355 eliminating all of the children of the multipart part. (Replacing a 356 non-multipart MIME part within a "foreverypart" loop context does not 357 alter the overall message structure.) If the MIME structure is 358 altered, the change takes effect immediately: the "foreverypart" 359 iterator that is executing does not go into the no-longer existing 360 body parts, and subsequent "foreverypart" iterators would use the new 361 message structure. 363 When used outside the context of a "foreverypart" loop, the MIME part 364 to be replaced is the entire message. 366 If the :mime parameter is not specified, the replacement string is a 367 text/plain part in UTF-8. 369 If the :mime parameter is specified, then the replacement string is, 370 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 371 both MIME headers and content. 373 If the entire message is being replaced, the optional ":subject" 374 parameter specifies a subject line to attach to the message that is 375 generated. UTF-8 characters can be used in the string argument; 376 implementations MUST convert the string to [RFC2047] encoded words if 377 and only if non-ASCII characters are present. Implementations MUST 378 preserve the previous Subject header as an Original-Subject header. 379 Implementations MUST preserve all other header fields from the 380 original message with the exception of those relating to the MIME 381 structure that is being replaced. 383 If the entire message is being replaced, the optional ":from" 384 parameter may be used to specify an alternate address to use in the 385 From field of the message that is generated. The string must specify 386 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 387 syntax and generate an error when a syntactically invalid ":from" 388 parameter is specified. Implementations MAY also impose restrictions 389 on what addresses can be specified in a ":from" parameter; it is 390 suggested that values that fail such a validity check simply be 391 ignored rather than causing the replace action to fail. 392 Implementations MUST preserve the previous From header as an 393 Original-From header. 395 If ":mime" is specified and either ":subject" or ":from" is 396 specified, the ":subject:" or ":from" parameter MUST be ignored. 397 This SHOULD be flagged as a compilation error. 399 6. Action "enclose" 401 Usage: enclose <:subject string> <:headers string-list> string 403 A new Sieve action command is defined to allow an entire message to 404 be enclosed as an attachment to a new message. After enclosure, 405 subsequent actions affecting the message header or content use the 406 newly created message instead of the original message; this means 407 that any use of a "replace" action or other similar actions should be 408 executed before the "enclose" action. 410 If multiple "enclose" actions are executed by a script, only the text 411 specified on the last one is used when creating the enclosed message; 412 the message in this case would not be enclosed multiple times. 414 This action does not affect messages that are forwarded via a 415 "redirect" action. 417 Specifically, the original message becomes a multipart/mixed message 418 with two parts: a text/plain portion with the string argument as its 419 body, and a message/rfc822 portion with the original message 420 enclosed. The Content-Type: header field becomes multipart/mixed. 421 The optional Subject: header is specified by the :subject argument; 422 if not present the subject will be taken from the enclosed message. 423 Any headers specified by :headers are copied from the old message 424 into the new message. If not specified by :headers, Date: and From: 425 headers should be synthesized to reflect the current date and the 426 user running the Sieve action. 428 7. Action "extracttext" 430 Usage: extracttext [MODIFIER] [":first" number] 432 The "extracttext" action may be used within the context of a 433 "foreverypart" loop. Servers MUST support transcoding of any textual 434 body part into UTF-8 for use with this action. This requires 435 decoding any transfer encoding as well as transcoding from the 436 indicated character set into UTF-8. It stores at most :first 437 characters of the transcoded content of the current MIME body part in 438 the variable identified by varname. If the :first parameter is not 439 present, the whole content of the current MIME body part is stored. 440 In either case the actually stored data MAY be truncated to conform 441 to implementation specific limit on variable length and/or on MIME 442 body part length. If the transfer encoding or character set is 443 unrecognized by the implementation or recognized but invalid, an 444 empty string will result. 446 If "extracttext" is used outside the context of a "foreverypart" 447 loop, the action will set the variable identified by varname to the 448 empty string. This SHOULD be flagged as a compilation error. 450 Modifiers are applied on the extracted text before it is stored in 451 the variable. See [RFC5229] for details. 453 8. Sieve Capability Strings 455 A Sieve implementation that defines the "foreverypart" and "break" 456 actions will advertise the capability string "foreverypart". 458 A Sieve implementation that defines the ":mime" and ":anychild" 459 tagged arguments to the "header", "address" and "exists" commands 460 will advertise the capability string "mime". 462 A Sieve implementation that defines the "replace" action will 463 advertise the capability string "replace". 465 A Sieve implementation that defines the "enclose" action will 466 advertise the capability string "enclose". 468 A Sieve implementation that defines the "extracttext" action will 469 advertise the capability string "extracttext". Note that to be 470 useful, the "extracttext" action also requires the "variables" 471 [RFC5229] and "foreverypart" capabilities. 473 9. Examples 475 9.1. Example 1 477 A Sieve script to replace all the Windows executable attachments in a 478 message would be: 480 require [ "foreverypart", "mime", "replace" ]; 481 foreverypart 482 { 483 if anyof ( 484 header :mime :contenttype :is "Content-Type" "application/exe", 485 header :mime :param "filename" 486 ["Content-Type", "Content-Disposition"] :matches "*.com" ) 487 { 488 replace "Executable attachment removed by user filter"; 489 } 490 } 492 9.2. Example 2 494 A Sieve script to warn the user about executable attachment types 495 would be: 497 require [ "foreverypart", "mime", "enclose" ]; 499 foreverypart 500 { 501 if header :mime :param "filename" 502 ["Content-Type", "Content-Disposition"] :matches 503 ["*.com", "*.exe", "*.vbs", "*.scr", 504 "*.pif", "*.hta", "*.bat", "*.zip" ] 505 { 506 # these attachment types are executable 507 enclose :subject "Warning" :text 508 WARNING! The enclosed message contains executable attachments. 509 These attachments types may contain a computer virus program 510 that can infect your computer and potentially damage your data. 512 Before clicking on these message attachments, you should verify 513 with the sender that this message was sent by them and not a 514 computer virus. 515 . 516 ; 517 break; 518 } 519 } 521 9.3. Example 3 523 A Sieve script to extract subject and text out of messages from the 524 boss: 526 require ["mime", "variables", "extracttext"]; 528 if header :contains "from" "boss@example.org" 529 { 530 # :matches is used to get the value of the Subject header 531 if header :matches "Subject" "*" 532 { 533 set "subject" "${1}"; 534 } 536 # extract the first 100 characters of the first text/* part 537 foreverypart 538 { 539 if header :mime :type :is "Content-Type" "text" 540 { 541 extracttext :first 100 "msgcontent"; 542 break; 543 } 544 } 546 # if it's not a 'for your information' message 547 if not header :contains "subject" "FYI:" 548 { 549 # do something using ${subject} and ${msgcontent} 550 # such as sending a notification using a 551 # notification extension 552 } 553 } 555 10. Acknowledgements 557 Comments from members of the MTA Filters Working Group, in particular 558 Ned Freed, Kjetil Torgrim Homme, Mark Mallett, Alexey Melnikov, Aaron 559 Stone and Nigel Swinson are gratefully acknowledged. 561 11. Security Considerations 563 The "enclose" action creates an entirely new message, as compared to 564 just redirecting or forwarding the existing message. Therefore, any 565 site policies applicable to message submission should be enforced. 567 The looping specification specified here provides easier access to 568 information about the message contents, which may also be achieved 569 through other sieve tests. This is not believed to raise any 570 additional security issues beyond those for the Sieve "envelope" and 571 "body" [I-D.ietf-sieve-body] tests. 573 Any change in message content may interfere with digital signature 574 mechanisms that include that content in the signed material. In 575 particular, using "replace" makes direct changes to the body content 576 and will affect the body hash included in DKIM signatures, or the 577 message signature used for S/MIME or OpenPGP. 579 It is not possible to examine the MIME structure of decrypted content 580 in a multipart/encrypted MIME part. 582 When "enclose" is used on a message containing a multipart/signed 583 MIME part, the SIEVE implementation MUST ensure that the original 584 message is copied octet-for-octet to maintain the validity of the 585 digital signature. 587 The system MUST be sized and restricted in such a manner that even 588 malicious use of mime part matching does not deny service to other 589 users of the host system. 591 All of the security considerations given in the base Sieve 592 specification also apply to these extensions. 594 12. IANA Considerations 596 The Original-Subject: and Original-From: headers are to be registered 597 in the Permanent Message Header Fields table. 599 The following templates specify the IANA registrations of the Sieve 600 extensions specified in this document. This information should be 601 added to the list of sieve extensions given on 602 http://www.iana.org/assignments/sieve-extensions. 604 [[ RFC Editor Note: replace RFC XXXX with a reference to this RFC. ]] 606 12.1. foreverypart capability 608 To: iana@iana.org 609 Subject: Registration of new Sieve extension 611 Capability name: foreverypart 612 Description: adds the "foreverypart" and "break" actions for 613 iterating through MIME parts of a message. 615 RFC number: RFC XXXX 616 Contact address: The Sieve discussion list 617 . 619 12.2. mime capability 621 To: iana@iana.org 622 Subject: Registration of new Sieve extension 624 Capability name: mime 625 Description: adds the ":mime" and ":anychild" tagged arguments to the 626 "header", "address" and "exists" tests. 628 RFC number: RFC XXXX 629 Contact address: The Sieve discussion list 630 . 632 12.3. replace capability 634 To: iana@iana.org 635 Subject: Registration of new Sieve extension 637 Capability name: replace 638 Description: adds the "replace" action for replacing a MIME body part 639 of a message. 641 RFC number: RFC XXXX 642 Contact address: The Sieve discussion list 643 . 645 12.4. enclose capability 647 To: iana@iana.org 648 Subject: Registration of new Sieve extension 649 Capability name: enclose 650 Description: adds the "enclose" action for enclosing a message with a 651 wrapper. 653 RFC number: RFC XXXX 654 Contact address: The Sieve discussion list 655 . 657 12.5. extracttext capability 659 To: iana@iana.org 660 Subject: Registration of new Sieve extension 661 Capability name: extracttext 662 Description: adds the "extracttext" action for extracting text from a 663 MIME body part. 665 RFC number: RFC XXXX 666 Contact address: The Sieve discussion list 667 . 669 13. Change History 671 [[ RFC Editor NOTE: This section is to be removed prior to 672 publication as an RFC. ]] 674 13.1. draft-ietf-sieve-mime-07 676 List :anychild parameter next to :mime, where it was added. 678 Expand description of "address" and "exists". 680 In replace, discuss interaction of :mime with :subject/:from. 682 In enclose, expand discussion o fmultiple enclosures. 684 Mention compilation error if extracttext is used outside of a 685 foreverypart loop. 687 13.2. draft-ietf-sieve-mime-06 689 Added note to foreverypart about nested identical names hiding outer 690 names. 692 Added notes to Security Considerations section about it not working 693 on multipart/signed sections, and how replace/enclose may affect 694 signatures. 696 13.3. draft-ietf-sieve-mime-05 698 Changed for_every_part to foreverypart, and extract_text to 699 extracttext. 701 Add option :name parameter to foreverypart and break. break :name 702 "string" will break out of closest enclosing foreverypart loop 703 with that name. 705 Clarify nesting a bit more. 707 Minor consistency nit picking. 709 13.4. draft-ietf-sieve-mime-04 711 loops are depth first 712 :anychild clarifications 714 update examples 716 grammar nits 718 transcoding for extract_text 720 13.5. draft-ietf-sieve-mime-03 722 add extraction 724 add security considerations 726 fill in iana considerations 728 13.6. draft-ietf-sieve-mime-02 730 minor syntax glitches in examples 732 Add clarification on "replace" affecting subsequent for_every_part 733 loops? 735 Add IANA considerations for Original-Subject: and Original-From:. 737 Add note on "enclose" creating From: and Date: headers. 739 13.7. draft-ietf-sieve-mime-01 741 what happens when nested for_every_part loop's 743 a "mime" shorthand for testing the type/subtype, without requiring 745 interactions with variables 746 notifications 747 notifications to calendar service 748 address tests, exists tests 749 mimeheader, mimeparameter tests 751 13.8. draft-ietf-sieve-mime-00 753 Changed title and text to emphasize MIME Tests. 755 Changed for.every.part to for_every_part. 757 Added :anychild to mime test. Default is to use the current 758 context or outer envelope; specifying :anychild will look at all 759 children. 761 Added clarifications to replacing parts affecting the structure. 763 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 765 Various other minor nit fixes. 767 13.9. draft-sieve-mime-loop-04 769 update reference for recent published rfcs 771 extract-text now required to do decode transfer encoding and 772 transcode to UTF-8 774 removed editheader reference since its not actually used 776 several text changes as suggested by Nigel Swinson, including re- 777 writes to abstract and introduction 779 13.10. draft-hansen-sieve-loop-03 781 after enclosure, subsequent actions affect newly created message 783 synthesis of Date/From headers by the enclose action is no longer 784 controversial 786 Filled in Security Considerations 788 Picked up extract_text action from draft-ietf-sieve-notify 790 Expanded the IANA considerations section 792 13.11. draft-hansen-sieve-loop-02 794 Update to 3028bis reference. 796 Added 2119 conventions section. 798 Terminology/title tweaks. 800 Added informative references to body and editheader extensions. 802 Added description of nested loops. 804 Replaced mime test by extensions to header, address and exists 805 tests. 807 13.12. draft-hansen-sieve-loop-01 809 Merged with draft-daboo-sieve-mime-00.txt. 811 14. References 813 14.1. Normative References 815 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 816 Extensions (MIME) Part One: Format of Internet Message 817 Bodies", RFC 2045, November 1996. 819 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 820 Part Three: Message Header Extensions for Non-ASCII Text", 821 RFC 2047, November 1996. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 827 April 2001. 829 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 830 Language", RFC 5228, January 2008. 832 14.2. Informative References 834 [I-D.ietf-sieve-body] 835 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 836 Extension", draft-ietf-sieve-body-09 (work in progress), 837 March 2008. 839 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 840 RFC 5229, January 2008. 842 Authors' Addresses 844 Tony Hansen 845 AT&T Laboratories 846 200 Laurel Ave. 847 Middletown, NJ 07748 848 USA 850 Email: tony+sieveloop@maillennium.att.com 851 Cyrus Daboo 852 Apple Inc. 853 1 Infinite Loop 854 Cupertino, CA 95014 855 USA 857 Email: cyrus@daboo.name 858 URI: http://www.apple.com/ 860 Full Copyright Statement 862 Copyright (C) The IETF Trust (2008). 864 This document is subject to the rights, licenses and restrictions 865 contained in BCP 78, and except as set forth therein, the authors 866 retain all their rights. 868 This document and the information contained herein are provided on an 869 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 870 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 871 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 872 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 873 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 876 Intellectual Property 878 The IETF takes no position regarding the validity or scope of any 879 Intellectual Property Rights or other rights that might be claimed to 880 pertain to the implementation or use of the technology described in 881 this document or the extent to which any license under such rights 882 might or might not be available; nor does it represent that it has 883 made any independent effort to identify any such rights. Information 884 on the procedures with respect to rights in RFC documents can be 885 found in BCP 78 and BCP 79. 887 Copies of IPR disclosures made to the IETF Secretariat and any 888 assurances of licenses to be made available, or the result of an 889 attempt made to obtain a general license or permission for the use of 890 such proprietary rights by implementers or users of this 891 specification can be obtained from the IETF on-line IPR repository at 892 http://www.ietf.org/ipr. 894 The IETF invites any interested party to bring to its attention any 895 copyrights, patents or patent applications, or other proprietary 896 rights that may cover technology that may be required to implement 897 this standard. Please address the information to the IETF at 898 ietf-ipr@ietf.org.