Network Working Group                                    Alexey Melnikov
Document: draft-ietf-sieve-notify-01.txt                          Editor
Expires: April 2006                                         October 2005

         Sieve -- An extension for providing instant notifications

Status of this Memo

     By submitting this Internet-Draft, each author represents that any
     applicable patent or other IPR claims of which he or she is aware
     have been or will be disclosed, and any of which he or she becomes
     aware will be disclosed, in accordance with Section 6 of BCP 79.

     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-

     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

     The list of current Internet-Drafts can be accessed at

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

     Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).


    Users go to great lengths to be notified as quickly as possible that
    they have received new mail. Most of these methods involve polling
    to check for new messages periodically. A push method handled by the
    final delivery agent gives users quicker notifications and saves
    server resources. This document does not specify the notification
    method but is expected that using existing instant messaging
    infrastructure such as Zephyr, Jabber, or SMS messages will be popular.
    This draft describes an extension to the Sieve mail filtering
    language that allows users to give specific rules for how and when
    notifications should be sent.

1.  Introduction

    This is an extension to the Sieve language defined by [SIEVE] for
    providing instant notifications. It defines the new action "notify".

    This document does not dictate the notification method used.
    Examples of possible notification methods are Zephyr and Jabber. The
    available method shall be site-defined.

    Conventions for notations are as in [SIEVE] section 1.1, including
    use of [KEYWORDS].

1.1.  Conventions Used in This Document
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in [KEYWORDS].

2.  Capability Identifier

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

3.  Actions

