idnits 2.17.1 draft-ietf-sieve-mime-loop-06.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 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 845. 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 194 has weird spacing: '... :type parse...' == Line 198 has weird spacing: '...subtype parse...' == Line 202 has weird spacing: '...enttype parse...' == Line 206 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 (September 12, 2008) is 5703 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 163, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 262, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 263, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 263, but not defined == Missing Reference: 'MODIFIER' is mentioned on line 391, 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: March 16, 2009 Apple Inc. 6 September 12, 2008 8 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, 9 Replacement and Enclosure 10 draft-ietf-sieve-mime-loop-06 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 March 16, 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" . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Action "enclose" . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Action "extracttext" . . . . . . . . . . . . . . . . . . . . . 9 60 8. Sieve Capability Strings . . . . . . . . . . . . . . . . . . . 9 61 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 63 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 64 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 12.1. foreverypart capability . . . . . . . . . . . . . . . . . 13 69 12.2. mime capability . . . . . . . . . . . . . . . . . . . . . 14 70 12.3. replace capability . . . . . . . . . . . . . . . . . . . 14 71 12.4. enclose capability . . . . . . . . . . . . . . . . . . . 14 72 12.5. extracttext capability . . . . . . . . . . . . . . . . . 14 73 13. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 74 13.1. draft-ietf-sieve-mime-06 . . . . . . . . . . . . . . . . 15 75 13.2. draft-ietf-sieve-mime-05 . . . . . . . . . . . . . . . . 15 76 13.3. draft-ietf-sieve-mime-04 . . . . . . . . . . . . . . . . 15 77 13.4. draft-ietf-sieve-mime-03 . . . . . . . . . . . . . . . . 15 78 13.5. draft-ietf-sieve-mime-02 . . . . . . . . . . . . . . . . 16 79 13.6. draft-ietf-sieve-mime-01 . . . . . . . . . . . . . . . . 16 80 13.7. draft-ietf-sieve-mime-00 . . . . . . . . . . . . . . . . 16 81 13.8. draft-sieve-mime-loop-04 . . . . . . . . . . . . . . . . 16 82 13.9. draft-hansen-sieve-loop-03 . . . . . . . . . . . . . . . 17 83 13.10. draft-hansen-sieve-loop-02 . . . . . . . . . . . . . . . 17 84 13.11. draft-hansen-sieve-loop-01 . . . . . . . . . . . . . . . 17 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 14.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 89 Intellectual Property and Copyright Statements . . . . . . . . . . 19 91 1. Introduction 93 MIME messages ([RFC2045]) are often complex objects, consisting of 94 many parts and sub-parts. This extension defines mechanisms for 95 performing tests on MIME body parts, looping through the MIME body 96 parts, extracting information from a MIME body part, changing the 97 contents of a MIME body part, and enclosing the entire message within 98 a wrapper. 100 2. Conventions Used in This Document 102 Conventions for notations are as in [RFC5228] section 1.1. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Sieve Loops: Actions "foreverypart" and "break" 110 The base Sieve language has no looping mechanism. Given that 111 messages may contain multiple parts, in order to support filters that 112 apply to any and all parts, we introduce a new control command: 113 "foreverypart", which is an iterator that walks though every MIME 114 part of a message, including nested parts, depth first, and applies 115 the commands in the specified block to each of them. The iterator 116 will start with the first MIME part (as its current context) and will 117 execute a command block (Sieve commands enclosed by {...}). Upon 118 completion of this command block, the iterator advances to the next 119 MIME part (as its current context) and executes the same command 120 block again. 122 The iterator can be terminated prematurely by a new Sieve command, 123 "break". 125 Usage: foreverypart [":name" string] block 127 Usage: break [":name" string]; 129 "foreverypart" commands can be nested inside other "foreverypart" 130 commands. When this occurs, the nested "foreverypart" iterates over 131 the MIME parts contained within the MIME part currently being 132 targeted by the nearest enclosing "foreverypart" command. (That is, 133 the inner loop only operates on children of the bodypart currently 134 accessed by the outer loop.) If that MIME part is a terminal MIME 135 part (i.e. does not contain other MIME parts) then the nested 136 "foreverypart" loop is simply ignored. 138 Sieve implementations MAY limit the number of nested loops that occur 139 within one another, however they MUST support at least one nested 140 loop inside another loop. 142 If a name is given to a "break" command, it terminates the closest 143 enclosing loop with the identical matching name. (If a nested 144 "foreverypart" name is the same as a "foreverpart" name in an outer 145 level, the outer level name is hidden.) It is an error if there is 146 no enclosing loop with that name. 148 4. Changes to Sieve Tests 150 This specification extends the base Sieve "header", "address" and 151 "exists" tests to support targeting those tests at a specific MIME 152 part or at all MIME parts in the enclosing scope. 154 4.1. Test "header" 156 The "header" test is extended with the addition of a new ":mime" 157 tagged argument and its associated options. 159 Usage: header [":mime"] [":anychild"] [MIMEOPTS] 160 [COMPARATOR] [MATCH-TYPE] 161 163 Usage: The definition of [MIMEOPTS] is: 165 Syntax: ":type" / ":subtype" / ":contenttype" / 166 ":param" 168 When the ":mime" tagged argument is present in the "header" test, it 169 will parse the MIME header lines in the message so that tests can be 170 performed on specific elements. 172 When used outside the context of a "foreverypart" iterator, and 173 without an ":anychild" tagged argument, the "header" test will 174 examine only the outer top-level RFC2822 headers of the message. 176 When used inside the context of a "foreverypart" iterator, and 177 without an ":anychild" tagged argument, the "header" test will 178 examine the headers associated with the current MIME part context 179 from the loop. 181 When used outside the context of a "foreverypart" iterator, and with 182 an ":anychild" tagged argument, the "header" test will examine all 183 MIME body parts and return true if any of them satisfies the test. 185 When used inside the context of a "foreverypart" iterator, and with 186 an ":anychild" tagged argument, the "header" test will examine the 187 current MIME part context and all it's nested MIME body parts, 188 returning true if any of them satisfies the test. 190 The "header" test with the ":mime" tagged argument can test various 191 aspects of certain structured MIME headers. These options are 192 available: 194 :type parses the header assuming it has the format of a "Content- 195 Type:" MIME header field, and tests the value of the MIME type 196 specified in the header. 198 :subtype parses the header assuming it has the format of a "Content- 199 Type:" MIME header field, and tests the value of the MIME subtype 200 specified in the header. 202 :contenttype parses the header assuming it has the format of a 203 "Content-Type:" MIME header field, and tests the combined value of 204 the MIME type and subtype specified in the header. 206 :param parses the header looking for MIME parameters in the header. 207 The supplied string-list lists the names of any parameters to be 208 tested. If any one named parameter value matches the test string 209 value, the test will return true. 211 Example: 213 require ["mime", "fileinto"]; 215 if header :mime :type "Content-Type" "image" 216 { 217 fileinto "INBOX.images"; 218 } 220 In this example, any message that contains a MIME image type part at 221 the top-level is saved to the mailbox "INBOX.images". 223 Example: 225 require ["mime", "fileinto"]; 227 if header :mime :anychild :contenttype 228 "Content-Type" "text/html" 229 { 230 fileinto "INBOX.html"; 231 } 232 In this example, any message that contains any MIME part with a 233 content-type of "text/html" is saved to the mailbox "INBOX.html". 235 Example: 237 require ["mime", "foreverypart", "fileinto"]; 239 foreverypart 240 { 241 if allof ( 242 header :mime :param "filename" :contains 243 "Content-Disposition" "important", 244 header :mime :subtype "Content-Type" "pdf", 245 size :over "100K") 246 { 247 fileinto "INBOX.important"; 248 break; 249 } 250 } 252 In this example, any message that contains a MIME part that has a 253 content-disposition with a filename parameter containing the text 254 "important", has a content-subtype of "pdf" and is bigger than 100 Kb 255 is saved to the mailbox "INBOX.important". 257 4.2. Test "address" 259 The "address" test is extended with the addition of a new ":mime" 260 tagged argument, which takes a number of other arguments. 262 Usage: address [":mime"] [":anychild"] [COMPARATOR] 263 [ADDRESS-PART] [MATCH-TYPE] 264 266 When the ":mime" tagged argument is present in the "address" test, it 267 will parse the MIME header lines as if they were standard address 268 header lines in a message so that tests can be performed on specific 269 elements. 271 The behavior of the ":anychild" tagged argument and the interaction 272 with the "foreverypart" iterator is the same as for the extended 273 "header" test Section 4.1. 275 Example: 277 require ["mime", "fileinto"]; 279 if address :mime :is :all "content-from" "tim@example.com" 280 { 281 fileinto "INBOX.part-from-tim"; 282 } 284 In this example, any message that contains a MIME Content-From header 285 at the top-level matching the text "tim@example.com" is saved to the 286 mailbox "INBOX.part-from-time". 288 4.3. Test "exists" 290 The "exists" test is extended with the addition of a new ":mime" 291 tagged argument, which takes one other argument. 293 Usage: exists [":mime"] [":anychild"] 295 When the ":mime" tagged argument is present in the "exists" test, the 296 test is extended to check for the existence of MIME headers in MIME 297 parts. 299 The behavior of the ":anychild" tagged argument and the interaction 300 with the "foreverypart" iterator is the same as for the extended 301 "header" test Section 4.1. 303 Example: 305 require ["mime", "fileinto"]; 307 if exists :mime :anychild "content-md5" 308 { 309 fileinto "INBOX.md5"; 310 } 312 In this example, any message that contains a MIME Content-MD5 header 313 in any MIME part is saved to the mailbox "INBOX.md5". 315 5. Action "replace" 317 Usage: replace [":mime"] [":subject" string] [":from" string] 318 320 The "replace" command is defined to allow a MIME part to be replaced 321 with the text supplied in the command. 323 When used in the context of a "foreverypart" iterator, the MIME part 324 to be replaced is the "current" MIME part. If the current MIME 325 context is a multipart MIME part, the entire multipart MIME part is 326 replaced, which would alter the MIME structure of the message by 327 eliminating all of the children of the multipart part. (Replacing a 328 non-multipart MIME part within a "foreverypart" loop context does not 329 alter the overall message structure.) If the MIME structure is 330 altered, the change takes effect immediately: the "foreverypart" 331 iterator that is executing does not go into the no-longer existing 332 body parts, and subsequent "foreverypart" iterators would use the new 333 message structure. 335 When used outside the context of a "foreverypart" loop, the MIME part 336 to be replaced is the entire message. 338 If the :mime parameter is not specified, the replacement string is a 339 text/plain part in UTF-8. 341 If the :mime parameter is specified, then the replacement string is, 342 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 343 both MIME headers and content. 345 If the entire message is being replaced, a ":subject" parameter 346 specifies a subject line to attach to the message that is generated. 347 UTF-8 characters can be used in the string argument; implementations 348 MUST convert the string to [RFC2047] encoded words if and only if 349 non-ASCII characters are present. Implementations MUST preserve the 350 previous Subject header as an Original-Subject header. 352 If the entire message is being replaced, a ":from" parameter may be 353 used to specify an alternate address to use in the From field of the 354 message that is generated. The string must specify a valid [RFC2822] 355 mailbox-list. Implementations SHOULD check the syntax and generate 356 an error when a syntactically invalid ":from" parameter is specified. 357 Implementations MAY also impose restrictions on what addresses can be 358 specified in a ":from" parameter; it is suggested that values that 359 fail such a validity check simply be ignored rather than causing the 360 replace action to fail. Implementations MUST preserve the previous 361 From header as an Original-From header. 363 6. Action "enclose" 365 Usage: enclose <:subject string> <:headers string-list> string 367 A new Sieve action command is defined to allow an entire message to 368 be enclosed as an attachment to a new message. After enclosure, 369 subsequent actions affecting the message header or content use the 370 newly created message instead of the original message; this means 371 that any use of a "replace" action or other similar actions should be 372 executed before the "enclose" action. 374 If multiple "enclose" actions are executed by a script, only the text 375 specified on the last one is used when creating the enclosed message. 376 This action does not affect messages that are forwarded via a 377 "redirect" action. 379 Specifically, the original message becomes a multipart/mixed message 380 with two parts: a text/plain portion with the string argument as its 381 body, and a message/rfc822 portion with the original message 382 enclosed. The Content-Type: header field becomes multipart/mixed. 383 The Subject: header is specified by the :subject argument. Any 384 headers specified by :headers are copied from the old message into 385 the new message. If not specified by :headers, Date: and From: 386 headers should be synthesized to reflect the current date and the 387 user running the Sieve action. 389 7. Action "extracttext" 391 Usage: extracttext [MODIFIER] [":first" number] 393 The extracttext action may be used within the context of a 394 "foreverypart" loop. Servers MUST support transcoding of any textual 395 body part into UTF-8 for use with this action. This requires 396 decoding any transfer encoding as well as transcoding from the 397 indicated character set into UTF-8. It stores at most :first 398 characters of the transcoded content of the current MIME body part in 399 the variable identified by varname. If the :first parameter is not 400 present, the whole content of the current MIME body part is stored. 401 In either case the actually stored data MAY be truncated to conform 402 to implementation specific limit on variable length and/or on MIME 403 body part length. If the transfer encoding or character set is 404 unrecognized by the implementation or recognized but invalid, an 405 empty string will result. 407 If extracttext is used outside the context of a "foreverypart" loop, 408 the action will set the variable identified by varname to the empty 409 string. 411 Modifiers are applied on the extracted text before it is stored in 412 the variable. See [RFC5229] for details. 414 8. Sieve Capability Strings 416 A Sieve implementation that defines the "foreverypart" and "break" 417 actions will advertise the capability string "foreverypart". 419 A Sieve implementation that defines the ":mime" and ":anychild" 420 tagged arguments to the "header", "address" and "exists" commands 421 will advertise the capability string "mime". 423 A Sieve implementation that defines the "replace" action will 424 advertise the capability string "replace". 426 A Sieve implementation that defines the "enclose" action will 427 advertise the capability string "enclose". 429 A Sieve implementation that defines the "extracttext" action will 430 advertise the capability string "extracttext". Note that to be 431 useful, the "extracttext" action also requires the "variables" 432 [RFC5229] and "foreverypart" capabilities. 434 9. Examples 436 9.1. Example 1 438 A Sieve script to replace all the Windows executable attachments in a 439 message would be: 441 require [ "foreverypart", "mime", "replace" ]; 442 foreverypart 443 { 444 if anyof ( 445 header :mime :contenttype :is "Content-Type" "application/exe", 446 header :mime :param "filename" 447 ["Content-Type", "Content-Disposition"] :matches "*.com" ) 448 { 449 replace "Executable attachment removed by user filter"; 450 } 451 } 453 9.2. Example 2 455 A Sieve script to warn the user about executable attachment types 456 would be: 458 require [ "foreverypart", "mime", "enclose" ]; 460 foreverypart 461 { 462 if header :mime :param "filename" 463 ["Content-Type", "Content-Disposition"] :matches 464 ["*.com", "*.exe", "*.vbs", "*.scr", 465 "*.pif", "*.hta", "*.bat", "*.zip" ] 466 { 467 # these attachment types are executable 468 enclose :subject "Warning" :text 469 WARNING! The enclosed message contains executable attachments. 470 These attachments types may contain a computer virus program 471 that can infect your computer and potentially damage your data. 473 Before clicking on these message attachments, you should verify 474 with the sender that this message was sent by them and not a 475 computer virus. 476 . 477 break; 478 } 479 } 481 9.3. Example 3 483 A Sieve script to extract subject and text out of messages from the 484 boss: 486 require ["mime", "variables", "extracttext"]; 488 if header :contains "from" "boss@example.org" 489 { 490 # :matches is used to get the value of the Subject header 491 if header :matches "Subject" "*" 492 { 493 set "subject" "${1}"; 494 } 496 # extract the first 100 characters of the first text/* part 497 foreverypart 498 { 499 if header :mime :type :is "Content-Type" "text" 500 { 501 extracttext :first 100 "msgcontent"; 502 break; 503 } 504 } 506 # if it's not a 'for your information' message 507 if not header :contains "subject" "FYI:" 508 { 509 # do something using ${subject} and ${msgcontent} 510 # such as sending a notification using a 511 # notification extension 512 } 513 } 515 10. Acknowledgements 517 Comments from members of the MTA Filters Working Group, in particular 518 Ned Freed, Kjetil Torgrim Homme, Mark Mallett, Alexey Melnikov, Aaron 519 Stone and Nigel Swinson are gratefully acknowledged. 521 11. Security Considerations 523 The "enclose" action creates an entirely new message, as compared to 524 just redirecting or forwarding the existing message. Therefore, any 525 site policies applicable to message submission should be enforced. 527 The looping specification specified here provides easier access to 528 information about the message contents, which may also be achieved 529 through other sieve tests. This is not believed to raise any 530 additional security issues beyond those for the Sieve "envelope" and 531 "body" [I-D.ietf-sieve-body] tests. 533 Any change in message content may interfere with digital signature 534 mechanisms that include that content in the signed material. In 535 particular, using "replace" makes direct changes to the body content 536 and will affect the body hash included in DKIM signatures, or the 537 message signature used for S/MIME or OpenPGP. 539 It is not possible to examine the MIME structure of decrypted content 540 in a multipart/encrypted MIME part. 542 When "enclose" is used on a message containing a multipart/signed 543 MIME part, the SIEVE implementation MUST ensure that the original 544 message is copied octet-for-octet to maintain the validity of the 545 digital signature. 547 The system MUST be sized and restricted in such a manner that even 548 malicious use of mime part matching does not deny service to other 549 users of the host system. 551 All of the security considerations given in the base Sieve 552 specification also apply to these extensions. 554 12. IANA Considerations 556 The Original-Subject: and Original-From: headers are to be registered 557 in the Permanent Message Header Fields table. 559 The following templates specify the IANA registrations of the Sieve 560 extensions specified in this document. This information should be 561 added to the list of sieve extensions given on 562 http://www.iana.org/assignments/sieve-extensions. 564 [[ RFC Editor Note: replace RFC XXXX with a reference to this RFC. ]] 566 12.1. foreverypart capability 568 To: iana@iana.org 569 Subject: Registration of new Sieve extension 571 Capability name: foreverypart 572 Description: adds the "foreverypart" and "break" actions for 573 iterating through MIME parts of a message. 575 RFC number: RFC XXXX 576 Contact address: The Sieve discussion list 577 . 579 12.2. mime capability 581 To: iana@iana.org 582 Subject: Registration of new Sieve extension 584 Capability name: mime 585 Description: adds the ":mime" and ":anychild" tagged arguments to the 586 "header", "address" and "exists" tests. 588 RFC number: RFC XXXX 589 Contact address: The Sieve discussion list 590 . 592 12.3. replace capability 594 To: iana@iana.org 595 Subject: Registration of new Sieve extension 597 Capability name: replace 598 Description: adds the "replace" action for replacing a MIME body part 599 of a message. 601 RFC number: RFC XXXX 602 Contact address: The Sieve discussion list 603 . 605 12.4. enclose capability 607 To: iana@iana.org 608 Subject: Registration of new Sieve extension 609 Capability name: enclose 610 Description: adds the "enclose" action for enclosing a message with a 611 wrapper. 613 RFC number: RFC XXXX 614 Contact address: The Sieve discussion list 615 . 617 12.5. extracttext capability 619 To: iana@iana.org 620 Subject: Registration of new Sieve extension 621 Capability name: extracttext 622 Description: adds the "extracttext" action for extracting text from a 623 MIME body part. 625 RFC number: RFC XXXX 626 Contact address: The Sieve discussion list 627 . 629 13. Change History 631 [[ RFC Editor NOTE: This section is to be removed prior to 632 publication as an RFC. ]] 634 13.1. draft-ietf-sieve-mime-06 636 Added note to foreverypart about nested identical names hiding outer 637 names. 639 Added notes to Security Considerations section about it not working 640 on multipart/signed sections, and how replace/enclose may affect 641 signatures. 643 13.2. draft-ietf-sieve-mime-05 645 Changed for_every_part to foreverypart, and extract_text to 646 extracttext. 648 Add option :name parameter to foreverypart and break. break :name 649 "string" will break out of closest enclosing foreverypart loop 650 with that name. 652 Clarify nesting a bit more. 654 Minor consistency nit picking. 656 13.3. draft-ietf-sieve-mime-04 658 loops are depth first 660 :anychild clarifications 662 update examples 664 grammar nits 666 transcoding for extract_text 668 13.4. draft-ietf-sieve-mime-03 670 add extraction 672 add security considerations 673 fill in iana considerations 675 13.5. draft-ietf-sieve-mime-02 677 minor syntax glitches in examples 679 Add clarification on "replace" affecting subsequent for_every_part 680 loops? 682 Add IANA considerations for Original-Subject: and Original-From:. 684 Add note on "enclose" creating From: and Date: headers. 686 13.6. draft-ietf-sieve-mime-01 688 what happens when nested for_every_part loop's 690 a "mime" shorthand for testing the type/subtype, without requiring 692 interactions with variables 693 notifications 694 notifications to calendar service 695 address tests, exists tests 696 mimeheader, mimeparameter tests 698 13.7. draft-ietf-sieve-mime-00 700 Changed title and text to emphasize MIME Tests. 702 Changed for.every.part to for_every_part. 704 Added :anychild to mime test. Default is to use the current 705 context or outer envelope; specifying :anychild will look at all 706 children. 708 Added clarifications to replacing parts affecting the structure. 710 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 712 Various other minor nit fixes. 714 13.8. draft-sieve-mime-loop-04 716 update reference for recent published rfcs 718 extract-text now required to do decode transfer encoding and 719 transcode to UTF-8 720 removed editheader reference since its not actually used 722 several text changes as suggested by Nigel Swinson, including re- 723 writes to abstract and introduction 725 13.9. draft-hansen-sieve-loop-03 727 after enclosure, subsequent actions affect newly created message 729 synthesis of Date/From headers by the enclose action is no longer 730 controversial 732 Filled in Security Considerations 734 Picked up extract_text action from draft-ietf-sieve-notify 736 Expanded the IANA considerations section 738 13.10. draft-hansen-sieve-loop-02 740 Update to 3028bis reference. 742 Added 2119 conventions section. 744 Terminology/title tweaks. 746 Added informative references to body and editheader extensions. 748 Added description of nested loops. 750 Replaced mime test by extensions to header, address and exists 751 tests. 753 13.11. draft-hansen-sieve-loop-01 755 Merged with draft-daboo-sieve-mime-00.txt. 757 14. References 759 14.1. Normative References 761 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 762 Extensions (MIME) Part One: Format of Internet Message 763 Bodies", RFC 2045, November 1996. 765 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 766 Part Three: Message Header Extensions for Non-ASCII Text", 767 RFC 2047, November 1996. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997. 772 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 773 April 2001. 775 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 776 Language", RFC 5228, January 2008. 778 14.2. Informative References 780 [I-D.ietf-sieve-body] 781 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 782 Extension", draft-ietf-sieve-body-09 (work in progress), 783 March 2008. 785 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 786 RFC 5229, January 2008. 788 Authors' Addresses 790 Tony Hansen 791 AT&T Laboratories 792 200 Laurel Ave. 793 Middletown, NJ 07748 794 USA 796 Email: tony+sieveloop@maillennium.att.com 798 Cyrus Daboo 799 Apple Inc. 800 1 Infinite Loop 801 Cupertino, CA 95014 802 USA 804 Email: cyrus@daboo.name 805 URI: http://www.apple.com/ 807 Full Copyright Statement 809 Copyright (C) The IETF Trust (2008). 811 This document is subject to the rights, licenses and restrictions 812 contained in BCP 78, and except as set forth therein, the authors 813 retain all their rights. 815 This document and the information contained herein are provided on an 816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 818 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 819 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 820 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 823 Intellectual Property 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed to 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the procedures with respect to rights in RFC documents can be 832 found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at 845 ietf-ipr@ietf.org.