TOC 
Sieve Working GroupA. Melnikov, Ed.
Internet-DraftIsode Limited
Intended status: Standards TrackB. Leiba, Ed.
Expires: April 7, 2008W. Segmuller
 IBM T.J. Watson Research Center
 T. Martin
 BeThereBeSquare Inc.
 October 05, 2007


SIEVE Email Filtering: Notifications
draft-ietf-sieve-notify-09

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

This Internet-Draft will expire on April 7, 2008.

Abstract

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 it is expected that using existing instant messaging infrastructure such as XMPP, 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.

Changes since draft-ietf-sieve-notify-08

Changes since draft-ietf-sieve-notify-07

Changes since draft-ietf-sieve-notify-06

Changes since draft-ietf-sieve-notify-05

Changes since draft-ietf-sieve-notify-04

Changes since draft-ietf-sieve-notify-03

Changes since draft-ietf-sieve-notify-02

Changes since draft-ietf-sieve-notify-00



Table of Contents

1.  Introduction
1.1.  Conventions used in this document

2.  Capability Identifier

3.  Notify Action
3.1.  Notify Action Syntax and Semantics
3.2.  Notify parameter "method"
3.3.  Notify tag ":from"
3.4.  Notify tag ":importance"
3.5.  Notify tag ":options"
3.6.  Notify tag ":message"
3.7.  Examples
3.8.  Requirements on notification methods specifications

4.  Test valid_notify_method

5.  Test notify_method_capability

6.  Modifier encodeurl to the 'set' action

7.  Interactions with Other Sieve Actions

8.  Security Considerations

9.  IANA Considerations
9.1.  Registration of Sieve extension
9.2.  New registry for Sieve notification mechanisms

10.  Acknowledgements

11.  References
11.1.  Normative References
11.2.  Informative References

§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

This is an extension to the Sieve language defined by [Sieve] (Guenther, P. and T. Showalter, “Sieve: An Email Filtering Language,” August 2006.) for providing instant notifications. It defines the new action "notify".

This document does not specify the notification methods. Examples of possible notification methods are email and XMPP. To allow a mechanism for portability of scripts that use notifications, implementation of the [MailTo] (Leiba, B. and M. Haardt, “Sieve Notification Mechanism: mailto,” October 2006.) method is mandatory. Other available methods shall depend upon the implementation and configuration of the system.



 TOC 

1.1.  Conventions used in this document

Conventions for notations are as in [Sieve] (Guenther, P. and T. Showalter, “Sieve: An Email Filtering Language,” August 2006.) section 1.1, including the use of [ABNF] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).

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 [Kwds] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Capability Identifier

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



 TOC 

3.  Notify Action



 TOC 

3.1.  Notify Action Syntax and Semantics

Usage:
notify [":from" string] [":importance" <"1" / "2" / "3">]
[":options" string-list]
[":message" string]
<method: string>

The Notify action specifies that a notification should be sent to a user. The format of the notification is implementation-defined and is also affected by the notification method used (see Section 3.2 (Notify parameter "method")). However, all content specified in the :message parameter SHOULD be included.



 TOC 

3.2.  Notify parameter "method"

The method positional parameter identifies the notification method that will be used; it is a URI [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.). For example, the notification method can be an SMS URI [SMS‑URI] (Wilde, E. and A. Vaha-Sipila, “URI scheme for GSM Short Message Service,” August 2005.) containing a phone number, or an XMPP [XMPP] (Saint-Andre, Ed., P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) URI containing an XMPP identifier [XMPP‑URI] (Saint-Andre, P., “Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP),” September 2005.).

The supported URI values will be site-specific, but support for the [MailTo] (Leiba, B. and M. Haardt, “Sieve Notification Mechanism: mailto,” October 2006.) method is REQUIRED in order to insure interoperability. If a URI schema is specified that the implementation does not support, the notification MUST cause an error condition. Sieve scripts can check the supported methods using the "valid_notify_method" test to be sure that they only use supported ones, to avoid such error conditions.

If the method parameter 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 semantic restrictions on URIs -- for example an SMS URI can only contain phone numbers in a particular geographical region -- and will treat violations of such semantic restrictions as errors.



 TOC 

