draft-ietf-sieve-imapflags-01.txt   draft-ietf-sieve-imapflags-02.txt 
Network Working Group Network Working Group
Internet Draft: Sieve -- IMAP flag Extension A. Melnikov Internet Draft: Sieve -- IMAP flag Extension A. Melnikov
Document: draft-ietf-sieve-imapflags-01.txt Isode Limited Document: draft-ietf-sieve-imapflags-02.txt Isode Limited
Expires: November 2005 May 2005 Expires: April 2006 October 2005
Sieve Mail Filtering Language: IMAP flag Extension Sieve Mail Filtering Language: IMAP flag Extension
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at line 37 skipping to change at line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
The protocol discussed in this document is experimental and subject The protocol discussed in this document is experimental and subject
to change. Persons planning on either implementing or using this to change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before protocol are STRONGLY URGED to get in touch with the author before
embarking on such a project. embarking on such a project.
Copyright Copyright
Copyright (C) The Internet Society 2000-2005. All Rights Reserved. Copyright (C) The Internet Society 2005. All Rights Reserved.
Abstract Abstract
Recent discussions have shown that it is desirable to set different Recent discussions have shown that it is desirable to set different
[IMAP] flags on message delivery. This can be done, for example, [IMAP] flags on message delivery. This can be done, for example,
by a Sieve interpreter that works as a part of a Mail Delivery by a Sieve interpreter that works as a part of a Mail Delivery
Agent. Agent.
This document describes an extension to the Sieve mail filtering This document describes an extension to the Sieve mail filtering
language for setting [IMAP] flags. The extension allows to set both language for setting [IMAP] flags. The extension allows to set both
[IMAP] system flags and [IMAP] keywords. [IMAP] system flags and [IMAP] keywords.
0. Meta-information on this draft 0. Meta-information on this draft
This information is intended to facilitate discussion. It will be This information is intended to facilitate discussion. It will be
removed when this document leaves the Internet-Draft stage. removed when this document leaves the Internet-Draft stage.
Editorial comments are marked with << and >>.
0.1. Discussion 0.1. Discussion
This draft defines an extension to the Sieve mail filtering This draft defines an extension to the Sieve mail filtering
language (RFC 3028) being discussed on the MTA Filters language (RFC 3028) being discussed on the MTA Filters
mailing list at <ietf-mta-filters@imc.org>. Subscription requests mailing list at <ietf-mta-filters@imc.org>. Subscription requests
can be sent to <ietf-mta-filters-request@imc.org> (send an email can be sent to <ietf-mta-filters-request@imc.org> (send an email
message with the word "subscribe" in the body). More information on message with the word "subscribe" in the body). More information on
the mailing list along with a WWW archive of back messages is the mailing list along with a WWW archive of back messages is
available at <http://www.imc.org/ietf-mta-filters/>. available at <http://www.imc.org/ietf-mta-filters/>.
skipping to change at line 167 skipping to change at line 165
0.10. Changes from draft-ietf-sieve-imapflags-00.txt 0.10. Changes from draft-ietf-sieve-imapflags-00.txt
1. Added back the internal variable, made the variable parameter to all 1. Added back the internal variable, made the variable parameter to all
actions optional. actions optional.
2. Some editorial suggestions from Mark E. Mallett. 2. Some editorial suggestions from Mark E. Mallett.
3. Updated boilerplate once again. 3. Updated boilerplate once again.
0.11. Changes from draft-ietf-sieve-imapflags-01.txt
1. Clarified that if "variables" is not available, then usage of
the explicit variable parameter causes a runtime error.
2. Clarified handling of spaces, in particular that leading/
trailing spaces in a flag variable are to be ignored.
3. Clarified that the extension can't be used to set the \Recent flag.
4. Made the variable list parameter to hasflag test optional, for
consistency with all actions.
5. Dropped the "Implementation Notes" section.
6. Fixed an error in section 5: when the :flags tagged argument is not
specified, the correct behavior is to use flags from the internal
variable.
7. Other minor editorial changes.
1. Introduction 1. Introduction
This is an extension to the Sieve language defined by [SIEVE] for This is an extension to the Sieve language defined by [SIEVE] for
setting [IMAP] flags. It adds a new tagged argument to "keep" and setting [IMAP] flags. It adds a new tagged argument to "keep" and
"fileinto" that describes the list of flags that have to be set "fileinto" that describes the list of flags that have to be set
when the message is delivered to the specified mailbox. It also when the message is delivered to the specified mailbox. It also
adds several actions to help manipulate list of flags and a test adds several actions to help manipulate list of flags and a test
to check if a flag belongs to a list. to check if a flag belongs to a list.
Sieve interpreters that don't support integration with IMAP SHOULD Sieve interpreters that don't support integration with IMAP SHOULD
ignore this extension. ignore this extension.
The capability string associated with extension defined in this The capability string associated with extension defined in this
document is "imap4flags". document is "imap4flags".
<<Extension name has been changed as revision 03 of this document is widely
deployed in CMU Cyrus server>>
The "imap4flags" extension can be used with or without the "variables" The "imap4flags" extension can be used with or without the "variables"
extension [Variables]. When the "variables" extension is also present extension [VARIABLES]. When the "variables" extension is enabled in
a script can use explicit variable names in setflag/addflag/removeflag a script using <require "variables">, the script can use explicit
actions. See also section 3 for more details. variable names in setflag/addflag/removeflag actions. See also section
When the "variables" extension is not present the explicit variable name 3 for more details. When the "variables" extension is not enabled
parameter to setflag/addflag/removeflag MUST NOT be used. the explicit variable name parameter to setflag/addflag/removeflag
MUST NOT be used and MUST cause an error according to [SIEVE].
2. Conventions used. 2. Conventions used.
Conventions for notations are as in [SIEVE] section 1.1, including Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS] and "Syntax:" label for the definition of action use of [KEYWORDS] and "Syntax:" label for the definition of action
and tagged arguments syntax. and tagged arguments syntax.
2.1. General requirements for flag handling 2.1. General requirements for flag handling
The following notes apply to processing of Addflag and Removeflag actions, The following notes apply to processing of Addflag and Removeflag actions,
hasflag test and :flags tagged argument. hasflag test and :flags tagged argument.
A Sieve interpreter MUST ignore empty strings (i.e. "") in a list-of-flags A Sieve interpreter MUST ignore empty strings (i.e. "") in a list-of-flags
parameter. parameter.
The Sieve interpreter SHOULD check the list of flags for validity as The Sieve interpreter SHOULD check the list of flags for validity as
described by [IMAP] ABNF. In particular non-ASCII characters are not described by [IMAP] ABNF. In particular non-ASCII characters are not
allowed in flag names. However spaces MUST be always allowed and multiple allowed in flag names. However spaces MUST be always allowed. Multiple
spaces between flag names MUST be treated as a single space character. spaces between flag names MUST be treated as a single space character,
leading and trailing spaces MUST be ignored.
A string containing a space-separated list of flags is equivalent to a A string containing a space-separated list of flags is equivalent to a
string list consisting of the flags. The last requirement is to simplify string list consisting of the flags. The last requirement is to simplify
amalgamation of multiple flag lists. amalgamation of multiple flag lists.
If a flag validity check fails the flag should be silently If a flag validity check fails the flag MUST be ignored.
ignored, but a warning message SHOULD be logged by the Sieve interpreter.
Note that it is not possible to use this extension to set or clear the
\Recent flag or any other special system flag which is not settable
in [IMAP]. Any such flags MUST be ignored if included in a flag list.
3. Actions 3. Actions
All actions described in this specification (setflag, addflag, removeflag) All actions described in this specification (setflag, addflag, removeflag)
operate on string variables that contain a set of [IMAP] flags. operate on string variables that contain a set of [IMAP] flags.
On variable substitution a set of flags is represented as a string On variable substitution a set of flags is represented as a string
containing space-separated list of flag names. containing space-separated list of flag names.
<<Should this cause an automatic duplicate elimination?>>
Any of setflag/addflag/removeflag action MAY alter the flag list in any
way that leaves its semantics as a set of case-insensitive words unaltered.
For example, it may reorder the flags, alter the case of the letters in
them, or add or remove duplicates or extraneous spaces. Scripts
MUST NOT make assumptions about the ordering of flags in lists or
the preservation of their case.
Note that the parameter specifying a variable name to setflag/addflag/ Note that the parameter specifying a variable name to setflag/addflag/
removeflag actions is optional. If the parameter is not specified removeflag actions and the hasflag test is optional. If the parameter
the actions operate on the internal variable, which has the empty is not specified the actions operate on the internal variable, which
value when the script starts execution. If the SIEVE interpreter doesn't has the empty value when the script starts execution. If the SIEVE
support the "variables" extension [Variables], the present variable interpreter doesn't support the "variables" extension [VARIABLES],
name parameter MUST cause runtime error. the present variable name parameter MUST cause runtime error.
The "addflag" action adds flags to an existing set. The "removeflag" The "addflag" action adds flags to an existing set. The "removeflag"
action removes flags from an existing set. The "setflag" action action removes flags from an existing set. The "setflag" action
replaces an existing set of flags with a new set. The "set" action replaces an existing set of flags with a new set. The "set" action
defined in [Variables] can be used to replace an existing set of flags defined in [VARIABLES] can be used to replace an existing set of flags
with a new set as well. with a new set as well. However it should be noted that the "set"
action can't perform any flag reordering, duplicate elimination, etc.
The :flags tagged argument to "keep" and "fileinto" The :flags tagged argument to "keep" and "fileinto"
actions is used to associate a set of flags referenced by a variable actions is used to associate a set of flags referenced by a variable
with the current message. If the :flags tagged argument is not specified with the current message. If the :flags tagged argument is not specified
with those 2 actions, the current value of the internal variable is used with those 2 actions, the current value of the internal variable is used
instead. The value also applies to the implicit keep. instead. The value also applies to the implicit keep.
<<When keep/fileinto is used multiple times and duplicate elimination Note that when keep/fileinto is used multiple times in a script and
is used, the last flag value wins.>> duplicate message elimination is performed, the last flag list value MUST
win.
3.1. Setflag Action 3.1. Setflag Action
Syntax: setflag [<variablename: string>] <list-of-flags: string-list> Syntax: setflag [<variablename: string>] <list-of-flags: string-list>
Setflag is used for setting [IMAP] system flags or keywords. Setflag is used for setting [IMAP] system flags or keywords.
Setflag replaces any previously set flags. Setflag replaces any previously set flags.
Example: if size :over 500K { Example: if size :over 500K {
setflag "flags" "\\Deleted"; setflag "flags" "\\Deleted";
skipping to change at line 272 skipping to change at line 301
setflag "flagvar" "\\Flagged"; setflag "flagvar" "\\Flagged";
fileinto :flags "${flagvar}" "INBOX.From Boss"; fileinto :flags "${flagvar}" "INBOX.From Boss";
} }
3.2. Addflag action 3.2. Addflag action
Syntax: addflag [<variablename: string>] <list-of-flags: string-list> Syntax: addflag [<variablename: string>] <list-of-flags: string-list>
Addflag is used to add flags to a list of [IMAP] flags. It doesn't Addflag is used to add flags to a list of [IMAP] flags. It doesn't
replace any previously set flags. This means that multiple occurrences replace any previously set flags. This means that multiple occurrences
of addflag are treated additively. The order of the flags MAY NOT of addflag are treated additively.
be preserved and duplicates are allowed.
The following examples demonstrate requirements described in 2.1. The following examples demonstrate requirements described in 2.1.
The following two actions The following two actions
addflag "flagvar" "\\Deleted"; addflag "flagvar" "\\Deleted";
addflag "flagvar" "\\Answered"; addflag "flagvar" "\\Answered";
produce the same result as the single action produce the same result as the single action
addflag "flagvar" ["\\Deleted", "\\Answered"]; addflag "flagvar" ["\\Deleted", "\\Answered"];
skipping to change at line 319 skipping to change at line 347
addflag "flagvar" "$MDNRequired"; addflag "flagvar" "$MDNRequired";
} }
if header :contains "from" "imap@cac.washington.example.edu" { if header :contains "from" "imap@cac.washington.example.edu" {
removeflag "flagvar" "$MDNRequired"; removeflag "flagvar" "$MDNRequired";
fileinto :flags "${flagvar}" "INBOX.imap-list"; fileinto :flags "${flagvar}" "INBOX.imap-list";
} }
4. Test hasflag 4. Test hasflag
Syntax: hasflag [MATCH-TYPE] Syntax: hasflag [MATCH-TYPE]
<variable-list: string-list> <list-of-flags: string-list> [<variable-list: string-list>] <list-of-flags: string-list>
The "hasflag" test evaluates to true if any of the variables matches any The "hasflag" test evaluates to true if any of the variables matches any
flag name. The type of match defaults to ":is". flag name. The type of match defaults to ":is".
If the list of variables is omitted, value of the internal variable is
used instead.
Flagname comparisons is always done with the "i;ascii-casemap" operator, Flagname comparisons is always done with the "i;ascii-casemap" operator,
i.e., case-insensitive comparisons, as defined in [IMAP]. i.e., case-insensitive comparisons, as defined in [IMAP].
Note, that if an implementation automatically performs flags reordering Example:
and/or duplicate elimination, it MUST perform it on both variable-list If the variable "MyFlags" has the value "A B", the following test
values and flag-list values. This is required so that, when the variable
"MyFlags" has the value "A B", the following test
hasflag :is "MyFlags" "b A" hasflag :is "MyFlags" "b A"
evaluates to true as expected. The above test can be also written as evaluates to true. The above test can be also written as
hasflag "MyFlags" ["b","A"] hasflag "MyFlags" ["b","A"]
5. Tagged argument :flags 5. Tagged argument :flags
This specification adds a new optional tagged argument ":flags" that This specification adds a new optional tagged argument ":flags" that
alter the behavior of actions "keep" and "fileinto". alter the behavior of actions "keep" and "fileinto".
The :flags tagged argument specifies that the flags provided in the The :flags tagged argument specifies that the flags provided in the
subsequent argument should be set when fileinto/keep deliver the message subsequent argument should be set when fileinto/keep deliver the message
to the target mailbox/user's main mailbox. If the :flags tagged argument to the target mailbox/user's main mailbox. If the :flags tagged argument
is not specified, "keep" or "fileinto" will not set any flag when they is not specified, "keep" or "fileinto" will use the current value of the
deliver the message to the mailbox. internal variable when delivering message to the target mailbox.
Syntax: ":flags" <list-of-flags: string-list> Syntax: ":flags" <list-of-flags: string-list>
The copy of the message filed into mailbox will have only flags The copy of the message filed into mailbox will have only flags
listed after ":flags". listed after ":flags".
The Sieve interpreter MUST ignore all flags that it can't store The Sieve interpreter MUST ignore all flags that it can't store
permanently. This means that the interpreter must not treat failure permanently. This means that the interpreter must not treat failure
to store any flag as a runtime failure to execute the Sieve to store any flag as a runtime failure to execute the Sieve
script. For example, if the mailbox "INBOX.From Boss" can't store any script. For example, if the mailbox "INBOX.From Boss" can't store any
skipping to change at line 372 skipping to change at line 400
and and
fileinto "INBOX.From Boss"; fileinto "INBOX.From Boss";
are equivalent. are equivalent.
This document doesn't dictate how the Sieve interpreter will set This document doesn't dictate how the Sieve interpreter will set
the [IMAP] flags. In particular, the Sieve interpreter may work as the [IMAP] flags. In particular, the Sieve interpreter may work as
an IMAP client, or may have direct access to the mailstore. an IMAP client, or may have direct access to the mailstore.
6. Implementation Notes 6. Interaction with Other Sieve Actions
"Addflag <variable> <flaglist>" can be implemented as several actions
"set <variable> "${variable} <flag>", where <flag> is a flag in flaglist.
A script interpreter MAY reorder flags and remove duplicates from the list.
Thus a SIEVE script writer MUST NOT assume that the order or duplicates
will be preserved.
A "hasflag <variable> <flag>" test can be implemented as follows:
string :matches :comparator "i;ascii-casemap"
" ${<variable>} " "* <flag> *"
"setflag <variable> [<flag1>,<flag2>,...]" can be implemented as
follows:
set <variable> "<flag1> <flag2> ... <flagN>"
"addflag <variable> <flag>" can be implemented as:
if not string :matches :comparator "i;ascii-casemap"
" ${<variable>} " "* <flag> *" {
set <variable> "${<variable>} <flag>"
}
"removeflag <variable> <flag>" can be implemented as:
if string :matches :comparator "i;ascii-casemap" " ${<variable>} "
"* <flag> *" {
set <variable> "${1} ${2}";
}
/* Remove any leading space */
if string :matches :comparator "i;ascii-casemap" "${<variable>}"
" *" {
set <variable> "${1}";
}
/* Remove any trailing space */
if string :matches :comparator "i;ascii-casemap" "${<variable>}"
"* " {
set <variable> "${1}";
}
7. Interaction with Other Sieve Actions
This extension work only on the message that is currently being This extension work only on the message that is currently being
processed by Sieve, it doesn't affect another message generated processed by Sieve, it doesn't affect another message generated
as a side affect of any action. as a side affect of any action.
The extension decribed in this document doesn't change the implicit The extension decribed in this document doesn't change the implicit
keep (see section 2.10.2 of [SIEVE]). keep (see section 2.10.2 of [SIEVE]).
8. Other Considerations 7. Other Considerations
This extension intentionally doesn't allow setting [IMAP] flags on This extension intentionally doesn't allow setting [IMAP] flags on
an arbitrary message in the [IMAP] message store. an arbitrary message in the [IMAP] message store.
9. Security Considerations 8. Security Considerations
Security considerations are discussed in the [IMAP], [SIEVE] and Security considerations are discussed in the [IMAP], [SIEVE] and
[Variables]. [VARIABLES].
It is belived that this extension doesn't introduce any additional It is believed that this extension doesn't introduce any additional
security concerns. security concerns.
10. Extended example 9. Extended example
# #
# Example Sieve Filter # Example Sieve Filter
# Declare any optional features or extension used by the script # Declare any optional features or extension used by the script
# #
require ["fileinto", "imap4flags", "variables"]; require ["fileinto", "imap4flags", "variables"];
# #
# Move large messages to special mailbox # Move large messages to special mailbox
# #
skipping to change at line 508 skipping to change at line 493
# it's from a list. # it's from a list.
fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder
} }
else else
{ {
# Move all other external mail to "personal" # Move all other external mail to "personal"
# folder. # folder.
fileinto :flags "${MyFlags}" "personal"; fileinto :flags "${MyFlags}" "personal";
} }
11. Acknowledgments 10. Acknowledgments
This document has been revised in part based on comments and This document has been revised in part based on comments and
discussions which took place on and off the Sieve mailing list. discussions which took place on and off the Sieve mailing list.
The help of those who took the time to review the draft and make The help of those who took the time to review the draft and make
suggestions is appreciated, especially that of Tim Showalter, suggestions is appreciated, especially that of Tim Showalter,
Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo,
Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson,
Kjetil Torgrim Homme and Mark E. Mallett. Kjetil Torgrim Homme, Mark E. Mallett, Dave Cridland,
Arnt Gulbrandsen and Philip Guenther.
Special thanks to Tony Hansen and David Lamb for helping me Special thanks to Tony Hansen and David Lamb for helping me
better explain the concept. better explain the concept.
12. Author's Address 11. Author's Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
Hampton, Middlesex Hampton, Middlesex
United Kingdom, TW12 2BX United Kingdom, TW12 2BX
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
13. Normative References 12. Normative References
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint,
RFC 3028, January 2001. RFC 3028, January 2001.
[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
Internet Mail Consortium, RFC 2234, November, 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Harvard University, RFC 2119, March 1997. Requirement Levels", Harvard University, RFC 2119, March 1997.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
University of Washington, RFC 3501, March 2003. University of Washington, RFC 3501, March 2003.
[Variables] Homme, K. T., "Sieve -- Variables Extension", University of [VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University of
Oslo, work in progress, draft-ietf-sieve-variables-XX.txt Oslo, work in progress, draft-ietf-sieve-variables-XX.txt
14. Intellectual Property Statement 13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at line 574 skipping to change at line 557
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
15. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 End of changes. 31 change blocks. 
96 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/