idnits 2.17.1 draft-ietf-sieve-convert-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 1, 2011) is 4523 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track Q. Sun 5 Expires: June 3, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 December 1, 2011 10 Sieve Extension for Converting Messages Before Delivery 11 draft-ietf-sieve-convert-06 13 Abstract 15 This document describes how the "CONVERT" IMAP extension can be used 16 within the Sieve mail filtering language to transform messages before 17 final delivery. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 3, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in this Document . . . . . . . . . . . . . . 3 56 2. "convert" action . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Interaction with other tests and actions . . . . . . . . . . 4 58 2.2. "convert" as a test . . . . . . . . . . . . . . . . . . . . . 5 60 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The IMAP "CONVERT" extension [RFC5259] adds an IMAP command for 79 performing client-controlled conversions on whole messages or their 80 body parts. This document defines a similar extension to the Sieve 81 mail filtering language [RFC5228], which reuses the conversion 82 parameters and framework established by IMAP CONVERT. 84 1.1. Conventions Used in this Document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 Conventions for notations are as in Sieve [RFC5228] section 1.1, 91 including the use of ABNF [RFC5234]. 93 2. "convert" action 95 Usage: convert 96 97 99 The "convert" action specifies that body parts with "quoted-from- 100 mime-type" MIME type be converted to "quoted-to-mime-type" MIME type 101 using conversion parameters specified in "transcoding-params". Each 102 conversion parameter value has the following syntax: "=", where and are defined in CONVERT [RFC5259]. 105 Messages that don't have any body parts with the "quoted-from-mime- 106 type" MIME type are not affected by the conversion. 108 The "convert" action can be used with Sieve MIME Part Tests 109 [RFC5703], in the case that some, but not all of the body parts need 110 to be converted, or where different body parts might require 111 different conversions. When the "convert" action appears in a 112 "foreverypart" loop, it applies only to the body part being 113 processed, and not to any other body parts (see Section 3.2 for an 114 example). 116 When the "convert" action appears outside a "foreverypart" loop, the 117 conversion applies equally to all body parts -- that is, all body 118 parts that have the "quoted-from-mime-type" are converted, using the 119 same transcoding parameters. 121 A single "convert" action will only apply once to any body part. If, 122 for example, << convert "image/jpeg" "image/jpeg" ["pix-x=100","pix- 123 y=120"] >> converts a larger JPEG image to the smaller 100 x 120 124 size, that will be the end of that "convert" action on that body 125 part. The action will not see a "new" JPEG body part to process, 126 resulting from the conversion. 128 If a "convert" action cannot be completed -- perhaps because the 129 conversion failed, or because the requested conversion is not 130 available -- that "convert" action MUST terminate and leave the 131 message unchanged, rolling back any other conversions done by that 132 action. The script processing continues, and prior or subsequent 133 "convert" actions are not affected. No error condition is raised, 134 and no partial conversions from a single "convert" action are 135 allowed. 137 Implementations might defer any actual conversion until the the 138 results of the conversion are needed for script processing, to avoid 139 doing conversions unnecessarily. Consider the case wherein a 140 "convert" action is processed, but a "discard" action results without 141 the need to actually perform the conversion. 143 When conversions actually need to be done, they can put a significant 144 load on the server. Computationally expensive conversions of a lot 145 of body parts can constitute an attack vector, and even if done 146 legitimately they can create an unacceptable load. Servers MAY 147 refuse conversions, or do them at lower priority, effectively slowing 148 the requesting process in order to avoid negative effects on service 149 to other processes. 151 2.1. Interaction with other tests and actions 153 Whether the actual conversion has been done yet or not, a successful 154 "convert" action effectively changes the message, and all subsequent 155 actions, including any other "convert" actions, apply to the changed 156 message. The "convert" action does not affect the applicability of 157 other actions; any action that was applicable before the "convert" is 158 equally applicable to the changed message afterward. 160 When a disposition-type action, such as "fileinto" or "redirect", is 161 encountered, the state of the message with respect to conversions is 162 "locked in" for that disposition-type action. Whether the 163 implementation performs the action at that point or batches it for 164 later, it MUST perform the action on the message as it stood at the 165 time, and MUST NOT include subsequent conversions encountered later 166 in the script processing. Therefore, the sequence "convert, 167 fileinto, convert, fileinto" will store two different versions of the 168 message: the first "fileinto" uses only the first conversion, while 169 the second uses both. See Section 3.4 for an example of how this can 170 be used. 172 In addition, any tests done on the message and its parts will test 173 the message after prior conversions have been done. The fourth block 174 of Section 3.4 shows an example of this situation. 176 Convert actions are cumulative, and each conversion operates on the 177 message as it stands after all prior conversions. See the fourth 178 block of Section 3.4 for an example of how this might be tricky. 180 Because the implicit keep (see Section 2.10.2 of [RFC5228]), if it is 181 in effect, acts on the final state of the message, all conversions 182 are performed before any implicit keep. 184 2.2. "convert" as a test 186 To simplify testing for supported and successful conversions, the 187 "convert" action can also be used as a test. As such, it will 188 attempt to perform the requested conversion(s), and will evaluate to 189 "false" if and only if at least one conversion failed. The failure 190 can be because a conversion was unsupported, or because the data 191 could not be converted (perhaps it had been corrupted in transit, or 192 mislabeled at its origin). 194 This creates a new type of Sieve action, a "testable action". The 195 usage as a test is exactly the same as for an action, and it doubles 196 as an action and a test of the action's result at the same time. See 197 Section 3.2 for an example of how this test can be used. 199 Note that defining this new testable action does not change the 200 definitions of any other actions -- it does not imply that other 201 actions can be used as tests. Future extensions might define other 202 testable actions, but those specifications would be responsible for 203 clearly specifying that. 205 3. Examples 207 3.1. Example 1 209 In the following example, all "image/tiff" body parts of the message 210 are converted to "image/jpeg" with image resolution of 320x240 211 pixels. The converted message is then subject to the implicit keep. 213 require ["convert"]; 214 convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"]; 216 3.2. Example 2 218 In the following example, all "image/tiff" body parts of the message 219 are converted to "image/jpeg", as in Example 1. If the conversions 220 were successful, those messages are then filed into a mailbox called 221 "INBOX.pics". Other messages (those with no image/tiff body parts) 222 are subject to the implicit keep, and have not been converted. 224 require ["mime", "fileinto", "convert"]; 225 if header :mime :anychild :contenttype 226 "Content-Type" "image/tiff" 227 { 228 if (convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"]) 229 { 230 fileinto "INBOX.pics"; 231 } 232 } 234 3.3. Example 3 236 In the following example, only "image/tiff" body parts with a 237 Content-Disposition of "inline" are converted. Matching parts that 238 are larger than 500 kilobytes are converted using an image resolution 239 of 640x480 pixels, and those smaller are converted to 320x240 pixels. 240 The message disposition is not changed, so the implicit keep will be 241 in effect unless something else in the script changes that. 243 require ["mime", "foreverypart", "fileinto", "convert"]; 244 foreverypart 245 { 246 if header :mime :param "filename" :contains 247 "Content-Disposition" "inline" 248 { 249 if size :over "500K" 250 { 251 convert "image/tiff" "image/jpeg" ["pix-x=640","pix-y=480"]; 252 } else { 253 convert "image/tiff" "image/jpeg" ["pix-x=320","pix-y=240"]; 254 } 255 } 256 } 258 [... script continues ...] 260 3.4. Example 4 262 The following example shows some tricky interactions between multiple 263 "convert" actions and other disposition-type actions. 265 require ["mime", "foreverypart", 266 "fileinto", "redirect" "convert"]; 268 # The first "if" block will convert all image/tiff body parts 269 # to 640x480 jpegs, and will file the message 270 # into the "INBOX.pics" mailbox as converted at this point. 271 if header :mime :anychild :contenttype 272 "Content-Type" "image/tiff" 273 { 274 convert "image/tiff" "image/jpeg" ["pix-x=640","pix-y=480"]; 275 fileinto "INBOX.pics"; 276 } 278 # The second block, the "foreverypart" loop, will convert all 279 # inline jpegs to 320x240 resolution... including any tiff body 280 # parts that had been converted in the first block, above. 281 # Therefore, any tiff that had been converted to a 640x480 jpeg 282 # will be re-converted to a 320x240 jpeg here if its 283 # Content-Disposition is specified as "inline". 284 foreverypart 285 { 286 if header :mime :param "filename" :contains 287 "Content-Disposition" "inline" 288 { 289 convert "image/jpeg" "image/jpeg" ["pix-x=320","pix-y=240"]; 290 } 291 } 293 # The third block will take any message that contains a header 294 # field called "Mobile-Link" and redirect it to the user's 295 # mobile address. The redirected message will include both 296 # conversions above, from block one and block two. 297 if exists "Mobile-Link" 298 { 299 redirect "joe@mobile.example.com"; 300 } 302 # The fourth block will file the message into "Tiff" if it 303 # contains any tiff body parts. But because of the earlier 304 # conversion (in the first block), there will never be any 305 # tiff body parts, so this "fileinto" will never happen. 306 if header :mime :anychild :contenttype 307 "Content-Type" "image/tiff" 309 { 310 fileinto "Tiff"; 311 } 313 # Now, at the end of the script processing, the Sieve 314 # processor will perform an implicit keep if none of 315 # the "fileinto" and "redirect" actions were taken. 316 # The kept message will include any conversions that 317 # were done (that is, any from the second block). 319 4. Security Considerations 321 Security considerations given in IMAP CONVERT [RFC5259] and Sieve 322 [RFC5228] are relevant to this document. There are no additional 323 security considerations resulting from combining the two. 325 5. IANA Considerations 327 IANA is requested to add the following registration to the Sieve 328 Extensions registry, as defined in RFC 5228: 330 Capability name: convert 331 Description: adds a new Sieve test and action that enable Sieve 332 scripts to perform data conversions on the message being 333 delivered. 334 RFC number: this RFC 335 Contact address: The Sieve discussion list 337 6. Acknowledgements 339 The authors also want to thank all who have contributed key insight 340 and extensively reviewed and discussed the concepts of CONVERT. 342 7. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 348 Language", RFC 5228, January 2008. 350 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 351 Specifications: ABNF", STD 68, RFC 5234, January 2008. 353 [RFC5259] Melnikov, A. and P. Coates, "Internet Message Access 354 Protocol - CONVERT Extension", RFC 5259, July 2008. 356 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 357 Tests, Iteration, Extraction, Replacement, and Enclosure", 358 RFC 5703, October 2009. 360 Authors' Addresses 362 Alexey Melnikov 363 Isode Limited 364 5 Castle Business Village 365 36 Station Road 366 Hampton, Middlesex TW12 2BX 367 UK 369 Email: Alexey.Melnikov@isode.com 370 URI: http://www.melnikov.ca/ 372 Qian Sun 373 Huawei Technologies 374 Bantian Longgang 375 Shenzhen, Guandong 518129 376 P.R China 378 Phone: +86 755 28780808 379 Email: sunqian@huawei.com 381 Barry Leiba 382 Huawei Technologies 384 Phone: +1 646 827 0648 385 Email: barryleiba@computer.org 386 URI: http://internetmessagingtechnology.org/ 388 Kepeng Li 389 Huawei Technologies 390 Huawei Base, Bantian, Longgang District 391 Shenzhen, Guangdong 518129 392 P. R. China 394 Phone: +86-755-28974289 395 Email: likepeng@huawei.com