Network Working Group
Internet Draft: Sieve -- IMAP flag Extension                 A. Melnikov
Document: draft-melnikov-sieve-imapflags-01.txt   Messaging Direct, Inc.
Expires: 19 December 1999                                   19 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

   The list of Internet-Draft Shadow Directories can be accessed at

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt''  listing  contained  in  the  Internet-Drafts
   Shadow   Directories   on   (Africa),
   (Europe), (Pacific Rim),  (US  East
   Coast), or (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 (C) The Internet Society 1998.  All Rights Reserved.


   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

   This document describes an extension to the  Sieve  mail  filtering
   language for setting [IMAP] flags.

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 <>.  Subscription  requests
   can  be  sent  to <> (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 <>.

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 version 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

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.

Melnikov                   Expires December 1999              [Page 2]

Internet Draft         Sieve -- IMAP flag Extension          June 1999

   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

   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 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

   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:

        if header :contains "from" "" {
          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 additive.

   For example, the following two actions

      addflag "\Deleted";
      addflag "\Answered";

   produce the same result as a single action

      addflag ["\Deleted", "\Answered"];

   In all other  respects  addflag  action  behave  the  same  way  as

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

        if header :contains "Disposition-Notification-To" "" {
          addflag "$MDNRequired";
        if header :contains "from" "" {
          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

   Mark action allows to mark message as urgent. Implementers are free
   to choose any flag or any  combination  of  flags,  however  it  is
   RECOMMENDED  that  IMAP  \Flagged  flag  is  used.  Mark  action is
   sematically equivalent to 'addflag "\Flagged"'.

   Unmark action allows to reset urgent flag previously  set  by  Mark
   action. Unmark SHOULD at least clear IMAP \Flagged flag. Unmark MAY
   clear other flags as well.  Unmark action is sematically 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
   actions together with reject,  because  this  action doesn't allow keeping
   received message.

   SIEVE interpreter  MUST  ignore any of setflag/addflag/removeflag commands,
   when they are used  with  reject. SIEVE interpreter MUST ignore these commands
   when no keep (implicit or explicit) or fileinto actions will be taken.

   SIEVE verifier SHOULD reject script, which contains setflag/addflag/removeflag
   together with  reject.

5. Other Considerations

   This extension intentionally doesn't allow setting [IMAP] flags  on
   arbitrary message in 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

   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 made
    suggestions is appreciated, especially that of Tim Showalter,
    Barry Leiba, and Randall Gellens.

9. Author's Address

    Alexey Melnikov
    Messaging Direct, Inc.

    Home address :
    121293, Russia, Moscow,
    general Ermolov street, 6 - 90


    Fax (San Diego, CA) : 1 (619) 8393837


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.

   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

    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

Melnikov                   Expires December 1999              [Page 7]