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

Versions: (draft-martin-sieve-notify) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5435

Sieve Working Group                                     A. Melnikov, Ed.
Internet-Draft                                             Isode Limited
Intended status: Standards Track                           B. Leiba, Ed.
Expires: April 22, 2007                                     W. Segmuller
                                         IBM T.J. Watson Research Center
                                                               T. Martin
                                                    BeThereBeSquare Inc.
                                                        October 19, 2006


                     Sieve Extension: Notifications
                       draft-ietf-sieve-notify-04

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 22, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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



Melnikov, et al.         Expires April 22, 2007                 [Page 1]


Internet-Draft       Sieve Extension: Notifications         October 2006


   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.

ToDo

   o  Change tagged :method to the positional parameter?

Changes since draft-ietf-sieve-notify-03

   o  Added a warning that "notify" must not be used as a crappy form of
      "redirect".

   o  Added a warning about using "notify" to forward confidential
      information in order to bypass organization's policy.

   o  Fixed syntax of the :options argument - it is a string list, each
      string containing "<attribute>=<value>"

   o  Renamed :priority to :importance

   o  Cleaned up section about requirements on methods.

Changes since draft-ietf-sieve-notify-02

   o  Added :from tagged argument.

   o  Added Extract_text action, which allows to extract content of the
      first text/* part.

   o  Added back the ":options" parameter to the notify action.

   o  Added new section talking about requirements on notification
      method specs.

   o  Added more examples.

Changes since draft-ietf-sieve-notify-00

   o  Updated references, etc.

   o  Added IANA considerations section.

   o  Removed denotify action.




Melnikov, et al.         Expires April 22, 2007                 [Page 2]


Internet-Draft       Sieve Extension: Notifications         October 2006


   o  Updated examples to use the variables extension.

   o  Replaced notification method with URI.

   o  Removed text suggesting that this extension can be used to track
      all Sieve actions taken.

   o  Changed priority to be a string.

   o  Added text about URI verification.

   o  Clarified that a notification method is allowed to perform
      adaptation of notification context (e.g. truncation, charset
      conversion, etc.).  These adaptations must be documented in a
      document describing the notification method.

   o  Clarified that notify is compatible with all existing actions.

   o  Removed the :id parameter to the notify action.

   o  Added valid_notif_method test that allows to test if an
      notification method (URI) is supported.

   o  Added a new capability response to ManageSieve that allows to
      report supported notification types.


























Melnikov, et al.         Expires April 22, 2007                 [Page 3]


Internet-Draft       Sieve Extension: Notifications         October 2006


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.1.  Conventions used in this document  . . . . . . . . . . . . .  5

   2.    Capability Identifier  . . . . . . . . . . . . . . . . . . .  5

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

   4.    Extract_text Action  . . . . . . . . . . . . . . . . . . . . 10

   5.    Test valid_notif_method  . . . . . . . . . . . . . . . . . . 11

   6.    Interactions with Other Sieve Actions  . . . . . . . . . . . 12

   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 12

   8.    Extensions to ManageSieve protocol . . . . . . . . . . . . . 12

   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 13

   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13

   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11.1. Normative References . . . . . . . . . . . . . . . . . . . . 13
   11.2. Informative References . . . . . . . . . . . . . . . . . . . 14

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
         Intellectual Property and Copyright Statements . . . . . . . 16














Melnikov, et al.         Expires April 22, 2007                 [Page 4]


Internet-Draft       Sieve Extension: Notifications         October 2006


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 methods shall be site-defined.

1.1.  Conventions used in this document

   Conventions for notations are as in [Sieve] section 1.1, including
   the use of [ABNF].

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


2.  Capability Identifier

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


3.  Notify Action

3.1.  Notify Action Syntax and Semantics

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

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

3.2.  Notify tag ":method"

   The :method tag identifies the notification method that will be used;
   it is a URI [URI].  For example, the notification method can be an
   SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP] URI
   containing a Jabber identifier [XMPP-URI].  If the :method tag is not
   specified, a default implementation-defined notification method is



Melnikov, et al.         Expires April 22, 2007                 [Page 5]


Internet-Draft       Sieve Extension: Notifications         October 2006


   used, and if there is no default method defined, the notification is
   ignored.  Implementations MUST NOT generate an error condition for
   lack of a default notification method, and execution of the script
   MUST continue.

   The supported URI values will be site-specific.  If an 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_notif_method" test to be sure that they only
   use supported ones, to avoid such error conditions.  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
   semantic restrictions on URIs -- for example an SMS URI can only
   contain phone numbers in a particular geographical region.  Violation
   of such semantic restrictions MUST be treated as an error.
   [[Barry 1: "MUST" seems silly here, since the whole sentence is a
   "MAY".]]

3.3.  Notify tag ":from"

   A ":from" parameter may be used to specify a notification method
   specific author of the notification.  Implementations SHOULD check
   the syntax according to the notification method specification and
   generate an error when a syntactically invalid ":from" parameter is
   specified.

3.4.  Notify tag ":importance"

   The :importance tag specifies the importance 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.  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.
   [[Alexey 1: Clarify that this is a transport indicator, not content]]

   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.  [[Alexey 2: Does
   the MUST prohibit inclusion of the field into :message content?]]




Melnikov, et al.         Expires April 22, 2007                 [Page 6]


Internet-Draft       Sieve Extension: Notifications         October 2006


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.

   Each string in the options string list has the following value:
   "<optionname>=<value>" [[Alexey 3: Do we need IANA registry for
   <optionname>?]]

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

   The implementation of a notification method MAY modify 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.  Allowed modifications should be documented
   in a standards-track, experimental or informational document.

   In order to construct more complex messages the notify extension can
   be used together with the Sieve variables extension [Variables], as
   shown in the examples below.

3.7.  Examples




















Melnikov, et al.         Expires April 22, 2007                 [Page 7]


Internet-Draft       Sieve Extension: Notifications         October 2006


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

       if header :contains "from" "boss@example.org" {
           notify :importance "1"
               :message "This is probably very important";
           # 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}";
           fileinto "INBOX.sieve";
       }


   Example 2:
       require ["notify", "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}";
       }



Melnikov, et al.         Expires April 22, 2007                 [Page 8]


Internet-Draft       Sieve Extension: Notifications         October 2006


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

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

       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 :method "${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 :method "sms:+14085551212"
                  :importance "1" :message "BOSS: ${subject}";
           }
       }

   [[anchor2: Make sure that the XMPP notification syntax is correct.]]

3.8.  Requirements on notification methods specifications

   This section describes requirements on a document describing a Sieve
   notification method.

   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.




Melnikov, et al.         Expires April 22, 2007                 [Page 9]


Internet-Draft       Sieve Extension: Notifications         October 2006


   A notification method MAY ignore parameters specified in the Notify
   action.  [[Alexey 4: Does this apply to :message?  I.e., do we want
   to allow for notifications that can only transport "you got mail"
   indicator?]]

   It is RECOMMENDED that a timestamp be included in the notification.

   Implementations SHOULD NOT include extraneous information not
   specified in parameters to the notify action.

   If there are errors sending the notification, the Sieve interpreter
   SHOULD ignore the notification and not retry indefinitely.  Document
   describing a notification method SHOULD describe how retries,
   duplicate suppression (if any), etc. are to be handled by
   implementations.


4.  Extract_text Action

   Usage:  extract_text [MODIFIER] [":first" number]
           <varname: string>

   The Extract_text action stores at most :first bytes of the first
   text/* part in the variable identified by varname.  If the :first
   parameter is not present, the whole content of the first text/* part
   is stored.  If the message being processed doesn't contain any text/*
   part, the action will set the variable identified by varname to empty
   string.  [[Alexey 5: Do we need to be more specific about what "the
   first text part" means?]]

   Modifiers are applied on the extracted text before it is stored in
   the variable.  See [Variables] for details.

   Note that this action is only available when the Sieve script
   specifies both "variables" [Variables] and "notify" capabilities in
   the require statements.















Melnikov, et al.         Expires April 22, 2007                [Page 10]


Internet-Draft       Sieve Extension: Notifications         October 2006


   Example 4:
       require ["notify", "variables"];

       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}";
           }

           # extract the first 100 bytes of the first text/* part
           extract_text :first 100 "msgcontent";

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



5.  Test valid_notif_method

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

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

   All of the listed notification methods must be supported and valid or
   the test is false.



   Example 5:
             if not valid_notif_method ["mailto:",
                     "http://gw.example.net/notify?test"] {
                 stop;
             }







Melnikov, et al.         Expires April 22, 2007                [Page 11]


Internet-Draft       Sieve Extension: Notifications         October 2006


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


7.  Security Considerations

   Security considerations are discussed in [Sieve].  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 forwarding of any 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.

   [[Alexey 6: The following might be too specific to mailto:]] Users
   must not use notifications as poor's man "redirect" facility, as this
   can result in mail 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.


8.  Extensions to ManageSieve protocol

   A ManageSieve [ManageSieve] server that supports the "notify"
   extension MUST advertise the NOTIFY capability, that has a single
   mandatory parameter.  The parameter is a string containing space
   separated list of URI schema parts for supported nofication methods.

   Example:
   S: "NOTIFY" "xmpp mailto"




Melnikov, et al.         Expires April 22, 2007                [Page 12]


Internet-Draft       Sieve Extension: Notifications         October 2006


9.  IANA Considerations

   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: 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 <Alexey.Melnikov@isode.com>

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


10.  Acknowledgements

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


11.  References

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.

   [ManageSieve]
              Martin, T. and A. Melnikov, "A Protocol for Remotely
              Managing Sieve Scripts", work in
              progress, draft-martin-managesieve, February 2006.

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

   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.




Melnikov, et al.         Expires April 22, 2007                [Page 13]


Internet-Draft       Sieve Extension: Notifications         October 2006


   [Variables]
              Homme, K., "Sieve Extension: Variables", work in
              progress, draft-ietf-sieve-variables, October 2005.

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.


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











Melnikov, et al.         Expires April 22, 2007                [Page 14]


Internet-Draft       Sieve Extension: Notifications         October 2006


   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

































Melnikov, et al.         Expires April 22, 2007                [Page 15]


Internet-Draft       Sieve Extension: Notifications         October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Melnikov, et al.         Expires April 22, 2007                [Page 16]


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