draft-ietf-sieve-convert-01.txt   draft-ietf-sieve-convert-02.txt 
Sieve Working Group A. Melnikov Sieve Working Group A. Melnikov
Internet-Draft Isode Limited Internet-Draft Isode Limited
Intended status: Standards Track Q. Sun Intended status: Standards Track Q. Sun
Expires: January 9, 2012 B. Leiba Expires: January 26, 2012 B. Leiba
K. Li K. Li
Huawei Technologies Huawei Technologies
July 8, 2011 July 25, 2011
Sieve Extension for converting messages before delivery Sieve Extension for converting messages before delivery
draft-ietf-sieve-convert-01 draft-ietf-sieve-convert-02
Abstract Abstract
This document describes how IMAP CONVERT can be used within Sieve to This document describes how IMAP CONVERT can be used within Sieve to
transform messages before final delivery. transform messages before final delivery.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2012. This Internet-Draft will expire on January 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in this Document . . . . . . . . . . . . . . 3 1.1. Conventions Used in this Document . . . . . . . . . . . . . . 3
2. "convert" action . . . . . . . . . . . . . . . . . . . . . . 3 2. "convert" action . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Interaction with other actions . . . . . . . . . . . . . . . 4 2.1. Interaction with other actions . . . . . . . . . . . . . . . 4
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The IMAP CONVERT extension [RFC5259] adds an IMAP command for The IMAP CONVERT extension [RFC5259] adds an IMAP command for
performing client-controlled conversions on whole messages or their performing client-controlled conversions on whole messages or their
body parts. This document defines a similar extension to the Sieve body parts. This document defines a similar extension to the Sieve
mail filtering language [RFC5228], which reuses the conversion mail filtering language [RFC5228], which reuses the conversion
parameters and framework established by IMAP CONVERT. parameters and framework established by IMAP CONVERT.
1.1. Conventions Used in this Document 1.1. Conventions Used in this Document
skipping to change at page 4, line 16 skipping to change at page 4, line 16
2.1. Interaction with other actions 2.1. Interaction with other actions
Whether the actual conversion has been done yet or not, a "convert" Whether the actual conversion has been done yet or not, a "convert"
action effectively changes the message, and all subsequent actions, action effectively changes the message, and all subsequent actions,
including any other "convert" actions, apply to the changed message. including any other "convert" actions, apply to the changed message.
The "convert" action does not affect the applicability of other The "convert" action does not affect the applicability of other
actions; any action that was applicable before the "convert" is actions; any action that was applicable before the "convert" is
equally applicable to the changed message afterward. equally applicable to the changed message afterward.
All conversions are performed before any disposition-type actions. When a disposition-type action, such as "fileinto" or "redirect", is
Therefore, the sequence "convert, fileinto, convert" is the same as encountered, the state of the message with respect to conversions is
"convert, convert, fileinto": in both cases, all conversions are done "locked in" for that disposition-type action. Whether the
before the message is filed. implementation performs the action at that point or batches it for
later, it MUST perform the action on the message as it stood at the
time, and MUST NOT include subsequent conversions encountered later
in the script processing. Therefore, the sequence "convert,
fileinto, convert, fileinto" will store two different versions of the
message: the first "fileinto" uses only the first conversion, while
the second uses both. See Section 3.4 for an example of how this can
be used.
Repeating for emphasis: note that disposition-type actions, such as Convert actions are cumulative, and each conversion operates on the
"fileinto" and "redirect", will work on the converted message, filing message as it stands after all prior conversions. See the fourth
or redirecting it after all conversions are done. block of Section 3.4 for an example of how this might be tricky.
See Section 3.4 for an example of how this might be tricky. Because the implicit keep, if it is in effect, acts on the final
state of the message, all conversions are performed before any
implicit keep.
3. Examples 3. Examples
3.1. Example 1 3.1. Example 1
In the following example, all "image/tiff" body parts of the message In the following example, all "image/tiff" body parts of the message
are converted to "image/jpeg" with image resolution of 320x240 are converted to "image/jpeg" with image resolution of 320x240
pixels. The message is then subject to the implicit keep. pixels. The converted message is then subject to the implicit keep.
require ["convert"]; require ["convert"];
convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240";
3.2. Example 2 3.2. Example 2
In the following example, all "image/tiff" body parts of the message In the following example, all "image/tiff" body parts of the message
are converted to "image/jpeg", as in Example 1. Those messages are are converted to "image/jpeg", as in Example 1. Those messages are
then filed into a mailbox called "INBOX.pics". Other messages (those then filed into a mailbox called "INBOX.pics". Other messages (those
with no image/tiff body parts) are subject to the implicit keep. with no image/tiff body parts) are subject to the implicit keep, and
have not been converted.
require ["mime", "fileinto", "convert"]; require ["mime", "fileinto", "convert"];
if header :mime :anychild :contenttype if header :mime :anychild :contenttype
"Content-Type" "image/tiff" "Content-Type" "image/tiff"
{ {
convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240";
fileinto "INBOX.pics"; fileinto "INBOX.pics";
} }
3.3. Example 3 3.3. Example 3
In the following example, only "image/tiff" body parts with a In the following example, only "image/tiff" body parts with a
Content-Disposition of "inline" are converted. Matching parts that Content-Disposition of "inline" are converted. Matching parts that
are larger than 500 kilobytes are converted using an image resolution are larger than 500 kilobytes are converted using an image resolution
of 640x480 pixels, and those smaller are converted to 320x240 pixels. of 640x480 pixels, and those smaller are converted to 320x240 pixels.
The message disposition is not changed, so the implicit keep will be The message disposition is not changed, so the implicit keep will be
in effect unless something else in the script changes that. in effect unless something else in the script changes that.
skipping to change at page 6, line 9 skipping to change at page 6, line 14
3.4. Example 4 3.4. Example 4
The following example shows some tricky interactions between multiple The following example shows some tricky interactions between multiple
"convert" actions and other disposition-type actions. "convert" actions and other disposition-type actions.
require ["mime", "foreverypart", require ["mime", "foreverypart",
"fileinto", "redirect" "convert"]; "fileinto", "redirect" "convert"];
# The first "if" block will convert all image/tiff body parts # The first "if" block will convert all image/tiff body parts
# to 640x480 jpegs, and will register the message to be filed # to 640x480 jpegs, and will file the message
# into the "INBOX.pics" mailbox. But the rest of the script # into the "INBOX.pics" mailbox as converted at this point.
# will be run before the "fileinto" is done.
if header :mime :anychild :contenttype if header :mime :anychild :contenttype
"Content-Type" "image/tiff" "Content-Type" "image/tiff"
{ {
convert "image/tiff" "image/jpeg" "pix-x" "640" "pix-y" "480"; convert "image/tiff" "image/jpeg" "pix-x" "640" "pix-y" "480";
fileinto "INBOX.pics"; fileinto "INBOX.pics";
} }
# The second block, the "foreverypart" loop, will convert all # The second block, the "foreverypart" loop, will convert all
# inline jpegs to 320x240 resolution... including any tiff body # inline jpegs to 320x240 resolution... including any tiff body
# parts that had been converted in the first block, above. # parts that had been converted in the first block, above.
skipping to change at page 6, line 35 skipping to change at page 6, line 39
foreverypart foreverypart
{ {
if header :mime :param "filename" :contains if header :mime :param "filename" :contains
"Content-Disposition" "inline" "Content-Disposition" "inline"
{ {
convert "image/jpeg" "image/jpeg" convert "image/jpeg" "image/jpeg"
"pix-x" "320" "pix-y" "240"; "pix-x" "320" "pix-y" "240";
} }
} }
# The third block will redirect the message to Joe if it # The third block will take any message that contains a header
# field called "Mobile-Link" and redirect it to the user's
# mobile address. The redirected message will include both
# conversions above, from block one and block two.
if exists "Mobile-Link"
{
redirect "joe@mobile.example.com";
}
# The fourth block will file the message into "Tiff" if it
# contains any tiff body parts. But because of the earlier # contains any tiff body parts. But because of the earlier
# conversion (in the first block), there will never be any # conversion (in the first block), there will never be any
# tiff body parts, so the message will never be redirected. # tiff body parts, so this "fileinto" will never happen.
if header :mime :anychild :contenttype if header :mime :anychild :contenttype
"Content-Type" "image/tiff" "Content-Type" "image/tiff"
{ {
redirect "joe@example.com"; fileinto "Tiff";
} }
# Now, at the end of the script processing, after all # Now, at the end of the script processing, the Sieve
# conversions, the message will be filed into "INBOX.pics" # processor will perform an implicit keep if none of
# if the first "if" block was taken, or will be implicitly # the "fileinto" and "redirect" actions were taken.
# kept if not. # The kept message will include any conversions that
# were done (that is, any from the second block).
4. Security Considerations 4. Security Considerations
Security considerations given in IMAP CONVERT [RFC5259] and Sieve Security considerations given in IMAP CONVERT [RFC5259] and Sieve
[RFC5228] are relevant to this document. There are no additional [RFC5228] are relevant to this document. There are no additional
security considerations resulting from combining the two. security considerations resulting from combining the two.
5. IANA Considerations 5. IANA Considerations
IANA is requested to add the following registration to the Sieve IANA is requested to add the following registration to the Sieve
 End of changes. 18 change blocks. 
28 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/