Network Working Group Internet Draft: Sieve -- IMAP flag Extension A. Melnikov Document: draft-melnikov-sieve-imapflags-00.txt Epsylon Technologies Expires: 16 May 1999 16 November 1998 Sieve -- IMAP flag Extension Status of this memo This document is an Internet-Draft. 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.'' 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 was desirable to set different [IMAP] flags on message delivery. This can be done, for example, by SIEVE interpreter that works as a part of Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. Melnikov Expires May 1999 [Page 1]
Internet Draft Sieve -- IMAP flag Extension November 1998 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. 1. Introduction This is an extension to the Sieve language defined by [SIEVE] for setting [IMAP] flags. It defines several new actions "setflag", "addflag" and "removeflag". This document doesn't dictate how SIEVE interpreter can set [IMAP] flags. In particular, SIEVE interpreter may work as an IMAP client, or may have direct access to the mailstore. SIEVE interpreters, that doesn'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 Sieve implementations that implement setflag action have an identifier of "IMAPFLAGS" for use with the capability mechanism. Melnikov Expires May 1999 [Page 2]
Internet Draft Sieve -- IMAP flag Extension November 1998 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 message that is currently processed by SIEVE. When called with keep, setflag sets flags in 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 mean, in particular, that if user's main mailbox can't store any flags, then the following SIEVE script produces no actions Example: if size over 500K setflag "\Deleted"; More substantial example is: Example: if header "from" contains "boss@frobnitzm.edu" { setflag "\Flagged"; fileinto "INBOX.From Boss"; } 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 additive. For example, the following two actions addflag "\Deleted"; addflag "\Answered"; Melnikov Expires May 1999 [Page 3]
Internet Draft Sieve -- IMAP flag Extension November 1998 produce the same result as a single action addflag ["\Deleted", "\Answered"]; In all other respects addflag action behave 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 action behave the same way as setflag. Example: if header ["Disposition-Notification-To"] :contains ["mel@example.com"] { addflag "$MDNRequired"; } if header ["from"] :contains ["imap@cac.washington.edu"] { removeflag "$MDNRequired"; fileinto "INBOX.imap-list"; } 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 actions together with reject and discard, because these actions don't allow keeping received message. SIEVE interpreter MUST ignore any of setflag/addflag/removeflag commands, when it is used with reject or discard (or similar). SIEVE verifier SHOULD reject script, which contains setflag/addflag/removeflag together with reject or discard (or similar). 5. Other Considerations This extension intentionally doesn't allow setting [IMAP] flags on arbitrary message in IMAP message store. Melnikov Expires May 1999 [Page 4]
Internet Draft Sieve -- IMAP flag Extension November 1998 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 setflag = "setflag" WSP string-list ;; a list of [IMAP] flags addflag = "addflag" WSP string-list ;; a list of [IMAP] flags removeflag = "removeflag" WSP string-list ;; a list of [IMAP] flags 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. 9. Author's Address Alexey Melnikov Epsylon Technologies Home address : 121293, Russia, Moscow, general Ermolov street, 6 - 90 Email: mel@taxxi.com Fax (San Diego, CA) : 1 (619) 8393837 Melnikov Expires May 1999 [Page 5]
Internet Draft Sieve -- IMAP flag Extension November 1998 Appendices Appendix A. References [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. [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Carnegie Mellon, Work in Progress. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", University of Washington, RFC 2060, December 1996. Appendix B. Full Copyright Statement Copyright (C) The Internet Society 1997. 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. Melnikov Expires May 1999 [Page 6]