idnits 2.17.1 draft-ietf-sieve-mime-loop-03.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 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 724. 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 184 has weird spacing: '... :type parse...' == Line 188 has weird spacing: '...subtype parse...' == Line 192 has weird spacing: '...enttype parse...' == Line 196 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 (July 8, 2007) is 6136 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 157, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 249, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 250, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 250, but not defined == Missing Reference: 'MODIFIER' is mentioned on line 379, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-09) exists of draft-ietf-sieve-body-06 == Outdated reference: A later version (-11) exists of draft-ietf-sieve-editheader-08 Summary: 2 errors (**), 0 flaws (~~), 14 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: January 9, 2008 Apple Computer 6 July 8, 2007 8 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, 9 Replacement and Enclosure 10 draft-ietf-sieve-mime-loop-03 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 January 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The Sieve email filtering language has no way to examine individual 44 MIME parts or any way to manipulate those individual parts. However, 45 being able to filter based on MIME content is important. This 46 document defines extensions for these needs. 48 Note 50 This document is being discussed on the MTA-FILTERS mailing list, 51 ietf-mta-filters@imc.org. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 57 3. Sieve Loops . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Changes to Sieve tests . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Test "header" . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Test "address" . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Test "exists" . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Action Replace . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Action Enclose . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Action extract_text . . . . . . . . . . . . . . . . . . . . . 9 65 8. Sieve Capability Strings . . . . . . . . . . . . . . . . . . . 9 66 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 13. Change History (to be removed prior to publication as an 74 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 13.1. draft-ietf-sieve-mime-02 . . . . . . . . . . . . . . . . . 14 76 13.2. draft-ietf-sieve-mime-01 . . . . . . . . . . . . . . . . . 14 77 13.3. draft-ietf-sieve-mime-00 . . . . . . . . . . . . . . . . . 14 78 13.4. draft-hansen-sieve-loop-01 . . . . . . . . . . . . . . . . 14 79 13.5. draft-hansen-sieve-loop-02 . . . . . . . . . . . . . . . . 14 80 13.6. draft-hansen-sieve-loop-03 . . . . . . . . . . . . . . . . 15 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 Intellectual Property and Copyright Statements . . . . . . . . . . 17 87 1. Introduction 89 Sieve scripts are used to make decisions about the disposition of an 90 email message. The base Sieve specification, 91 [I-D.ietf-sieve-3028bis], defines operators for looking at the 92 message headers, such as addresses and the subject. Other extensions 93 provide access to the body of the message ([I-D.ietf-sieve-body]), or 94 allow you to manipulate the header of the message 95 ([I-D.ietf-sieve-editheader]). But none of these extensions take 96 into account that MIME messages ([RFC2045]) are often complex 97 objects, consisting of many parts and sub-parts. This extension 98 defines mechanisms for performing tests on MIME body parts, looping 99 through the MIME body parts, extracting information from a MIME body 100 part, changing the contents of a MIME body part, and enclosing the 101 entire message with a wrapper. 103 2. Conventions Used in This Document 105 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 106 1.1. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Sieve Loops 114 The base Sieve language has no looping mechanism. Given that 115 messages may contain multiple parts, in order to support filters that 116 apply to any and all parts, we introduce a new control command: 117 "for_every_part", which is an iterator that walks though every MIME 118 part of a message, including nested parts, and applies the commands 119 in the specified block to each of them. The iterator will start with 120 the first MIME part (as its current context) and will execute a 121 command block (Sieve commands enclosed by { ...}). Upon completion 122 of this command block, the iterator advances to the next MIME part 123 (as its current context) and executes the same command block again. 125 The iterator can be terminated prematurely by a new Sieve command, 126 "break". 128 Usage: for_every_part block 129 Usage: break; 131 "for_every_part" commands can be nested inside other "for_every_part" 132 commands. When this occurs, the nested "for_every_part" iterates 133 over the MIME parts contained within the MIME part current being 134 targeted by the nearest enclosing "for_every_part" command. If that 135 MIME part is a terminal MIME part (i.e. does not contain other MIME 136 parts) then the nested "for_every_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 4. Changes to Sieve tests 144 This specification extends the base Sieve "header", "address" and 145 "exists" tests to support targeting those tests at a specific MIME 146 part or at all MIME parts in the enclosing scope. 148 4.1. Test "header" 150 The "header" test is extended with the addition of a new ":mime" 151 tagged argument, which takes a number of other arguments. 153 Usage: header [:mime] [:anychild] [MIMEOPTS] 154 [COMPARATOR] [MATCH-TYPE] 155 157 Usage: The definition of [MIMEOPTS] is: 159 Syntax: ":type" / ":subtype" / ":contenttype" / 160 ":param" 162 When the ":mime" tagged argument is present in the "header" test, it 163 will parse the MIME header lines in a message so that tests can be 164 performed on specific elements. 166 If the ":anychild" tagged argument is NOT specified: 168 o If used within the context of a "for_every_part" iterator, the 169 "header" test will examine the headers associated with the current 170 MIME part context from the loop. 172 o If used outside the context of a "for_every_part" iterator, the 173 "header" test will examine only the outer, top-level, headers of 174 the message. 176 If the ":anychild" tagged argument IS specified, the "header" test 177 will examine all MIME body parts and return true if any of them 178 satisfies the test. 180 The "header" test with the ":mime" tagged argument can test various 181 aspects of certain structed MIME headers. These options are 182 available: 184 :type parses the header assuming it has the format of a "Content- 185 Type:" MIME header field, and tests the value of the MIME type 186 specified in the header. 188 :subtype parses the header assuming it has the format of a "Content- 189 Type:" MIME header field, and tests the value of the MIME subtype 190 specified in the header. 192 :contenttype parses the header assuming it has the format of a 193 "Content-Type:" MIME header field, and tests the combined value of 194 the MIME type and subtype specified in the header. 196 :param parses the header looking for MIME parameters in the header. 197 The supplied string-list lists the names of any parameters to be 198 tested. If any one named parameter value matches the test string 199 value, the test will return true. 201 Example: 203 require ["mime", "fileinto"]; 205 if header :mime :type "Content-Type" "image" 206 { 207 fileinto "INBOX.images"; 208 } 210 In this example, any message that contains a MIME image type part at 211 the top-level is saved to the mailbox "INBOX.images". 213 Example: 215 require ["mime", "fileinto"]; 217 if header :mime :anychild :contenttype :comparator 218 "Content-Type" "text/html" 219 { 220 fileinto "INBOX.html"; 221 } 223 In this example, any message that contains any MIME part with a 224 content-type of "text/html" is saved to the mailbox "INBOX.html". 226 Example: 228 require ["mime", "for_every_part", "fileinto"]; 230 for_every_part 231 { 232 if header :mime :param "filename" :comparator 233 "Content-Disposition" "important" 234 { 235 fileinto "INBOX.important"; 236 break; 237 } 238 } 240 In this example, any message that contains any MIME part with a 241 content-disposition with a filename parameter containing the text 242 "important" is saved to the mailbox "INBOX.important". 244 4.2. Test "address" 246 The "address" test is extended with the addition of a new ":mime" 247 tagged argument, which takes a number of other arguments. 249 Usage: address [:mime] [:anychild] [COMPARATOR] 250 [ADDRESS-PART] [MATCH-TYPE] 251 253 When the ":mime" tagged argument is present in the "address" test, it 254 will parse the MIME header lines as if they were standard address 255 header lines in a message so that tests can be performed on specific 256 elements. 258 The behavior of the ":anychild" tagged argument and the interaction 259 with the "for_every_part" iterator is the same as for the extended 260 "header" test Section 4.1. 262 Example: 264 require ["mime", "fileinto"]; 266 if address :mime :is :all "content-from" "tim@example.com" 267 { 268 fileinto "INBOX.part-from-tim"; 269 } 271 In this example, any message that contains a MIME Content-From header 272 at the top-level matching the text "tim@example.com" is saved to the 273 mailbox "INBOX.part-from-time". 275 4.3. Test "exists" 277 The "exists" test is extended with the addition of a new ":mime" 278 tagged argument, which takes one other argument. 280 Usage: exists [:mime] [:anychild] 282 When the ":mime" tagged argument is present in the "exists" test, the 283 test is extended to check for the existence of MIME headers in MIME 284 parts. 286 The behavior of the ":anychild" tagged argument and the interaction 287 with the "for_every_part" iterator is the same as for the extended 288 "header" test Section 4.1. 290 Example: 292 require ["mime", "fileinto"]; 294 if exists :mime :anychild "content-md5" 295 { 296 fileinto "INBOX.md5"; 297 } 299 In this example, any message that contains a MIME Content-MD5 header 300 in any MIME part is saved to the mailbox "INBOX.md5". 302 5. Action Replace 304 Usage: replace [:mime] [:subject string] [:from string] 305 307 The "replace" command is defined to allow a MIME part to be replaced 308 with the text supplied in the command. 310 When used in the context of a "for_every_part" iterator, the MIME 311 part to be replaced is the "current" MIME part. If the current MIME 312 context is a multipart MIME part, the entire multipart MIME part is 313 replaced, which would alter the MIME structure of the message by 314 eliminating all of the children of the multipart part. (Replacing a 315 non-multipart MIME part within a "for_every_part" loop context does 316 not alter the overall message structure.) If the MIME structure is 317 altered, the change takes effect immediately: the "for_every_part" 318 iterator that is executing does not go into the no-longer existing 319 body parts, and subsequent "for_every_part" iterators would use the 320 new message structure. 322 When used outside the context of a "for_every_part" loop, the MIME 323 part to be replaced is the entire message. 325 If the :mime parameter is not specified, the replacement string is a 326 text/plain part. 328 If the :mime parameter is specified, then the replacement string is, 329 in fact, a MIME entity as defined in [RFC2045] section 2.4, including 330 both MIME headers and content. If the optional :mime parameter is 331 not supplied, the reason string is considered to be a UTF-8 string. 333 If the entire message is being replaced, a ":subject" parameter 334 specifies a subject line to attach to the message that is generated. 335 UTF-8 characters can be used in the string argument; implementations 336 MUST convert the string to [RFC2047] encoded words if and only if 337 non-ASCII characters are present. Implementations MUST preserve the 338 previous Subject header as an Original-Subject header. 340 If the entire message is being replaced, a ":from" parameter may be 341 used to specify an alternate address to use in the From field of the 342 message that is generated. The string must specify a valid [RFC2822] 343 mailbox-list. Implementations SHOULD check the syntax and generate 344 an error when a syntactically invalid ":from" parameter is specified. 345 Implementations MAY also impose restrictions on what addresses can be 346 specified in a ":from" parameter; it is suggested that values that 347 fail such a validity check simply be ignored rather than causing the 348 replace action to fail. Implementations MUST preserve the previous 349 From header as an Original-From header. 351 6. Action Enclose 353 Usage: enclose <:subject string> <:headers string-list> string 355 A new Sieve action command is defined to allow an entire message to 356 be enclosed as an attachment to a new message. After enclosure, 357 subsequent actions affecting the message header or content use the 358 newly create message instead of the original message; this means that 359 any use of a "replace" action or other similar actions should be 360 executed before the "enclose" action. 362 If multiple "enclose" actions are executed by a script, only the text 363 specified on the last one is used when creating the enclosed message. 364 This action does not affect messages that are forwarded via a 365 "redirect" action. 367 Specifically, the original message becomes a multipart/mixed message 368 with two parts: a text/plain portion with the string argument as its 369 body, and a message/rfc822 portion with the original message 370 enclosed. The Content-Type: header field becomes multipart/mixed. 371 The Subject: header is specified by the :subject argument. Any 372 headers specified by :headers are copied from the old message into 373 the new message. If not specified by :headers, Date: and From: 374 headers should be synthesized to reflect the current date and the 375 user running the Sieve action. 377 7. Action extract_text 379 Usage: extract_text [MODIFIER] [":first" number] 381 The extract_text action may be used within the context of a 382 "for_every_part" loop. It stores at most :first bytes of the current 383 MIME body part in the variable identified by varname. If the :first 384 parameter is not present, the whole content of the current MIME body 385 part is stored. In either case the actually stored data MAY be 386 truncated to conform to implementation specific limit on variable 387 length and/or on MIME body part length. QUESTION: What do we do if 388 the Content-Transfer-Encoding is anything other than 7bit? 390 If extract_text is used outside the context of a "for_every_part" 391 loop, the action will set the variable identified by varname to the 392 empty string. 394 Modifiers are applied on the extracted text before it is stored in 395 the variable. See [I-D.ietf-sieve-variables] for details. 397 8. Sieve Capability Strings 399 A Sieve implementation that defines the "for_every_part" and "break" 400 actions will advertise the capability string "for_every_part". 402 A Sieve implementation that defines the ":mime" tagged arguments to 403 the "header", "address" and "exists" commands will advertise the 404 capability string "mime". 406 A Sieve implementation that defines the "replace" action will 407 advertise the capability string "replace". 409 A Sieve implementation that defines the "enclose" action will 410 advertise the capability string "enclose". 412 A Sieve implementation that defines the "extract_text" action will 413 advertise the capability string "extract_text". Note that to be 414 useful, the "extract_text" action also requires the "variables" 415 [I-D.ietf-sieve-variables] and "mime" capabilities. 417 9. Examples 419 9.1. Example 1 421 A Sieve script to replace all the Windows executable attachments in a 422 message would be: 424 require [ "for_every_part", "mime", "replace" ]; 425 for_every_part 426 { 427 if ( anyof ( 428 header :mime :contenttype :is "Content-Type" "application/exe", 429 header :mime :param "filename" 430 ["Content-Type", "Content-Disposition"] :matches "*.com" ) 431 { 432 replace "Executable attachment removed by user filter"; 433 } 434 } 436 9.2. Example 2 438 A Sieve script to warn the user about executable attachment types 439 would be: 441 require [ "for_every_part", "mime", "enclose" ]; 443 for_every_part 444 { 445 if header :mime :param "filename" 446 ["Content-Type", "Content-Disposition"] :matches 447 ["*.com", "*.exe", "*.vbs", "*.scr", 448 "*.pif", "*.hta", "*.bat", "*.zip" ] 449 { 450 # these attachment types are executable 451 enclose :subject "Warning" " 452 WARNING! The enclosed message contains executable attachments. 453 These attachments types may contain a computer virus program 454 that can infect your computer and potentently damage your data 456 Before clicking on these message attachments, you should verify 457 with the sender that this message was sent by them and not a 458 computer virus. 459 "; 460 break; 461 } 462 } 464 9.3. Example 3 466 A Sieve script to extract subject and text out of messages from the 467 boss 468 require ["mime", "variables", "extract_text"]; 470 if header :contains "from" "boss@example.org" 471 { 472 # :matches is used to get the value of the Subject header 473 if header :matches "Subject" "*" 474 { 475 set "subject" "${1}"; 476 } 478 # extract the first 100 bytes of the first text/* part 479 for_every_part 480 { 481 if header :mime :type :is "Content-Type" "text" 482 { 483 extract_text :first 100 "msgcontent"; 484 break; 485 } 486 } 488 # if it's not a 'for your information' message 489 if not header :contains "subject" "FYI:" 490 { 491 # do something using ${subject} and ${msgcontent} 492 # such as sending a notification using a notification extion 493 } 494 } 496 10. Acknowledgements 498 Comments from members of the MTA Filters Working Group, in particular 499 Ned Freed, Nigel Swinson, Mark Mallett and Alexey Melnikov, are 500 gratefully acknowledged. 502 11. Security Considerations 504 The "enclose" action creates an entirely new message, as compared to 505 just redirecting or forwarding the existing message. Therefore, any 506 site policies applicable to message submission should be enforced 507 here. 509 The looping specification specified here provides easier access to 510 information about the message contents, which may also be achieved 511 through other sieve tests. This is not believed to raise any 512 additional security issues beyond those for the Sieve "envelope" and 513 "body" tests. 515 The system MUST be sized and restricted in such a manner that even 516 malicious use of mime part matching does not deny service to other 517 users of the host system. 519 Any change in a message content may interfere with digital signature 520 mechanisms that include the body in the signed material. 522 All of the security considerations given in the base Sieve 523 specification also apply to these extensions. 525 12. IANA Considerations 527 The Original-Subject: and Original-From: headers are to be registered 528 in the Permanent Message Header Fields table. 530 The following template specifies the IANA registration of the Sieve 531 extensions specified in this document: 533 To: iana@iana.org Subject: Registration of new Sieve extensions 534 Capability name: for_every_part 535 Description: adds the "for_every_part" and "break" actions for 536 iterating through MIME parts of a message. 537 Capability name: mime 538 Description: adds ":mime" tagged arguments to the "header", "address" 539 and "exists" commands. 540 Capability name: replace 541 Description: adds the "replace" action for replacing a MIME body part 542 of a message. 543 Capability name: enclose 544 Description: adds the "enclose" action for enclosing a message with a 545 wrapper. 546 Capability name: extract_text 547 Description: adds the "extract_text" action for extracting text from 548 a MIME body part. 549 RFC number: RFC XXXX 550 Contact address: The Sieve discussion list 551 . 553 This information should be added to the list of sieve extensions 554 given on http://www.iana.org/assignments/sieve-extensions. 556 13. Change History (to be removed prior to publication as an RFC) 557 13.1. draft-ietf-sieve-mime-02 559 minor syntax glitches in examples 561 Add clarification on "replace" affecting subsequent for_every_part 562 loops? 564 Add IANA considerations for Original-Subject: and Original-From:. 566 Add note on "enclose" creating From: and Date: headers. 568 13.2. draft-ietf-sieve-mime-01 570 what happens when nested for_every_loop's 572 a "mime" shorthand for testing the type/subtype, without requiring 574 interactions with variables 575 notifications 576 notifications to calendar service 577 address tests, exists tests 578 mimeheader, mimeparameter tests 580 13.3. draft-ietf-sieve-mime-00 582 Changed title and text to emphasize MIME Tests. 584 Changed for.every.part to for_every_part. 586 Added :anychild to mime test. Default is to use the current context 587 or outer envelope; specifying :anychild will look at all children. 589 Added clarifications to replacing parts affecting the structure. 591 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 593 Various other minor nit fixes. 595 13.4. draft-hansen-sieve-loop-01 597 Merged with draft-daboo-sieve-mime-00.txt. 599 13.5. draft-hansen-sieve-loop-02 601 Update to 3028bis reference. 603 Added 2119 conventions section. 605 Terminology/title tweaks. 607 Added informative references to body and editheader extensions. 609 Added description of nested loops. 611 Replaced mime test by extensions to header, address and exists 612 tests. 614 13.6. draft-hansen-sieve-loop-03 616 after enclosure, subsequent actions affect newly created message 618 synthesis of Date/From headers by the enclose action is no longer 619 controversial 621 Filled in Security Considerations 623 Picked up extract_text action from draft-ietf-sieve-notify 625 Expanded the IANA considerations section 627 14. References 629 14.1. Normative References 631 [I-D.ietf-sieve-3028bis] 632 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 633 Language", draft-ietf-sieve-3028bis-12 (work in progress), 634 February 2007. 636 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 637 Extensions (MIME) Part One: Format of Internet Message 638 Bodies", RFC 2045, November 1996. 640 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 641 Part Three: Message Header Extensions for Non-ASCII Text", 642 RFC 2047, November 1996. 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 648 April 2001. 650 14.2. Informative References 652 [I-D.ietf-sieve-body] 653 Guenther, P. and J. Degener, "Sieve Email Filtering: Body 654 Extension", draft-ietf-sieve-body-06 (work in progress), 655 February 2007. 657 [I-D.ietf-sieve-editheader] 658 Guenther, P. and J. Degener, "Sieve Email Filtering: 659 Editheader Extension", draft-ietf-sieve-editheader-08 660 (work in progress), March 2007. 662 [I-D.ietf-sieve-variables] 663 Homme, K., "Sieve Extension: Variables", 664 draft-ietf-sieve-variables-08 (work in progress), 665 December 2005. 667 Authors' Addresses 669 Tony Hansen 670 AT&T Laboratories 671 200 Laurel Ave. 672 Middletown, NJ 07748 673 USA 675 Email: tony+sieveloop@maillennium.att.com 677 Cyrus Daboo 678 Apple Computer, Inc. 679 1 Infinite Loop 680 Cupertino, CA 95014 681 USA 683 Email: cyrus@daboo.name 684 URI: http://www.apple.com/ 686 Full Copyright Statement 688 Copyright (C) The IETF Trust (2007). 690 This document is subject to the rights, licenses and restrictions 691 contained in BCP 78, and except as set forth therein, the authors 692 retain all their rights. 694 This document and the information contained herein are provided on an 695 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 696 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 697 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 698 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 699 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 702 Intellectual Property 704 The IETF takes no position regarding the validity or scope of any 705 Intellectual Property Rights or other rights that might be claimed to 706 pertain to the implementation or use of the technology described in 707 this document or the extent to which any license under such rights 708 might or might not be available; nor does it represent that it has 709 made any independent effort to identify any such rights. Information 710 on the procedures with respect to rights in RFC documents can be 711 found in BCP 78 and BCP 79. 713 Copies of IPR disclosures made to the IETF Secretariat and any 714 assurances of licenses to be made available, or the result of an 715 attempt made to obtain a general license or permission for the use of 716 such proprietary rights by implementers or users of this 717 specification can be obtained from the IETF on-line IPR repository at 718 http://www.ietf.org/ipr. 720 The IETF invites any interested party to bring to its attention any 721 copyrights, patents or patent applications, or other proprietary 722 rights that may cover technology that may be required to implement 723 this standard. Please address the information to the IETF at 724 ietf-ipr@ietf.org. 726 Acknowledgment 728 Funding for the RFC Editor function is provided by the IETF 729 Administrative Support Activity (IASA).