idnits 2.17.1 draft-ietf-sieve-mime-loop-04.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 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 800. 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 188 has weird spacing: '... :type parse...' == Line 192 has weird spacing: '...subtype parse...' == Line 196 has weird spacing: '...enttype parse...' == Line 200 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 (February 23, 2008) is 5904 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 156, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 257, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 258, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 258, but not defined == Missing Reference: 'MODIFIER' is mentioned on line 386, but not defined ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-09) exists of draft-ietf-sieve-body-07 Summary: 2 errors (**), 0 flaws (~~), 12 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: August 26, 2008 Apple Inc. 6 February 23, 2008 8 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, 9 Replacement and Enclosure 10 draft-ietf-sieve-mime-loop-04 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 August 26, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document defines extensions to the Sieve email filtering 44 language to permit analysis and manipulation of the MIME body parts 45 of an email message. 47 Note 49 This document is being discussed on the MTA-FILTERS mailing list, 50 ietf-mta-filters@imc.org. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 3. Sieve Loops . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Changes to Sieve tests . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Test "header" . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Test "address" . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Test "exists" . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Action Replace . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Action Enclose . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Action extract_text . . . . . . . . . . . . . . . . . . . . . 9 64 8. Sieve Capability Strings . . . . . . . . . . . . . . . . . . . 9 65 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 12.1. for_every_part capability . . . . . . . . . . . . . . . . 13 73 12.2. mime capability . . . . . . . . . . . . . . . . . . . . . 13 74 12.3. replace capability . . . . . . . . . . . . . . . . . . . . 14 75 12.4. enclose capability . . . . . . . . . . . . . . . . . . . . 14 76 12.5. extract_text capability . . . . . . . . . . . . . . . . . 14 77 13. Change History (to be removed prior to publication as an 78 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 13.1. draft-ietf-sieve-mime-02 . . . . . . . . . . . . . . . . . 15 80 13.2. draft-ietf-sieve-mime-01 . . . . . . . . . . . . . . . . . 15 81 13.3. draft-ietf-sieve-mime-00 . . . . . . . . . . . . . . . . . 15 82 13.4. draft-hansen-sieve-loop-01 . . . . . . . . . . . . . . . . 16 83 13.5. draft-hansen-sieve-loop-02 . . . . . . . . . . . . . . . . 16 84 13.6. draft-hansen-sieve-loop-03 . . . . . . . . . . . . . . . . 16 85 13.7. draft-sieve-mime-loop-04 . . . . . . . . . . . . . . . . . 16 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 88 14.2. Informative References . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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 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 "for_every_part", 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: for_every_part block 128 Usage: break; 130 "for_every_part" commands can be nested inside other "for_every_part" 131 commands. When this occurs, the nested "for_every_part" iterates 132 over the MIME parts contained within the MIME part currently being 133 targeted by the nearest enclosing "for_every_part" command. If that 134 MIME part is a terminal MIME part (i.e. does not contain other MIME 135 parts) then the nested "for_every_loop" is simply ignored. 137 Sieve implementations MAY limit the number of nested loops that occur 138 within one another, however they MUST support at least one nested 139 loop inside another loop. 141 4. Changes to Sieve tests 143 This specification extends the base Sieve "header", "address" and 144 "exists" tests to support targeting those tests at a specific MIME 145 part or at all MIME parts in the enclosing scope. 147 4.1. Test "header" 149 The "header" test is extended with the addition of a new ":mime" 150 tagged argument and its associated options. 152 Usage: header [:mime] [:anychild] [MIMEOPTS] 153 [COMPARATOR] [MATCH-TYPE] 154 156 Usage: The definition of [MIMEOPTS] is: 158 Syntax: ":type" / ":subtype" / ":contenttype" / 159 ":param" 161 When the ":mime" tagged argument is present in the "header" test, it 162 will parse the MIME header lines in the message so that tests can be 163 performed on specific elements. 165 When used outside the context of a "for_every_part" iterator, and 166 without an ":anychild" tagged argument, the "header" test will 167 examine only the outer top-level RFC2822 headers of the message. 169 When used inside the context of a "for_every_part" iterator, and 170 without an ":anychild" tagged argument, the "header" test will 171 examine the headers associated with the current MIME part context 172 from the loop. 174 When used outside the context of a "for_every_part" iterator, and 175 with an ":anychild" tagged argument, the "header" test will examine 176 all MIME body parts and return true if any of them satisfies the 177 test. 179 When used inside the context of a "for_every_part" iterator, and with 180 an ":anychild" tagged argument, the "header" test will examine the 181 current MIME part context and all it's nested MIME body parts, 182 returning true if any of them satisfies the test. 184 The "header" test with the ":mime" tagged argument can test various 185 aspects of certain structured MIME headers. These options are 186 available: 188 :type parses the header assuming it has the format of a "Content- 189 Type:" MIME header field, and tests the value of the MIME type 190 specified in the header. 192 :subtype parses the header assuming it has the format of a "Content- 193 Type:" MIME header field, and tests the value of the MIME subtype 194 specified in the header. 196 :contenttype parses the header assuming it has the format of a 197 "Content-Type:" MIME header field, and tests the combined value of 198 the MIME type and subtype specified in the header. 200 :param parses the header looking for MIME parameters in the header. 201 The supplied string-list lists the names of any parameters to be 202 tested. If any one named parameter value matches the test string 203 value, the test will return true. 205 Example: 207 require ["mime", "fileinto"]; 209 if header :mime :type "Content-Type" "image" 210 { 211 fileinto "INBOX.images"; 212 } 214 In this example, any message that contains a MIME image type part at 215 the top-level is saved to the mailbox "INBOX.images". 217 Example: 219 require ["mime", "fileinto"]; 221 if header :mime :anychild :contenttype 222 "Content-Type" "text/html" 223 { 224 fileinto "INBOX.html"; 225 } 227 In this example, any message that contains any MIME part with a 228 content-type of "text/html" is saved to the mailbox "INBOX.html". 230 Example: 232 require ["mime", "for_every_part", "fileinto"]; 234 for_every_part 235 { 236 if allof ( 237 header :mime :param "filename" :contains 238 "Content-Disposition" "important", 239 header :mime :subtype "Content-Type" "pdf", 240 size :over "100K") 241 { 242 fileinto "INBOX.important"; 243 break; 244 } 245 } 247 In this example, any message that contains a MIME part that has a 248 content-disposition with a filename parameter containing the text 249 "important", has a content-subtype of "pdf" and is bigger than 100 Kb 250 is saved to the mailbox "INBOX.important". 252 4.2. Test "address" 254 The "address" test is extended with the addition of a new ":mime" 255 tagged argument, which takes a number of other arguments. 257 Usage: address [:mime] [:anychild] [COMPARATOR] 258 [ADDRESS-PART] [MATCH-TYPE] 259 261 When the ":mime" tagged argument is present in the "address" test, it 262 will parse the MIME header lines as if they were standard address 263 header lines in a message so that tests can be performed on specific 264 elements. 266 The behavior of the ":anychild" tagged argument and the interaction 267 with the "for_every_part" iterator is the same as for the extended 268 "header" test Section 4.1. 270 Example: 272 require ["mime", "fileinto"]; 274 if address :mime :is :all "content-from" "tim@example.com" 275 { 276 fileinto "INBOX.part-from-tim"; 277 } 279 In this example, any message that contains a MIME Content-From header 280 at the top-level matching the text "tim@example.com" is saved to the 281 mailbox "INBOX.part-from-time". 283 4.3. Test "exists" 285 The "exists" test is extended with the addition of a new ":mime" 286 tagged argument, which takes one other argument. 288 Usage: exists [:mime] [:anychild] 290 When the ":mime" tagged argument is present in the "exists" test, the 291 test is extended to check for the existence of MIME headers in MIME 292 parts. 294 The behavior of the ":anychild" tagged argument and the interaction 295 with the "for_every_part" iterator is the same as for the extended 296 "header" test Section 4.1. 298 Example: 300 require ["mime", "fileinto"]; 302 if exists :mime :anychild "content-md5" 303 { 304 fileinto "INBOX.md5"; 305 } 307 In this example, any message that contains a MIME Content-MD5 header 308 in any MIME part is saved to the mailbox "INBOX.md5". 310 5. Action Replace 312 Usage: replace [:mime] [:subject string] [:from string] 313 315 The "replace" command is defined to allow a MIME part to be replaced 316 with the text supplied in the command. 318 When used in the context of a "for_every_part" iterator, the MIME 319 part to be replaced is the "current" MIME part. If the current MIME 320 context is a multipart MIME part, the entire multipart MIME part is 321 replaced, which would alter the MIME structure of the message by 322 eliminating all of the children of the multipart part. (Replacing a 323 non-multipart MIME part within a "for_every_part" loop context does 324 not alter the overall message structure.) If the MIME structure is 325 altered, the change takes effect immediately: the "for_every_part" 326 iterator that is executing does not go into the no-longer existing 327 body parts, and subsequent "for_every_part" iterators would use the 328 new message structure. 330 When used outside the context of a "for_every_part" loop, the MIME 331 part to be replaced is the entire message. 333 If the :mime parameter is not specified, the replacement string is a 334 text/plain part in UTF-8. 336 If the :mime parameter is specified, then the replacement string is, 337 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 338 both MIME headers and content. 340 If the entire message is being replaced, a ":subject" parameter 341 specifies a subject line to attach to the message that is generated. 342 UTF-8 characters can be used in the string argument; implementations 343 MUST convert the string to [RFC2047] encoded words if and only if 344 non-ASCII characters are present. Implementations MUST preserve the 345 previous Subject header as an Original-Subject header. 347 If the entire message is being replaced, a ":from" parameter may be 348 used to specify an alternate address to use in the From field of the 349 message that is generated. The string must specify a valid [RFC2822] 350 mailbox-list. Implementations SHOULD check the syntax and generate 351 an error when a syntactically invalid ":from" parameter is specified. 352 Implementations MAY also impose restrictions on what addresses can be 353 specified in a ":from" parameter; it is suggested that values that 354 fail such a validity check simply be ignored rather than causing the 355 replace action to fail. Implementations MUST preserve the previous 356 From header as an Original-From header. 358 6. Action Enclose 360 Usage: enclose <:subject string> <:headers string-list> string 362 A new Sieve action command is defined to allow an entire message to 363 be enclosed as an attachment to a new message. After enclosure, 364 subsequent actions affecting the message header or content use the 365 newly created message instead of the original message; this means 366 that any use of a "replace" action or other similar actions should be 367 executed before the "enclose" action. 369 If multiple "enclose" actions are executed by a script, only the text 370 specified on the last one is used when creating the enclosed message. 371 This action does not affect messages that are forwarded via a 372 "redirect" action. 374 Specifically, the original message becomes a multipart/mixed message 375 with two parts: a text/plain portion with the string argument as its 376 body, and a message/rfc822 portion with the original message 377 enclosed. The Content-Type: header field becomes multipart/mixed. 378 The Subject: header is specified by the :subject argument. Any 379 headers specified by :headers are copied from the old message into 380 the new message. If not specified by :headers, Date: and From: 381 headers should be synthesized to reflect the current date and the 382 user running the Sieve action. 384 7. Action extract_text 386 Usage: extract_text [MODIFIER] [":first" number] 388 The extract_text action may be used within the context of a 389 "for_every_part" loop. Servers MUST support transcoding of any 390 textual body part into UTF-8 for use with this action. This requires 391 decoding any transfer encoding as well as transcoding from the 392 indicated character set into UTF-8. It stores at most :first 393 characters of the transcoded content of the current MIME body part in 394 the variable identified by varname. If the :first parameter is not 395 present, the whole content of the current MIME body part is stored. 396 In either case the actually stored data MAY be truncated to conform 397 to implementation-specific limit on variable length and/or on MIME 398 body part length. If the transfer encoding or character set is 399 unrecognized by the implementation or recognized but invalid, an 400 empty string will result. 402 If extract_text is used outside the context of a "for_every_part" 403 loop, the action will set the variable identified by varname to the 404 empty string. 406 Modifiers are applied on the extracted text before it is stored in 407 the variable. See [RFC5229] for details. 409 8. Sieve Capability Strings 411 A Sieve implementation that defines the "for_every_part" and "break" 412 actions will advertise the capability string "for_every_part". 414 A Sieve implementation that defines the ":mime" and ":anychild" 415 tagged arguments to the "header", "address" and "exists" tests will 416 advertise the capability string "mime". 418 A Sieve implementation that defines the "replace" action will 419 advertise the capability string "replace". 421 A Sieve implementation that defines the "enclose" action will 422 advertise the capability string "enclose". 424 A Sieve implementation that defines the "extract_text" action will 425 advertise the capability string "extract_text". Note that to be 426 useful, the "extract_text" action also requires the "variables" 427 [RFC5229] and "for_every_part" capabilities. 429 9. Examples 431 9.1. Example 1 433 A Sieve script to replace all the Windows executable attachments in a 434 message would be: 436 require [ "for_every_part", "mime", "replace" ]; 437 for_every_part 438 { 439 if anyof ( 440 header :mime :contenttype :is "Content-Type" "application/exe", 441 header :mime :param "filename" 442 ["Content-Type", "Content-Disposition"] :matches "*.com" ) 443 { 444 replace "Executable attachment removed by user filter"; 445 } 446 } 448 9.2. Example 2 450 A Sieve script to warn the user about executable attachment types 451 would be: 453 require [ "for_every_part", "mime", "enclose" ]; 455 for_every_part 456 { 457 if header :mime :param "filename" 458 ["Content-Type", "Content-Disposition"] :matches 459 ["*.com", "*.exe", "*.vbs", "*.scr", 460 "*.pif", "*.hta", "*.bat", "*.zip" ] 461 { 462 # these attachment types are executable 463 enclose :subject "Warning" :text 464 WARNING! The enclosed message contains executable attachments. 465 These attachments types may contain a computer virus program 466 that can infect your computer and potentially damage your data. 468 Before clicking on these message attachments, you should verify 469 with the sender that this message was sent by them and not a 470 computer virus. 471 . 472 break; 473 } 474 } 476 9.3. Example 3 478 A Sieve script to extract subject and text out of messages from the 479 boss: 481 require ["mime", "variables", "extract_text"]; 483 if header :contains "from" "boss@example.org" 484 { 485 # :matches is used to get the value of the Subject header 486 if header :matches "Subject" "*" 487 { 488 set "subject" "${1}"; 489 } 491 # extract the first 100 characters of the first text/* part 492 for_every_part 493 { 494 if header :mime :type :is "Content-Type" "text" 495 { 496 extract_text :first 100 "msgcontent"; 497 break; 498 } 499 } 501 # if it's not a 'for your information' message 502 if not header :contains "subject" "FYI:" 503 { 504 # do something using ${subject} and ${msgcontent} 505 # such as sending a notification using a 506 # notification extensions 507 } 508 } 510 10. Acknowledgements 512 Comments from members of the MTA Filters Working Group, in particular 513 Ned Freed, Kjetil Torgrim Homme, Mark Mallett, Alexey Melnikov, Aaron 514 Stone and Nigel Swinson are gratefully acknowledged. 516 11. Security Considerations 518 The "enclose" action creates an entirely new message, as compared to 519 just redirecting or forwarding the existing message. Therefore, any 520 site policies applicable to message submission should be enforced. 522 The looping specification specified here provides easier access to 523 information about the message contents, which may also be achieved 524 through other sieve tests. This is not believed to raise any 525 additional security issues beyond those for the Sieve "envelope" and 526 "body" [I-D.ietf-sieve-body] tests. 528 The system MUST be sized and restricted in such a manner that even 529 malicious use of mime part matching does not deny service to other 530 users of the host system. 532 Any change in a message content may interfere with digital signature 533 mechanisms that include the body in the signed material. 535 All of the security considerations given in the base Sieve 536 specification also apply to these extensions. 538 12. IANA Considerations 540 The Original-Subject: and Original-From: headers are to be registered 541 in the Permanent Message Header Fields table. 543 The following templates specify the IANA registrations of the Sieve 544 extensions specified in this document. This information should be 545 added to the list of sieve extensions given on 546 http://www.iana.org/assignments/sieve-extensions. 548 12.1. for_every_part capability 550 To: iana@iana.org 552 Subject: Registration of new Sieve extension 554 Capability name: for_every_part 556 Description: adds the "for_every_part" and "break" actions for 557 iterating through MIME parts of a message. 559 RFC number: This RFC 561 Contact address: The Sieve discussion list 562 . 564 12.2. mime capability 566 To: iana@iana.org 568 Subject: Registration of new Sieve extension 570 Capability name: mime 572 Description: adds the ":mime" and ":anychild" tagged arguments to the 573 "header", "address" and "exists" tests. 575 RFC number: This RFC 577 Contact address: The Sieve discussion list 578 . 580 12.3. replace capability 582 To: iana@iana.org 584 Subject: Registration of new Sieve extension 586 Capability name: mime 588 Description: adds the "replace" action for replacing a MIME body part 589 of a message. 591 RFC number: This RFC 593 Contact address: The Sieve discussion list 594 . 596 12.4. enclose capability 598 To: iana@iana.org 600 Subject: Registration of new Sieve extension 602 Capability name: mime 604 Description: adds the "enclose" action for enclosing a message with a 605 wrapper. 607 RFC number: This RFC 609 Contact address: The Sieve discussion list 610 . 612 12.5. extract_text capability 614 To: iana@iana.org 616 Subject: Registration of new Sieve extension 618 Capability name: mime 620 Description: adds the "extract_text" action for extracting text from 621 a MIME body part. 623 RFC number: This RFC 625 Contact address: The Sieve discussion list 626 . 628 13. Change History (to be removed prior to publication as an RFC) 630 13.1. draft-ietf-sieve-mime-02 632 minor syntax glitches in examples 634 Add clarification on "replace" affecting subsequent for_every_part 635 loops? 637 Add IANA considerations for Original-Subject: and Original-From:. 639 Add note on "enclose" creating From: and Date: headers. 641 13.2. draft-ietf-sieve-mime-01 643 what happens when nested for_every_loop's 645 a "mime" shorthand for testing the type/subtype, without requiring 647 interactions with variables 648 notifications 649 notifications to calendar service 650 address tests, exists tests 651 mimeheader, mimeparameter tests 653 13.3. draft-ietf-sieve-mime-00 655 Changed title and text to emphasize MIME Tests. 657 Changed for.every.part to for_every_part. 659 Added :anychild to mime test. Default is to use the current context 660 or outer envelope; specifying :anychild will look at all children. 662 Added clarifications to replacing parts affecting the structure. 664 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 666 Various other minor nit fixes. 668 13.4. draft-hansen-sieve-loop-01 670 Merged with draft-daboo-sieve-mime-00.txt. 672 13.5. draft-hansen-sieve-loop-02 674 Update to 3028bis reference. 676 Added 2119 conventions section. 678 Terminology/title tweaks. 680 Added informative references to body and editheader extensions. 682 Added description of nested loops. 684 Replaced mime test by extensions to header, address and exists 685 tests. 687 13.6. draft-hansen-sieve-loop-03 689 after enclosure, subsequent actions affect newly created message 691 synthesis of Date/From headers by the enclose action is no longer 692 controversial 694 Filled in Security Considerations 696 Picked up extract_text action from draft-ietf-sieve-notify 698 Expanded the IANA considerations section 700 13.7. draft-sieve-mime-loop-04 702 update reference for recent published rfcs 704 extract-text now required to do decode transfer encoding and 705 transcode to UTF-8 707 removed editheader reference since its not actually used 709 several text changes as suggested by Nigel Swinson, including re- 710 writes to abstract and introduction 712 tweaked IANA registrations 714 14. References 715 14.1. Normative References 717 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 718 Extensions (MIME) Part One: Format of Internet Message 719 Bodies", RFC 2045, November 1996. 721 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 722 Part Three: Message Header Extensions for Non-ASCII Text", 723 RFC 2047, November 1996. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, March 1997. 728 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 729 April 2001. 731 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 732 Language", RFC 5228, January 2008. 734 14.2. Informative References 736 [I-D.ietf-sieve-body] 737 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 738 Extension", draft-ietf-sieve-body-07 (work in progress), 739 December 2007. 741 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 742 RFC 5229, January 2008. 744 Authors' Addresses 746 Tony Hansen 747 AT&T Laboratories 748 200 Laurel Ave. 749 Middletown, NJ 07748 750 USA 752 Email: tony+sieveloop@maillennium.att.com 753 Cyrus Daboo 754 Apple Inc. 755 1 Infinite Loop 756 Cupertino, CA 95014 757 USA 759 Email: cyrus@daboo.name 760 URI: http://www.apple.com/ 762 Full Copyright Statement 764 Copyright (C) The IETF Trust (2008). 766 This document is subject to the rights, licenses and restrictions 767 contained in BCP 78, and except as set forth therein, the authors 768 retain all their rights. 770 This document and the information contained herein are provided on an 771 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 772 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 773 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 774 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 775 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 776 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 778 Intellectual Property 780 The IETF takes no position regarding the validity or scope of any 781 Intellectual Property Rights or other rights that might be claimed to 782 pertain to the implementation or use of the technology described in 783 this document or the extent to which any license under such rights 784 might or might not be available; nor does it represent that it has 785 made any independent effort to identify any such rights. Information 786 on the procedures with respect to rights in RFC documents can be 787 found in BCP 78 and BCP 79. 789 Copies of IPR disclosures made to the IETF Secretariat and any 790 assurances of licenses to be made available, or the result of an 791 attempt made to obtain a general license or permission for the use of 792 such proprietary rights by implementers or users of this 793 specification can be obtained from the IETF on-line IPR repository at 794 http://www.ietf.org/ipr. 796 The IETF invites any interested party to bring to its attention any 797 copyrights, patents or patent applications, or other proprietary 798 rights that may cover technology that may be required to implement 799 this standard. Please address the information to the IETF at 800 ietf-ipr@ietf.org. 802 Acknowledgment 804 Funding for the RFC Editor function is provided by the IETF 805 Administrative Support Activity (IASA).