[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 draft-ietf-sieve-imapflags

Network Working Group
Internet Draft: Sieve -- IMAP flag Extension                 A. Melnikov
Document: draft-melnikov-sieve-imapflags-04.txt   Messaging Direct, Ltd.
Expires: April 2001                                         October 2000


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


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. Open issues

   1. Do we want to use special actions that work with global state or use optional tagged arguments?
      Allow both? Currently the draft allows both models.

   2. If we decide to keep both, what "keep"/"fileinto" without tagged arguments means: don't set any flags
      or use global flags? I would rather ignore flags completely to keep current "keep"/"fileinto" behavior.
      This breaks backward compatibility with the previous draft and if this is a big concern it can be addressed
      in the next revision of the draft.

   3. Add example that describes why implicit way is useful?

   4. Should the document repeat when describing flag manipulation actions that they have no affect
      if non of ":globalflags", ":globalflags_plus" or ":globalflags_minus" is specified?

   5. ":globalflags_plus" and ":globalflags_minus" names are ugly. Suggestions are welcome.


0.3. To be done

      Text will be reworked not to reference "internal variable".


0.4. 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.5. 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.6. 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


0.7. Changes from the revision 02

   1. BugFix: all backslashes must be escaped

   2. Added extended example and more detailed description of "addflag"/"removeflag" additivity.

   3. Minor example bugfixes


0.8. Changes from the revision 03

   1. Added second way to specify flags to be set (via optional tagged arguments). [Tim Showalter]

   2. Rules for using Reject with imapflags relaxed. [Randall Gellens]

   3. Removed ABNF section completely, added syntax description to action definition. [Tim Showalter]

   4. Cleaned up the example. [Ken Murchison]

   5. Added [FM] acronym (Flag Manupulation)

   6. Clarified "mark"/"unmark" bahavior. [Randall Gellens}


1. Introduction

   This is  an  extension to the Sieve language defined by [SIEVE] for
   setting [IMAP] flags.  There are two major ways to specify which flags should
   be set: explicit, that lists flags using tagged argument for "keep" and
   "fileinto" and implicit, that uses actions that work with the global state
   ("setflag", "addflag", "removeflag", "mark" and "unmark"). There is also possible
   to combine the advantages of both ways. The first approach is described in section 4.
   The second is described in the sections 3 and 4.

   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.

2. Conventions used.

   Conventions for notations are as in [SIEVE] section 1.1,  including
   use of [KEYWORDS] and "Syntax:" label for the definition of action and tagged arguments syntax.

   Global flags are those that are set by "setflag"/"addflag"/"removeflag"/"mark"/"unmark" actions.

   "[FM]" (Flag Manipulation) acronym references any of "setflag"/"addflag"/"removeflag"/"mark"/"unmark"
   actions.

   The capability string associated with extension defined in this document
   is "imapflags".


3. Actions

   All actions described in this specification (setflag, addflag, removeflag,
   mark, unmark) operate on an internal variable that contains the set of [IMAP] flags
   associated with the message being delivered. When the interpreter starts executing
   a script this variable contains an empty set. The "addflag" action adds flags
   to the existing set. The "removeflag" action removes flags from the existing set.
   The "setflag" action replaces the existing set of flags with a new set.
   Whenever the interpreter encounters a "fileinto" or "keep" action it files
   the message with the current set of flags.


3.1. Setflag Action

   Syntax:   setflag <list-of-flags: string-list>

   Setflag is used for setting  [IMAP]  system flags or keywords. Setflag
   replaces  any previously  set  flags.  It  should  be  used together with "keep"
   or "fileinto".  It MUST be ignored  if  mailstore or target mailbox 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 all subsequent "fileinto"/"keep"
   actions in a script till next occurence of [FM] action.

   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 :globalflags "INBOX.From Boss";
        }


3.2. Addflag action

   Syntax:   addflag <list-of-flags: string-list>

   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: string-list>

   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.
   Multiple occurrences of removeflag are treated additively.

   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 :globalflags "INBOX.imap-list";
        }


3.4. Mark and Unmark Actions

   Syntax:   mark

   Syntax:   unmark

   The mark action allows a message to be marked as urgent. Conformant implementation MUST
   set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well. Thus 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 MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark.
   Unmark MUST NOT unset any other flags. This means that the following script does nothing:

      mark;
      unmark;

   The unmark action is semantically equivalent to 'removeflag "\\Flagged"'.


