Internet Engineering Task Force T. Hansen Internet-Draft AT&T Laboratories Intended status: Standards Track C. Daboo Expires: April 25, 2007 Apple Computer October 22, 2006 SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and Enclosure draft-ietf-sieve-mime-loop-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The SIEVE email filtering language has no way to examine individual MIME parts or any way to manipulate those individual parts. However, being able to filter based on MIME content is important. This document defines extensions for these needs. Hansen & Daboo Expires April 25, 2007 [Page 1] Internet-Draft SIEVE MIME Operations October 2006 Note This document is being discussed on the MTA-FILTERS mailing list, ietf-mta-filters@imc.org. 1. Introduction SIEVE scripts are used to make decisions about the disposition of an email message. The base SIEVE specification, [I-D.ietf-sieve-3028bis], defines operators for looking at the message headers, such as addresses and the subject. Other extensions provide access to the body of the message ([I-D.ietf-sieve-body]), or allow you to manipulate the header of the message ([I-D.ietf-sieve-editheader]). But none of these extensions take into account that MIME messages ([RFC2045]) are often complex objects, consisting of many parts and sub-parts. This extension defines mechanisms for performing tests on MIME body parts, looping through the MIME body parts, changing the contents of a MIME body part, and enclosing the message with a wrapper. 2. Conventions Used in This Document Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. SIEVE Loops The base SIEVE language has no looping mechanism. Given that messages may contain multiple parts, in order to support filters that apply to any and all parts, we introduce a new control command: "for_every_part", which is an iterator that walks though every MIME part of a message, including nested parts, and applies the commands in the specified block to each of them. The iterator will start with the first MIME part (as its current context) and will execute a command block (SIEVE commands enclosed by { ...}). Upon completion of this command block, the iterator advances to the next MIME part (as its current context) and executes the same command block again. The iterator can be terminated prematurely by a new SIEVE command, "break". Hansen & Daboo Expires April 25, 2007 [Page 2] Internet-Draft SIEVE MIME Operations October 2006 Usage: for_every_part block Usage: break; "for_every_part" commands can be nested inside other "for_every_part" commands. When this occurs, the nested "for_every_part" iterates over the MIME parts contained within the MIME part current being targeted by the nearest enclosing "for_every_part" command. If that MIME part is a terminal MIME part (i.e. does not contain other MIME parts) then the nested "for_every_loop" is simply ignored. SIEVE implementations MAY limit the number of nested loops that occur within one another, however they MUST support at least one nested loop inside another loop. 4. Changes to SIEVE tests This specification extends the base SIEVE "header", "address" and "exists" tests to support targeting those tests at a specific MIME part or at all MIME parts in the enclosing scope. 4.1. Test "header" The "header" test is extended with the addition of a new ":mime" tagged argument, which takes a number of other arguments. Usage: header [:mime] [:anychild] [MIMEOPTS] [COMPARATOR] [MATCH-TYPE] Usage: The definition of [MIMEOPTS] is: Syntax: ":type" / ":subtype" / ":contenttype" / ":param" When the ":mime" tagged argument is present in the "header" test, it will parse the MIME header lines in a message so that tests can be performed on specific elements. If the ":anychild" tagged argument is NOT specified: o If used within the context of a "for_every_part" iterator, the "header" test will examine the headers associated with the current MIME part context from the loop. o If used outside the context of a "for_every_part" iterator, the "header" test will examine only the outer, top-level, headers of Hansen & Daboo Expires April 25, 2007 [Page 3] Internet-Draft SIEVE MIME Operations October 2006 the message. If the ":anychild" tagged argument IS specified, the "header" test will examine all MIME body parts and return true if any of them satisfies the test. The "header" test with the ":mime" tagged argument can test various aspects of certain structed MIME headers. These options are available: :type parses the header assuming it has the format of a "Content- Type:" MIME header field, and tests the value of the MIME type specified in the header. :subtype parses the header assuming it has the format of a "Content- Type:" MIME header field, and tests the value of the MIME subtype specified in the header. :contenttype parses the header assuming it has the format of a "Content-Type:" MIME header field, and tests the combined value of the MIME type and subtype specified in the header. :param parses the header looking for MIME parameters in the header. The supplied string-list lists the names of any parameters to be tested. If any one named parameter value matches the test string value, the test will return true. Example: require ["mime", "fileinto"]; if header :mime :type :comparator "Content-Type" "image" { fileinto "INBOX.images"; } In this example, any message that contains a MIME image type part at the top-level is saved to the mailbox "INBOX.images". Example: require ["mime", "fileinto"]; if header :mime :anychild :contenttype :comparator "Content-Type" "text/html" { fileinto "INBOX.html"; } Hansen & Daboo Expires April 25, 2007 [Page 4] Internet-Draft SIEVE MIME Operations October 2006 In this example, any message that contains any MIME part with a content-type of "text/html" is saved to the mailbox "INBOX.html". Example: require ["mime", "for_every_part", "fileinto"]; for_every_part { if header :mime :param "filename" :comparator "Content-Disposition" "important" { fileinto "INBOX.important"; break; } In this example, any message that contains any MIME part with a content-disposition with a filename parameter containing the text "important" is saved to the mailbox "INBOX.important". 4.2. Test "address" The "address" test is extended with the addition of a new ":mime" tagged argument, which takes a number of other arguments. Usage: address [:mime] [:anychild] [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] When the ":mime" tagged argument is present in the "address" test, it will parse the MIME header lines as if they were standard address header lines in a message so that tests can be performed on specific elements. The behavior of the ":anychild" tagged argument and the interaction with the "for_every_part" iterator is the same as for the extended "header" test Section 4.1. Example: require ["mime", "fileinto"]; if address :mime :is :all "content-from" "tim@example.com" { fileinto "INBOX.part-from-tim"; } In this example, any message that contains a MIME Content-From header Hansen & Daboo Expires April 25, 2007 [Page 5] Internet-Draft SIEVE MIME Operations October 2006 at the top-level matching the text "tim@example.com" is saved to the mailbox "INBOX.part-from-time". 4.3. Test "exists" The "exists" test is extended with the addition of a new ":mime" tagged argument, which takes one other argument. Usage: exists [:mime] [:anychild] When the ":mime" tagged argument is present in the "exists" test, the test is extended to check for the existence of MIME headers in MIME parts. The behavior of the ":anychild" tagged argument and the interaction with the "for_every_part" iterator is the same as for the extended "header" test Section 4.1. Example: require ["mime", "fileinto"]; if exists :mime :anychild "content-md5" { fileinto "INBOX.md5"; } In this example, any message that contains a MIME Content-MD5 header in any MIME part is saved to the mailbox "INBOX.md5". 5. Action Replace Usage: replace [:mime] [:subject string] [:from string] The "replace" command is defined to allow a MIME part to be replaced with the text supplied in the command. When used in the context of a "for_every_part" iterator, the MIME part to be replaced is the "current" MIME part. If the current MIME context is a multipart MIME part, the entire multipart MIME part is replaced, which would alter the MIME structure of the message by eliminating all of the children of the multipart part. (Replacing a non-multipart MIME part within a "for_every_part" loop context does not alter the overall message structure.) When used outside the context of a "for_every_part" loop, the MIME Hansen & Daboo Expires April 25, 2007 [Page 6] Internet-Draft SIEVE MIME Operations October 2006 part to be replaced is the entire message. If the :mime parameter is not specified, the replacement string is a text/plain part. If the :mime parameter is specified, then the replacement string is, in fact, a MIME entity as defined in [RFC2045] section 2.4, including both MIME headers and content. If the optional :mime parameter is not supplied, the reason string is considered to be a UTF-8 string. If the entire message is being replaced, a ":subject" parameter specifies a subject line to attach to the message that is generated. UTF-8 characters can be used in the string argument; implementations MUST convert the string to [RFC2047] encoded words if and only if non-ASCII characters are present. Implementations MUST preserve the previous Subject header as an Original-Subject header. If the entire message is being replaced, a ":from" parameter may be used to specify an alternate address to use in the From field of the message that is generated. The string must specify a valid [RFC2822] mailbox-list. Implementations SHOULD check the syntax and generate an error when a syntactically invalid ":from" parameter is specified. Implementations MAY also impose restrictions on what addresses can be specified in a ":from" parameter; it is suggested that values that fail such a validity check simply be ignored rather than causing the vacation action to fail. Implementations MUST preserve the previous From header as an Original-From header. 6. Action Enclose Usage: enclose <:subject string> <:headers string-list> string A new SIEVE action command is defined to allow an entire message to be enclosed as an attachment to a new message. This enclose action takes precedence over all other message modifications, such as "replace". If multiple "enclose" actions are executed by a script, only the text specified on the last one is used when creating the enclosed message. This action does not affect messages that are forwarded via a "redirect" action. Specifically, the original message becomes a multipart/mixed message with two parts: a text/plain portion with the string argument as its body, and a message/rfc822 portion with the original message enclosed. The Content-Type: header field becomes multipart/mixed. The Subject: header is specified by the :subject argument. Any headers specified by :headers are copied from the old message into the new message. Hansen & Daboo Expires April 25, 2007 [Page 7] Internet-Draft SIEVE MIME Operations October 2006 7. SIEVE Capability Strings A SIEVE implementation that defines the "for_every_part" and "break" actions will advertise the capability string "for_every_part". A SIEVE implementation that defines the ":mime" tagged arguments to the "header", "address" and "exists" commands will advertise the capability string "mime". A SIEVE implementation that defines the "replace" action will advertise the capability string "replace". A SIEVE implementation that defines the "enclose" action will advertise the capability string "enclose". 8. Examples 8.1. Example 1 A SIEVE script to replace all the Windows executable attachments in a message would be: require [ "for_every_part", "mime", "replace" ]; for_every_part { if ( anyof ( header :mime :subtype :is "Content-Type" "exe", header :mime :param "filename" ["Content-Type" "Content-Disposition"] :matches "*.com" ) { replace "Executable attachment removed by user filter"; } } 8.2. Example 2 A SIEVE script to warn the user about executable attachment types would be: Hansen & Daboo Expires April 25, 2007 [Page 8] Internet-Draft SIEVE MIME Operations October 2006 require [ "for_every_part", "mime", "enclose" ]; for_every_part { if header :mime :param "filename" ["Content-Type" "Content-Disposition"] :matches ["*.com", "*.exe", "*.vbs", "*.scr", "*.pif", "*.hta", "*.bat", "*.zip" ] { # these attachment types are executable enclose :subject "Warning" " WARNING! The enclosed message contains executable attachments. These attachments types may contain a computer virus program that can infect your computer and potentently damage your data Before clicking on these message attachments, you should verify with the sender that this message was sent by them and not a computer virus. "; break; } } 9. Acknowledgements Comments from members of the MTA Filters Working Group, in particular Ned Freed, Nigel Swinson and Mark Mallett, are gratefully acknowledged. 10. Security Considerations To be provided 11. IANA Considerations To be provided 12. Change History (to be removed prior to publication as an RFC) 12.1. draft-ietf-sieve-mime-01 what happens when nested for_every_loop's a "mime" shorthand for testing the type/subtype, without requiring Hansen & Daboo Expires April 25, 2007 [Page 9] Internet-Draft SIEVE MIME Operations October 2006 interactions with variables notifications notifications to calendar service address tests, exists tests mimeheader, mimeparameter tests 12.2. draft-ietf-sieve-mime-00 Changed title and text to emphasize MIME Tests. Changed for.every.part to for_every_part. Added :anychild to mime test. Default is to use the current context or outer envelope; specifying :anychild will look at all children. Added clarifications to replacing parts affecting the structure. Added :mime option to replace, ala draft-ietf-sieve-vacation-06. Various other minor nit fixes. 12.3. draft-hansen-sieve-loop-01 Merged with draft-daboo-sieve-mime-00.txt. 12.4. draft-hansen-sieve-loop-02 Update to 3028bis reference. Added 2119 conventions section. Terminology/title tweaks. Added informative references to body and editheader extensions. Added description of nested loops. Replaced mime test by extensions to header, address and exists tests. 13. References 13.1. Normative References [I-D.ietf-sieve-3028bis] Showalter, T. and P. Guenther, "Sieve: An Email Filtering Language", draft-ietf-sieve-3028bis-09 (work in progress), August 2006. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Hansen & Daboo Expires April 25, 2007 [Page 10] Internet-Draft SIEVE MIME Operations October 2006 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 13.2. Informative References [I-D.ietf-sieve-body] Guenther, P. and J. Degener, "Sieve Email Filtering: Body Extension", draft-ietf-sieve-body-04 (work in progress), August 2006. [I-D.ietf-sieve-editheader] Guenther, P. and J. Degener, "Sieve Email Filtering: Editheader Extension", draft-ietf-sieve-editheader-06 (work in progress), August 2006. Authors' Addresses Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA Email: tony+sieveloop@maillennium.att.com Cyrus Daboo Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014 USA Email: cyrus@daboo.name URI: http://www.apple.com/ Hansen & Daboo Expires April 25, 2007 [Page 11] Internet-Draft SIEVE MIME Operations October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hansen & Daboo Expires April 25, 2007 [Page 12]