3.3.  Notify tag ":from"

A ":from" parameter may be used to specify an author of the notification. The syntax of this parameter's value is method-specific. Implementations SHOULD check the syntax according to the notification method specification and generate an error when a syntactically invalid ":from" parameter is specified. In order to minimize/prevent forgery of the author value, implementations SHOULD impose restrictions on what values can specified in a ":from" parameter; it is suggested that values which fail such a validity check simply be ignored rather than causing the notify action to fail.



 TOC 

3.4.  Notify tag ":importance"

The :importance tag specifies the importance of the delivery of the notification. The :importance tag is followed by a numeric value represented as a string: "1" (high importance), "2" (normal importance), and "3" (low importance). If no importance is given, the default value "2" SHOULD be assumed. A notification method can treat the importance value as a transport indicator. For example, it might deliver notifications of high importance quicker than notifications of normal or low importance. 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", a notification method can require that a notification with importance of "3" is not to be sent, however the user should be notified of a notification with higher importance.

If the notification method allows users to filter messages based upon certain parameters in the message, users SHOULD be able to filter based upon importance. If the notification method does not support importance, then this parameter MUST be ignored. An implementation MAY include the importance value in the default message Section 3.6 (Notify tag ":message"), if one is not provided.



 TOC 

3.5.  Notify tag ":options"

The :options tag is used to send additional parameters to the notification method. Interpretation of the parameters is method-specific. This document doesn't specify any such additional parameter.

Each string in the options string list has the following syntax:
"<optionname>=<value>"



 TOC 

3.6.  Notify tag ":message"

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 implementation-specific message is used. Unless specified otherwise by a particular notification mechanism, an implementation default containing at least the value of the "From" header field and the value of the "Subject" header field is RECOMMENDED.

In order to construct more complex messages the notify extension can be used together with the Sieve variables extension [Variables] (Homme, K., “Sieve Extension: Variables,” December 2005.), as shown in the examples below.



 TOC 

3.7.  Examples

Example 1:
    require ["enotify", "fileinto", "variables"];

    if header :contains "from" "boss@example.org" {
        notify :importance "1"
            :message "This is probably very important"
            "mailto:alm@example.com";
        # Don't send any further notifications
        stop;
    }

    if header :contains "to" "sievemailinglist@example.org" {
        # :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 :importance "3"
            :message "[SIEVE] ${from}: ${subject}"
            "mailto:alm@example.com";
        fileinto "INBOX.sieve";
    }

Example 2:
    require ["enotify", "fileinto", "variables", "envelope"];

    if header :matches "from" "*@*.example.org" {
        # :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}"
            "mailto:alm@example.com";
    }

Example 3:
    require ["enotify", "variables"];

    set "notif_method"
    "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";

    if header :contains "subject" "Your dog" {
        set "notif_method" "sms:+14085551212";
    }

    if header :contains "to" "sievemailinglist@example.org" {
        set "notif_method" "";
    }

    if not string :is "${notif_method}" "" {
        notify "${notif_method}";
    }

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

        # don't need high importance notification for
        # a 'for your information'
        if not header :contains "subject" "FYI:" {
            notify :importance "1" :message "BOSS: ${subject}"
                   "sms:+14085551212";
        }
    }



 TOC 

3.8.  Requirements on notification methods specifications

This section describes requirements for documents that define specific Sieve notification methods.

A notification method MAY allow modification of the final notification text -- for example, truncating it if it exceeds a length limit, or modifying characters that can not be represented in the target character set. Characters in the notification text which can't be represented by the notification method SHOULD be replaced with a symbol indicating an unknown character. Allowed modifications MUST be documented in the document describing the notification method.

A notification method MAY ignore parameters specified in the Notify action.

A notification method MAY recommend the default message value to be used if the :message argument is not specified.

Notifications SHOULD include timestamps, if the notification method allows for their transmission outside of the textual message. Implementation methods which can only transmit timestamps in the textual message MAY include them in the textual message.

A notification SHOULD include means to identify/track its origin, in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help tracking a misconfigured or abusive origin of notifications.

Methods SHOULD NOT include any other extraneous information not specified in parameters to the notify action.