4. Tagged arguments

   This specification adds several optional tagged arguments that alter the behavior of actions
   "keep" and "fileinto". Only one of the following 4 tagged arguments can be used with "keep" or
   "fileinto". They specify that some flag or combination of flags should be set when they deliver
   the message to the target mailbox. If non of the 4 following tagged arguments is specified,
   "keep" or "fileinto" will not set any flag when they deliver the message to the mailbox.

   Syntax:   ":globalflags_plus" <list-of-flags: string-list>

   The copy of the message filed into mailbox will have both global flags and flags listed after
   ":globalflags_plus".


   Syntax:   ":globalflags_minus" <list-of-flags: string-list>

   The copy of the message filed into mailbox will have all global flag with exception of flags
   listed after ":globalflags_minus".


   Syntax:   ":globalflags"

   The copy of the message filed into mailbox will have only global flags.


   Syntax:   ":flags" <list-of-flags: string-list>

   The copy of the message filed into mailbox will have only flags listed after ":flags".
   Global flags set by any of [FM] actions are ignored.


5. Interaction with Other Sieve Actions

   Sieve actions sometimes  prohibit  each  other  in  order  to  make
   filtering scripts less likely to cause serious problems.

   The SIEVE interpreter  MUST  ignore any [FM]
   actions 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.

   If the script uses any of [FM] actions
   together with  reject a SIEVE verifier SHOULD warn the user using available means that
   the script contains actions that has no effect when used with reject.


6. Other Considerations

   This extension intentionally doesn't allow setting [IMAP] flags  on an
   arbitrary message in the [IMAP] message store.


7. Security Considerations

   Security considerations are discussed in the [IMAP] and [SIEVE].
   It is belived that this  extension  doesn't  introduce any
   additional security concerns.


8. Extended example

   #
   # Example Sieve Filter
   # Declare any optional features or extension used by the script
   #
   require ["fileinto", "imapflags"];

   #
   # Move large messages to special mailbox
   #
   if size :over 1M
           {
           addflag "$Big";
           if header :is "From" "boss@company.com"
                      {
   # The message will be marked as "\Flagged $Big" when filed into mailbox "Big messages"
                      addflag "\\Flagged";
                      }
           fileinto :globalflags "Big messages";
           }

   if header :is "From" "grandma@example.net"
           {
           addflag ["\\Answered", "$MDNSent"];
   # If the message is bigger than 1Mb it will be marked as "$Big \Answered $MDNSent"
   # when filed into mailbox "grandma". If the message is shorter than 1Mb it will be marked as
   # "\Answered $MDNSent"
           fileinto :globalflags "GrandMa";  # move to "GrandMa" folder
           }

   #
   # Handle messages from known mailing lists
   # Move messages from IETF filter discussion list to filter folder
   #
   if header :is "Sender" "owner-ietf-mta-filters@imc.org"
           {
           setflag "\\Flagged";
   # Message will always have just "\Flagged" flag
           keep :globalflags;
           }

   #
   # Keep all messages to or from people in my company
   #
   elsif anyof address :domain :is ["From", "To"] "company.com"
           {
           keep :globalflags;               # keep in "In" folder
           }
   #
   # Try and catch unsolicited email.  If a message is not to me,
   # or it contains a subject known to be spam, file it away.
   #
   elsif anyof (not address :all :contains
                  ["To", "Cc", "Bcc"] "me@company.com",
                header :matches "subject"
                  ["*make*money*fast*", "*university*dipl*mas*"])
           {
           removeflag "\\Flagged";
           # If message header does not contain my address,
           # it's from a list.
           fileinto :globalflags "spam";   # move to "spam" folder
           }
   else
           {
           # Move all other (non-company) mail to "personal"
           # folder.
           fileinto :globalflags "personal";
           }


9.  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, Randall Gellens, Ken Murchison and Cyrus Daboo.
    Special thanks to Tony Hansen, David Lamb and Roman Migal for helping
    me explain better the concept.


10. Author's Address

    Alexey Melnikov
    Messaging Direct, Ltd.

    Address : #900, 10117 Jasper Avenue, Edmonton, Alberta, Canada,
    T5J1W8

    Email: mel@messagingdirect.com


Appendices

Appendix A.  References

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language", Mirapoint,
   Work in Progress, draft-showalter-sieve-XX.txt

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


Appendix B. Full Copyright Statement

    Copyright (C) The Internet Society 2000. 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.


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/