Network Working Group Internet Draft: Sieve -- IMAP flag Extension A. Melnikov Document: draft-melnikov-sieve-imapflags-02.txt Messaging Direct, Inc. Expires: 25 December 1999 25 June 1999 Sieve -- IMAP flag Extension Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Copyright Copyright (C) The Internet Society 1998. All Rights Reserved. Abstract Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a SIEVE interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords. Melnikov Expires December 1999 [Page 1]
Internet Draft Sieve -- IMAP flag Extension June 1999 0. Meta-information on this draft This information is intended to facilitate discussion. It will be removed when this document leaves the Internet-Draft stage. 0.1. Discussion This draft is intended to be compared with the Sieve mail filtering language, an Internet-Draft being discussed on the MTA Filters mailing list at <ietf-mta-filters@imc.org>. Subscription requests can be sent to <ietf-mta-filters-request@imc.org> (send an email message with the word "subscribe" in the body). More information on the mailing list along with a WWW archive of back messages is available at <http://www.imc.org/ietf-mta-filters/>. 0.2. Changes from the version submitted to the SIEVE mailing list 1. Added addflag and removeflag actions 2. Changed the semantics of setflag (setflag is not additive any more) 3. Corrected section "Interaction with Other Sieve Actions". Removed incorrect reference to the forward action as to an action that prohibits setflag. 4. Added paragraph about the mutual order of fileinto/keep and setflag/addflag/removeflag actions. 0.3. Changes from the revision 00 1. Corrected Capability Identifier section (Section 2) 2. Corrected "Interaction with Other Sieve Actions" section (Section 4) 3. Examples were updated to be compatible with Sieve-07 draft 4. Added "mark" and "unmark" actions 0.4. Changes from the revision 01 1. Some language fixes based on Tony Hansen comments 2. Clarified that the extension allows to set both IMAP System Flags and Keywords Melnikov Expires December 1999 [Page 2]
Internet Draft Sieve -- IMAP flag Extension June 1999 1. Introduction This is an extension to the Sieve language defined by [SIEVE] for setting [IMAP] flags. It defines several new actions "setflag", "addflag", "removeflag", "mark" and "unmark". This document doesn't dictate how the SIEVE interpreter will set the [IMAP] flags. In particular, the SIEVE interpreter may work as an IMAP client, or may have direct access to the mailstore. SIEVE interpreters that don't support integration with IMAP SHOULD ignore this extension. Conventions for notations are as in [SIEVE] section 1.1, including use of [KEYWORDS]. 2. Capability Identifier The capability string associated with extension defined in this document is "imapflags". 3. Actions 3.1. Setflag Action Syntax: setflag <list-of-flags> Setflag is used for setting [IMAP] flags. Setflag replaces any previously set flags. It should be used together with keep or fileinto. It MUST be ignored if mailstore doesn't support the storing of any flags. Flags can be set only for the message that is currently being processed by SIEVE. When called with keep, setflag sets flags in the user's main mailbox. When called with fileinto, setflag sets flags in the mailbox indicated by the parameter. The order of setflag/fileinto or setflag/keep is important in the script. Any setflag action applies only to subsequent fileinto/keep actions. Server MUST ignore all flags that it can't store permanently. This means, in particular, that if the user's main mailbox can't store any flags, then the following SIEVE script produces no actions Example: if size over 500K setflag "\Deleted"; A more substantial example is: Example: if header :contains "from" "boss@frobnitzm.edu" { setflag "\Flagged"; fileinto "INBOX.From Boss"; } Melnikov Expires December 1999 [Page 3]
Internet Draft Sieve -- IMAP flag Extension June 1999 3.2. Addflag action Syntax: addflag <list-of-flags> Addflag is used for setting [IMAP] flags. However unlike setflag it doesn't replace any previously set flags. This means that multiple occurrences of addflag are treated additively. For example, the following two actions addflag "\Deleted"; addflag "\Answered"; produce the same result as the single action addflag ["\Deleted", "\Answered"]; In all other respects addflag behaves the same way as setflag. 3.3. Removeflag Action Syntax: removeflag <list-of-flags> Removeflag is used for setting [IMAP] flags. Removeflag clears flags previously set by setflag/addflag. Calling removeflag with a flag that wasn't set before is not an error and is ignored. In all other respects removeflag behaves the same way as setflag. Example: if header :contains "Disposition-Notification-To" "mel@example.com" { addflag "$MDNRequired"; } if header :contains "from" "imap@cac.washington.edu" { removeflag "$MDNRequired"; fileinto "INBOX.imap-list"; } 3.4. Mark and Unmark Actions Syntax: mark Syntax: unmark Melnikov Expires December 1999 [Page 4]
Internet Draft Sieve -- IMAP flag Extension June 1999 The mark action allows a message to be marked as urgent. Implementers are free to choose any flag or any combination of [IMAP] flags, however it is RECOMMENDED that the [IMAP] \Flagged flag be used. The mark action is semantically equivalent to 'addflag "\Flagged"'. The unmark action allows the flag previously set by the Mark action to be unset. Unmark SHOULD at least clear the [IMAP] \Flagged flag. Unmark MAY clear other flags as well. The unmark action is semantically equivalent to 'removeflag "\Flagged"'. 4. Interaction with Other Sieve Actions Sieve actions sometimes prohibit each other in order to make filtering scripts less likely to cause serious problems. It is strongly discouraged to use setflag/addflag/removeflag/mark/unmark actions together with reject, because that action doesn't allow keeping a received message. The SIEVE interpreter MUST ignore any setflag/addflag/removeflag/mark/unmark commands when they are used with reject. The SIEVE interpreter MUST ignore these commands when no keep (implicit or explicit) or fileinto actions will be taken. A SIEVE verifier SHOULD reject a script that contains a setflag/addflag/removeflag/mark/unmark action together with reject. 5. Other Considerations This extension intentionally doesn't allow setting [IMAP] flags on an arbitrary message in the [IMAP] message store. 6. Security Considerations Security considerations are discussed in the [IMAP] and [SIEVE]. It is belived that this extension doesn't introduce any additional security concerns. 7. Formal Grammar The grammar used in this section is the same as the ABNF described in [ABNF]. action =/ setflag / addflag / removeflag / mark / unmark setflag = "setflag" WSP string-list ;; a list of [IMAP] flags Melnikov Expires December 1999 [Page 5]
Internet Draft Sieve -- IMAP flag Extension June 1999 addflag = "addflag" WSP string-list ;; a list of [IMAP] flags removeflag = "removeflag" WSP string-list ;; a list of [IMAP] flags mark = "mark" unmark = "unmark" 8. Acknowledgments This document has been revised in part based on comments and 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 suggestions is appreciated, especially that of Tim Showalter, Barry Leiba, and Randall Gellens. Special thanks to Tony Hansen for helping with English language nuances. 9. Author's Address Alexey Melnikov Messaging Direct, Inc. Home address : 121293, Russia, Moscow, general Ermolov street, 6 - 90 Email: alexey.melnikov@messagingdirect.com Fax (San Diego, CA) : 1 (619) 8393837 Appendices Appendix A. References [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Carnegie Mellon, Work in Progress. [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 Requirement Levels", Harvard University, RFC 2119, March 1997. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", University of Washington, RFC 2060, December 1996. Melnikov Expires December 1999 [Page 6]
Internet Draft Sieve -- IMAP flag Extension June 1999 Appendix B. Full Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Melnikov Expires December 1999 [Page 7]