Methods MUST specify which URI parameters (if any) must be ignored, which ones must be used in the resulting notification and which ones must cause an error.

Methods MUST specify what values are returned by the notify_method_capability test Section 5 (Test notify_method_capability).

If there are errors sending the notification, the Sieve interpreter SHOULD ignore the notification and not retry indefinitely. The Sieve interpreter MAY throttle notifications; if it does, a request to send a notification can be silently ignored. Documents describing notification methods SHOULD describe how retries, throttling, duplicate suppression (if any), etc. are to be handled by implementations.



 TOC 

4.  Test valid_notify_method

Usage:
valid_notify_method <notification-uris: string-list>

The "valid_notify_method" test is true if the notification methods listed in the notification-uris argument are supported and they are syntactically (including URI parameters) and semantically (including implementation-specific semantic restrictions) valid. This test MUST perform exactly the same validation as would be performed on the "method" parameter to the "notify" action.

The test is true only if ALL of the listed notification methods are supported and valid.


Example 4 (partial):
          if not valid_notify_method ["mailto:",
                  "http://gw.example.net/notify?test"] {
              stop;
          }



 TOC 

5.  Test notify_method_capability

Usage:
notify_method_capability [COMPARATOR] [MATCH-TYPE] <notification-uri: string>
<notification-capability: string>
<key-list: string-list>

The "notify_method_capability" test retrieves the notification capability specified by the notification-capability string that is specific to the notification-uri and matches it to the values specified in the key-list. The test succeeds if a match occurs. The type of match defaults to ":is" and the default comparator is "i;ascii-casemap".

The notification-capability is case insensitive.

The notify_method_capability test MUST fail unconditionally if the specified notification-uri is syntactically invalid (as determined by the valid_notify_method test Section 4 (Test valid_notify_method)) or specifies an unsupported notification method. However this MUST NOT cause an error.

The notify_method_capability test MUST fail unconditionally if the specified notification-capability item does not exist. A script MUST NOT fail with an error if the item does not exist. This allows scripts to be written that handle nonexistent items gracefully.

This document defines a single notification-capability value "online", which is described below. Additional notification-capability values may be defined by a Standard Track or Experimental RFC.

For the "online" notification-capability the notify_method_capability test can match one of the following key-list values:

The "relational" extension [Relational] (Segmuller, W. and B. Leiba, “Sieve Extension: Relational Tests,” December 2005.) adds a match type called ":count". The count of an notify_method_capability test is 0 if the returned information is the empty string, or 1 otherwise.


Example 5:
          require ["enotify"];

          if notify_method_capability
                 "xmpp:tim@example.com?message;subject=SIEVE"
                 "Online"
                 "yes" {
              notify :importance "1" :message "You got mail"
                   "xmpp:tim@example.com?message;subject=SIEVE";
          } else {
              notify :message "You got mail" "sms:+14085551212";
          }



 TOC 

6.  Modifier encodeurl to the 'set' action

Usage:
":encodeurl"

When the Sieve script specifies both "variables" [Variables] (Homme, K., “Sieve Extension: Variables,” December 2005.) and "enotify" capabilities in the "require", a new "set" action modifier (see [Variables] (Homme, K., “Sieve Extension: Variables,” December 2005.)) ":encodeurl" becomes available to Sieve scripts. This modifier performs percent-encoding of any octet in the string which doesn't belong to the "unreserved" set (see [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)). The percent-encoding procedure is described in [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

The ":encodeurl" modifier has precedence 15.


Example 6:
    require ["enotify", "variables"];

    set :encodeurl "body_param" "Safe body&evil=evilbody";

    notify "mailto:tim@example.com?body=${body_param}";



 TOC 

7.  Interactions with Other Sieve Actions

The notify action is compatible with all other actions, and does not affect the operation of other actions. In particular, the notify action MUST NOT cancel the implicit keep.

Multiple executed notify actions are allowed. Specific notification methods MAY allow multiple notifications from the same script to be collapsed into one.



 TOC 

8.  Security Considerations

