idnits 2.17.1 draft-ietf-sieve-mime-loop-00.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 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 355. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 26, 2006) is 6631 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) -- Looks like a reference, but probably isn't: 'COMPARATOR' on line 101 -- Looks like a reference, but probably isn't: 'MATCH-TYPE' on line 101 == Unused Reference: '3' is defined on line 306, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (ref. '4') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3028 (ref. '5') (Obsoleted by RFC 5228, RFC 5429) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 10 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 Expires: August 31, 2006 C. Daboo 5 Cyrusoft International, Inc. 6 February 26, 2006 8 Sieve Extensions: MIME Tests, MIME Bodypart Iteration, Replacement and 9 Enclosure 10 draft-ietf-sieve-mime-loop-00.txt 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 31, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The current Sieve language has no way to look at individual MIME 44 parts, looping mechanism, or any way to manipulate those individual 45 parts. This document defines extensions for each of these needs. 47 Note 48 This document is being discussed in the MTA-FILTERS mailing lists, 49 ietf-mta-filters@imc.org. 51 1. Introduction 53 Sieve scripts are used to make decisions about the disposition of a 54 mail message. The original Sieve spec, [5], defined operators for 55 looking at the message headers, such as addresses and the subject. 56 Other extensions provide access to the body of the message, or allow 57 you to manipulate the header of the message. But none of these 58 extensions take into account that MIME messages ([1]) are often 59 complex objects, consisting of many parts and sub-parts. This 60 extension defines mechanisms for performing tests on MIME body parts, 61 looping through the MIME body parts, changing the contents of a MIME 62 body part, and enclosing the message with a wrapper. 64 2. Sieve Loops 66 The current Sieve language has no looping mechanism. Given that 67 messages may contain multiple attachments, in order to support 68 filters that apply to any and all attachments, we introduce a new 69 control command: "for_every_part", which is an iterator that walks 70 though every MIME part of a message, including nested parts, and 71 applies the specified block to each of them. The iterator will start 72 with the first MIME part (as its current context) and will execute a 73 command block (Sieve commands enclosed by { ...}). Upon completion 74 of this command block, the iterator advances to the next MIME part 75 (as its current context) and executes the same command block again. 77 NOTE: Need to deal with this comment 78 (http://www.imc.org/ietf-mta-filters/mail-archive/msg02707.html): 79 What will this do: for.every.part { if (some test here) { 80 for.every.part { ... } } } i.e. will the internal "for" be anchored 81 at the focus established by the enclosing "for" ? I'd hope so, but 82 this should be stated. 84 NOTE: Need to deal with this comment 85 (http://www.imc.org/ietf-mta-filters/mail-archive/msg02707.html): 86 BTW, shouldn't there be a "mime" shorthand for testing the type/ 87 subtype, without requiring if allof (mime :type "multipart", mime 88 :subtype "alternative") ? Especially for any recursive version of 89 "mime" (since the elements inside of "allof" can be matching 90 different mime parts). 92 The iterator can be terminated prematurely by a new sieve command, 93 "break". 95 Usage: for_every_part block 97 Usage: break; 99 3. Test "mime" 101 Usage: mime [:anychild] [COMPARATOR] [MATCH-TYPE] [] 105 Usage: mime [:filename] ... 107 Usage: mime [:type] ... 109 Usage: mime [:subtype] ... 111 For Sieve tests on MIME parts, a new Sieve test ("mime") is defined. 112 Similar in concept to the Sieve "header" test, it will parse the MIME 113 header lines so that tests can be performed on specific elements. 115 If :anychild is NOT specified: 117 If used within the context of a "for_every_part" iterator, the 118 "mime" test will examine the headers associated with the current 119 MIME part context. 121 If used outside the context of a "for_every_part" iterator, the 122 "mime" test will examine only the outer headers of the message. 124 If :anychild IS specified, the "mime" test will examine all MIME body 125 parts and return true if any of them satisfies the test. 127 The "mime" test has all of the options available from the header 128 test, [5] section 5.7. In addition, these options are available: 130 :filename examines the "Content-Disposition:" header field for its 131 "filename" parameter. If there is no "Content-Disposition:" 132 header field, then it will look at the "Content-Type:" header 133 field for the "name" parameter. 135 :type examines the "Content-Type:" header field type parameter. 137 :subtype examines the "Content-Type:" header field subtype parameter. 139 NOTE: We need to add some way to look at parameter lists, ala 140 http://www.imc.org/ietf-mta-filters/mail-archive/msg01655.html and 141 related messages: Content-Type: text/plain; charset="foo" 143 4. Action Replace 145 Usage: replace ["mime"] [":subject" string] [":from" string] 146 148 A new sieve action command is defined to allow the MIME part to be 149 replaced by a text message. The "replace" command causes a MIME part 150 to be removed and replaced with the text supplied by the command. 152 When used in the context of a "for_every_part" loop, the MIME part to 153 be replaced is the "current" MIME part. If the current MIME context 154 is a multipart MIME part, the entire multipart MIME part is replaced, 155 which would alter the MIME structure of the message by eliminating 156 all of the children of the multipart part. (Replacing a non- 157 multipart MIME part within a "for_every_part" loop context does not 158 alter the overall message structure.) 160 When used outside the context of a "for_every_part" loop, the MIME 161 part to be replaced is the entire message. 163 If the :mime parameter is not specified, the replacement string is a 164 text/plain part. 166 If the :mime parameter is specified, then the replacement string is, 167 in fact, a MIME entity as defined in [1] section 2.4, including both 168 MIME headers and content. If the optional :mime parameter is not 169 supplied, the reason string is considered to be a UTF-8 string. 171 If the entire message is being replaced, a ":subject" parameter 172 specifies a subject line to attach to the message that is generated. 173 UTF-8 characters can be used in the string argument; implementations 174 MUST convert the string to [2] encoded words if and only if non-ASCII 175 characters are present. Implementations MUST preserve the previous 176 Subject header as an Original-Subject header. 178 If the entire message is being replaced, a ":from" parameter may be 179 used to specify an alternate address to use in the From field of the 180 message that is generated. The string must specify a valid [4] 181 mailbox-list. Implementations SHOULD check the syntax and generate 182 an error when a syntactically invalid ":from" parameter is specified. 183 Implementations MAY also impose restrictions on what addresses can 184 specified in a ":from" parameter; it is suggested that values which 185 fail such a validity check simply be ignored rather than causing the 186 vacation action to fail. Implementations MUST preserve the previous 187 From header as an Original-From header. 189 5. Action Enclose 191 Usage: enclose <:subject string> <:headers string-list> string 193 A new sieve action command is defined to allow an entire message to 194 be enclosed as an attachment to a new message. This enclose action 195 takes precedance over all other message modifications, such as 196 "replace". If multiple "enclose" actions are executed by a script, 197 only the text specified on the last one is used when creating the 198 enclosed message. This action does not affect messages that are 199 forwarded via a "redirect" action. 201 Specifically, the original message becomes a multipart/mixed message 202 with two parts: a text/plain portion with the string argument as its 203 body, and a message/rfc822 portion with the original message 204 enclosed. The Content-Type: header field becomes multipart/mixed. 205 The Subject: header is specified by the :subject argument. Any 206 headers specified by :headers are copied from the old message into 207 the new message. 209 6. Sieve Capability Strings 211 A Sieve implementation that defines the "for_every_part" and "break" 212 actions will advertise the capability string "for_every_part". 214 A Sieve implementation that defines the "mime" test will advertise 215 the capability string "mime". 217 A Sieve implementation that defines the "replace" action will 218 advertise the capability string "replace". 220 A Sieve implementation that defines the "enclose" action will 221 advertise the capability string "enclose". 223 7. Examples 225 7.1. Example 1 227 A Sieve script to replace all the Windows executable attachments in a 228 message would be: 230 require [ "for_every_part", "mime", "replace" ]; 231 for_every_part { 232 if ( anyof ( mime :subtype :is "exe", mime :filename :matches "*.com" ) { 233 replace "Executable attachment removed by user filter"; 234 } 236 } 238 7.2. Example 2 240 A Sieve script to warn the user about executable attachment types 241 would be: 243 require [ "for_every_part", "mime", "enclose" ]; 245 for_every_part { 246 if mime :filename :matches ["*.com", "*.exe", "*.vbs", "*.scr", 247 "*.pif", "*.hta", "*.bat", "*.zip" ] { 248 # these attachment types are executable 249 enclose :subject "Warning" " 250 WARNING! The enclosed message contains executable attachments. 251 These attachments types may contain a computer virus program 252 that can infect your computer and potentently damage your data 254 Before clicking on these message attachments, you should verify with 255 the sender that this message was sent by them and not a computer virus. 256 "; 257 break; 258 } 259 } 261 8. Acknowledgements 263 Comments from members of the MTA Filters Working Group, in particular 264 Ned Freed, Nigel Swinson and Mark Mallett, are gratefully 265 acknowledged. 267 9. Security Considerations 269 To be provided 271 10. IANA Considerations 273 To be provided 275 11. Change History 277 11.1. draft-ietf-sieve-mime-00 279 Changed title to emphasize MIME Tests. 281 Changed for.every.part to for_every_part. 283 Added :anychild to mime test. Default is to use the current context 284 or outer envelope; specifying :anychild will look at all children. 286 Added clarifications to replacing parts affecting the structure. 288 Added :mime option to replace, ala draft-ietf-sieve-vacation-06. 290 Various other minor nit fixes. 292 11.2. draft-hansen-sieve-loop-01 294 Merged with draft-daboo-sieve-mime-00.txt. 296 12. Normative References 298 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 299 Extensions (MIME) Part One: Format of Internet Message Bodies", 300 RFC 2045, November 1996. 302 [2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 303 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 304 November 1996. 306 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 307 Levels", BCP 14, RFC 2119, March 1997. 309 [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 311 [5] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, 312 January 2001. 314 Authors' Addresses 316 Tony Hansen 317 AT&T Laboratories 318 200 Laurel Ave. 319 Middletown, NJ 07748 320 USA 322 Email: tony+sieveloop@maillennium.att.com 324 Cyrus Daboo 325 Cyrusoft International, Inc. 326 5001 Baum Blvd. 327 Suite 780 328 Pittsburgh, PA 15213 329 USA 331 Email: daboo@cyrusoft.com 333 Intellectual Property Statement 335 The IETF takes no position regarding the validity or scope of any 336 Intellectual Property Rights or other rights that might be claimed to 337 pertain to the implementation or use of the technology described in 338 this document or the extent to which any license under such rights 339 might or might not be available; nor does it represent that it has 340 made any independent effort to identify any such rights. Information 341 on the procedures with respect to rights in RFC documents can be 342 found in BCP 78 and BCP 79. 344 Copies of IPR disclosures made to the IETF Secretariat and any 345 assurances of licenses to be made available, or the result of an 346 attempt made to obtain a general license or permission for the use of 347 such proprietary rights by implementers or users of this 348 specification can be obtained from the IETF on-line IPR repository at 349 http://www.ietf.org/ipr. 351 The IETF invites any interested party to bring to its attention any 352 copyrights, patents or patent applications, or other proprietary 353 rights that may cover technology that may be required to implement 354 this standard. Please address the information to the IETF at 355 ietf-ipr@ietf.org. 357 Disclaimer of Validity 359 This document and the information contained herein are provided on an 360 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 361 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 362 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 363 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 364 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 367 Copyright Statement 369 Copyright (C) The Internet Society (2006). This document is subject 370 to the rights, licenses and restrictions contained in BCP 78, and 371 except as set forth therein, the authors retain all their rights. 373 Acknowledgment 375 Funding for the RFC Editor function is currently provided by the 376 Internet Society.