datatracker.ietf.org
Sign in
Version 5.3.1, 2014-04-16
Report a bug

Sieve Email Filtering: Imap4flags Extension
RFC 5232

Document type: RFC - Proposed Standard (January 2008)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5232 (Proposed Standard)
Responsible AD: Lisa Dusseault
Send notices to: sieve-chairs@tools.ietf.org

Network Working Group                                       A.  Melnikov
Request for Comments: 5232                                 Isode Limited
Category: Standards Track                                   January 2008

              Sieve Email Filtering: Imap4flags Extension

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   Recent discussions have shown that it is desirable to set different
   IMAP (RFC 3501) 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 setting of
   both IMAP system flags and IMAP keywords.

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used ...........................................2
   2. General Requirements for Flag Handling ..........................3
   3. Actions .........................................................3
      3.1. Action setflag .............................................4
      3.2. Action addflag .............................................4
      3.3. Action removeflag ..........................................5
   4. Test hasflag ....................................................6
   5. Tagged Argument :flags ..........................................7
   6. Interaction with Other Sieve Actions ............................8
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................8
   9. Extended Example ................................................8
   10. Acknowledgments ...............................................10
   11. Normative References ..........................................10

Melnikov                    Standards Track                     [Page 1]
RFC 5232              Sieve: Imap4flags Extension           January 2008

1.  Introduction

   This is an extension to the Sieve language defined by [SIEVE] for
   setting [IMAP] flags.  It adds a new tagged argument to "keep" and
   "fileinto" that describes the list of flags that have to be set when
   the message is delivered to the specified mailbox.  It also adds
   several actions to help manipulate list of flags and a test to check
   whether a flag belongs to a list.

   From the user's perspective, this extension provides several
   capabilities.  First, it allows manipulation of sets of IMAP flags.
   Second, it gives the ability to associate a set of IMAP flags with a
   message that is delivered to a mailstore using the keep/fileinto
   actions.  Third, it maintains an internal variable.  The internal
   variable contains the default flags that will be associated with a
   message that is delivered using the keep, implicit keep, or fileinto
   actions, when the :flags tagged argument is not specified.  When the
   Sieve [VARIABLES] extension is also supported by the Sieve engine, it
   enables support for multiple variables containing sets of IMAP flags.

   The capability string associated with the extension defined in this
   document is "imap4flags".  All conformant implementations MUST
   implement all Sieve actions (setflag, addflag, removeflag), the
   "hasflag" test, and the ":flags" tagged argument described in this
   document.

   The "imap4flags" extension can be used with or without the
   "variables" extension [VARIABLES].  When the "variables" extension is
   enabled in a script using <require "variables">, the script can use
   explicit variable names in setflag/addflag/removeflag actions and the
   hasflag test.  See also Section 3 for more details.  When the
   "variables" extension is not enabled, the explicit variable name
   parameter to setflag/addflag/removeflag/hasflag MUST NOT be used and
   MUST cause an error according to [SIEVE].

1.1.  Conventions Used

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

[include full document text]