Security considerations are discussed in [Sieve] (Guenther, P. and T. Showalter, “Sieve: An Email Filtering Language,” August 2006.). Additionally, implementations must be careful to follow the security considerations of the specific notification methods.

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, or may expose information to eavesdroppers.

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

An organization may have a policy about the forwarding of classified information to unclassified networks. Unless the policy is also enforced in the module responsible for generating (or sending) of notifications, users can use the extension defined in this document to extract classified information and bypass the policy.

Notifications can result in loops and bounces. In particular, a notification to an email address will not contain necessary Received header fields that might be otherwise used to prevent mail loops. All notification methods MUST take care to provide mechanisms for avoiding notification loops.

Implementations that construct URIs internally from various notify parameters MUST make sure that all components of such URIs are properly percent-encoded (see [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)). In particular this applies to values of the :from and the :message tagged arguments and may apply to the :options values.



 TOC 

9.  IANA Considerations



 TOC 

9.1.  Registration of Sieve extension

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

To: iana@iana.org
Subject: Registration of new Sieve extension
Capability name: enotify
Description: adds the 'notify' action for notifying user about the received message. It also provides two new test: valid_notify_method checks notification URIs for validity; notify_method_capability can check recipients capabilities.
RFC number: this RFC
Contact address:
    The Sieve discussion list <ietf-mta-filters@imc.org>

This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions.



 TOC 

9.2.  New registry for Sieve notification mechanisms

This defines the template for a new registry for Sieve notification mechanisms, to be created as http://www.iana.org/assignments/sieve-notification. There are no initial entries for this registry.

To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: [the name of the mechanism]
Mechanism URI: [the RFC number of the document that defines the URI used by this mechanism]
Mechanism-specific tags: [the names of any Sieve notify tags that are specific to this mechanism, or "none"]
Standards Track/IESG-approved experimental RFC number: [the RFC number of the document that defines this notification mechanism]
Person and email address to contact for further information: [the name and email address of the technical contact for information about this mechanism]



 TOC 

10.  Acknowledgements

Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen and Peter Saint-Andre for help with this document.



 TOC 

11.  References



 TOC 

11.1. Normative References

[ABNF] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 4234, October 2005.
[Kwds] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, March 1997.
[MailTo] Leiba, B. and M. Haardt, “Sieve Notification Mechanism: mailto,” work in progress, draft-ietf-sieve-notify-mailto, October 2006.
[Relational] Segmuller, W. and B. Leiba, “Sieve Extension: Relational Tests,” work in progress, draft-ietf-sieve-3431bis, December 2005.
[Sieve] Guenther, P. and T. Showalter, “Sieve: An Email Filtering Language,” work in progress, draft-ietf-sieve-3028bis, August 2006.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[Variables] Homme, K., “Sieve Extension: Variables,” work in progress, draft-ietf-sieve-variables, December 2005.


 TOC 

11.2. Informative References

[SMS-URI] Wilde, E. and A. Vaha-Sipila, “URI scheme for GSM Short Message Service,” work in progress, draft-wilde-sms-uri, August 2005.
[XMPP] Saint-Andre, Ed., P., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004.
[XMPP-URI] Saint-Andre, P., “Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP),” work in progress, draft-saintandre-xmpp-iri, September 2005.


 TOC 

Authors' Addresses

  Alexey Melnikov (editor)
  Isode Limited
  5 Castle Business Village
  36 Station Road
  Hampton, Middlesex TW12 2BX
  UK
Email:  Alexey.Melnikov@isode.com
  
  Barry Leiba (editor)
  IBM T.J. Watson Research Center
  19 Skyline Drive
  Hawthorne, NY 10532
  US
Phone:  +1 914 784 7941
Email:  leiba@watson.ibm.com
  
  Wolfgang Segmuller
  IBM T.J. Watson Research Center
  19 Skyline Drive
  Hawthorne, NY 10532
  US
Phone:  +1 914 784 7408
Email:  werewolf@us.ibm.com
  
  Tim Martin
  BeThereBeSquare Inc.
  672 Haight st.
  San Francisco, CA 94117
  US
Phone:  +1 510 260-4175
Email:  timmartin@alumni.cmu.edu


 TOC 

Full Copyright Statement

Intellectual Property