3.1.  Notify action

    Usage:   notify [":method" string]
               [":id" string]
               [":priority" <"1" / "2" / "3">]
               [":message" string]

    The Notify action specifies that a notification should be sent to
    the user upon successful handling of this message.

    The format of the notification is implementation-defined and
    is also affected by the notification method used (see below). However,
    all content specified in the notify action SHOULD be included.
    It is RECOMMENDED that a timestamp is included in the notification.
    Implementations SHOULD NOT include extraneous information.

    The :method tag identifies the notification method that will be
    used, it is an URI. For examples, the notification method can
    be an SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP]
    URI containing Jabber identifier [XMPP-URI].
    If the :method tag is not specified, the default
    implementation defined notification method is used.  The
    possible values of this will be site-specific.  If an URI schema is
    specified that the implementation does not support, the notification
    MUST be ignored. An implementation may treat this as a warning
    condition (e.g. it may log a warning), however this is not
    a fatal error and execution of the SIEVE script MUST continue.
    If the :method tag contains a supported URI schema, then the URI MUST
    be checked for syntactic validity. An invalid URI syntax or an unsupported URI
    extension MUST cause an error. An implementation MAY enforce
    other semantical restrictions on URIs, for example an SMS URI can only
    contain phone numbers in a particular geographical reason. Violation
    of such semantical restrictions MUST also cause an error.

    The :id tag can be used to give the notify action an unique
    identifier. This identifier can be used later in the script to
    cancel the specific notify. The string may have any value and SHOULD
    NOT be included in the notification.

    The :priority tag specifies the importance of the notification.
    The :priority tag is followed by a numeric value represented
    as a string: "1" (very important), "2" (normal importance),
    and "3" (not very important). If no priority is given,
    a default priority of "2" SHOULD be
    assumed. Some notification methods allow users to specify their
    state of activity (for example "busy" or "away from keyboard"). If
    the notification method provides this information it SHOULD be used
    to selectively send notifications.  If, for example, the user marks
    herself as "busy", an implementation SHOULD NOT send a notification
    for a new mailing list message with a priority of "3", however the
    user should be notified of a high priority action.  If the
    notification method allows users to filter messages based upon
    certain parameters in the message, users should be able to filter
    based upon priority. If the notification method does not support
    priority, then this parameter MUST be ignored.
    <<Should we keep using "high", "normal" and "low" instead?>>

    The :message tag specifies the message data to be included in the
    notification. The entirety of the string SHOULD be sent but
    implementations MAY shorten the message for technical or aesthetic
    reasons. If the message parameter is absent, a default message
    containing the value of the From header field and the value of the
    Subject header field will be used. Note that the notification
    method (the ":method" tag) may affect how this information is
    The implementation of a notification method MAY modify the
    final notification, e.g. truncating it, if it exceeds a length limit,
    or modify characters that can not be represented in the
    target character set. Allowed modifications should be documented
    in a standard track or an informational document.

    In order to construct more complex messages
    the notify extension can be used together with the Sieve variables
    extension [VARIABLES], as shown at the end of this section.

    <<Open issue: the previous version of this draft has defined the two
      variables that can't be currently represented:

         $text$     - the first text/* part

         $text[n]$  - the first n bytes of the first text/* part

    If there are errors sending the notification, the Sieve interpreter
    SHOULD ignore the notification and not retry indefinitely.

    This action MUST NOT cancel the implicit keep.

        require ["notify", "fileinto", "variables"];

        if header :contains "from" "" {
            notify :priority "1" :message "This is probably very important";
            # Don't send any further notifications

        if header :contains "to" "" {
            # :matches is used to get the value of the Subject header
            if header :matches "Subject" "*" {
                set "subject" "${1}";

            # :matches is used to get the value of the From header
            if header :matches "From" "*" {
                set "from" "${1}";

            notify :priority "3" :message "[SIEVE] ${from}: ${subject}";
            fileinto "INBOX.sieve";

        require ["notify", "fileinto", "variables", "envelope"];

        if header :matches "from" "*@*" {
            # :matches is used to get the MAIL FROM address
            if envelope :all :matches "from" "*" {
                set "env_from" " [really: ${1}]";

            # :matches is used to get the value of the Subject header
            if header :matches "Subject" "*" {
                set "subject" "${1}";

            # :matches is used to get the address from the From header
            if address :matches :all "from" "*" {
                set "from_addr" "${1}";

            notify :message "${from_addr}${env_from}: ${subject}";

3.2.  Denotify Action

    Usage: denotify [MATCH-TYPE string] [":priority" <"1" / "2" / "3">]

    The denotify action can be used to cancel previous notifications.
    If the priority is specified, then
    only cancel those notifications with the specified priority.  If a
    MATCH-TYPE with a string is specified, then only those notifications
    whose :id tag matches the specified string using the match-type
    operator are canceled.  The ascii-casemap comparator MUST be used.

    If no notifications exist that match the search criteria, then the
    denotify has no effect.  A denotify only cancels notifications that
    have already been requested.  It is not possible to preemptively
    cancel a notification.

    The sequence:


    will still generate a notification.  The denotify does not cancel
    the notify.

    The following table shows which notifies would get cancelled:

                                              # what is cancelled
      denotify                                # all notifications
      denotify :matches "*"                   # all notifications with :id tag
      denotify :priority "1"                  # all high priority notifications
      denotify :is "foobar"                   # all notifications with id "foobar"
      denotify :matches "foo*" :priority "2"  # all normal priority
                                              # notifications with id that
                                              # starts with "foo"


        require ["notify", "variables"];

        notify :method ""
               :id "foobar";

        if header :contains "from" "" {
            # :matches is used to get the value of the Subject header
            if header :matches "Subject" "*" {
                set "subject" "${1}";

            notify :method "sms:+14085551212" :id "foobar"
                   :priority "1" :message "BOSS: ${subject}";

        if header :contains "to" "" {
            denotify :is "foobar";

        if header :contains "subject" "FYI:" {
            # don't need high priority notification for
            # a 'for your information'
            denotify :is "foobar" :priority "1";

4.  Interaction with Other Sieve Actions

    The notify action MUST NOT cancel the implicit keep.

    The notify action is compatible with all actions.
    Multiple executed notify actions are allowed.
    <<Add text about suppression of identical notifications?>>

    The denotify action MUST NOT affect any actions other than the
    notify action.

5.  Security Considerations

    Security considerations are discussed in [SIEVE]. Additionally
    implementations must be careful to follow the security
    considerations of the specific notification methods. It is believed
    that this extension does not introduce any additional security

    The notify action is potentially very dangerous.  The path the
    notification takes through the network may not be secure.  An error
    in the options string may cause the message to be transmitted to
    someone it was not intended for.

    Just because a notification is received doesn't mean it was sent by
    the sieve implementation.  It might be possible to forge
    notifications with some notification methods.

6.  IANA Considerations

   The following template specifies the IANA registration of the
   variables Sieve extension specified in this document:

   Subject: Registration of new Sieve extension
   Capability name: notify
   Capability keyword: notify
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number:
           this RFC
   Person and email address to contact for further information:
           Alexey Melnikov <>

   This information should be added to the list of sieve extensions
   given on

7.  Acknowledgments

    Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Barry
    Leiba, Cyrus Daboo, Nigel Swinson, Kjetil Torgrim Homme,
    Michael Haardt, Mark E. Mallett and Ned Freed for help with
    this document.

8.  References

8.1.  Normative References

    [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
    Requirement Levels", BCP 14, RFC 2119, March 1997.

    [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
    Specifications: ABNF", RFC 4234, October 2005.

    [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering
    Language", work in progress, draft-ietf-sieve-3028bis-XX.txt.

8.2.  Informative References

    [VARIABLES] Homme, K., "Sieve Extension: Variables", work in
    progress, draft-ietf-sieve-variables-XX.txt.


    [XMPP-URI] Saint-Andre, P., "A Uniform Resource Identifier (URI)
    Scheme for the Extensible Messaging and Presence Protocol (XMPP)",
    work in progress, draft-saintandre-xmpp-uri-XX.txt.

    [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short
    Message Service", work in progress, draft-wilde-sms-uri-XX.txt.

9.  Author's and Editor's Addresses

    Tim Martin
    Mirapoint Inc.
    909 Hermosa Court
    Sunnyvale, CA 94085

    Phone: (408) 720-3835

    Wolfgang Segmuller
    IBM T.J. Watson Research Center
    30 Saw Mill River Rd
    Hawthorne, NY  10532

    Phone: (914) 784-7408

    Alexey Melnikov (Editor)
    Isode Limited
    5 Castle Business Village
    36 Station Road
    Hampton, Middlesex
    TW12 2BX, UK


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.