Network Working Group Tim Martin Document: draft-martin-sieve-notify-01.txt Wolfgang Segmuller Expires December 6, 2001 1 June 2001 Sieve -- An extension for providing instant notifications 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. 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 is expected that using existing instant messaging infrastructure such as Zephyr, ICQ, or SMS messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific preferences for notification of Sieve actions. Expires December 6, 2001 Martin [Page 1] Internet Draft Sieve -- Notifications extension June 1, 2001 TTaabbllee ooff CCoonntteennttss Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3 3. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Notify action . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Denotify Action . . . . . . . . . . . . . . . . . . . . . . . 5 4. Interaction with Other Sieve Actions . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 8 Expires December 6, 2001 Martin [Page 2] Internet Draft Sieve -- Notifications extension June 1, 2001 1. Introduction This is an extension to the Sieve language defined by [SIEVE] for providing instant notifications of sieve actions that have been preformed. It defines the new action "notify". This document does not dictate the notification method used. Examples of possible notification methods are Zephyr and ICQ. The method shall be site-defined. Sieve interpreters for which notifications are impractical or is not possible SHOULD ignore this extension. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 Syntax: notify [":method" string] [":id" string] [":options" 1*(string-list / number)] [<":low" / ":normal" / ":high">] ["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. However, Expires December 6, 2001 Martin [Page 3] Internet Draft Sieve -- Notifications extension June 1, 2001 all content specified in the notify action, including Sieve actions taken on the message, SHOULD be included. If errors occurred in another action they SHOULD be reported in the notification. In addition, if the notification method does not provide a timestamp, one SHOULD be appended to the notification. Implementations SHOULD NOT include extraneous information. The :method tag identifies the notification method that will be used. If the :method tag is not specified, the default implementation defined notification method MUST be used. The possible values of this will be site-specific. If a method is specified that the implementation does not support, the notification MUST be ignored. An implementation treats this as a warning condition and execution of the sieve script MUST continue. 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 :options tag is used to send parameters to the notification method. This might be the phone number for an SMS message or a user's ICQ identifier. The priority parameter specifies the importance of the notification. The priority parameter has the following values: ":high" (very important), ":normal", and ":low" (not very important). If no priority is given, a default priority of ":normal" 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 :low, 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. 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. Message may include the message variables defined below. If the message parameter is absent, a default message of "$from$: $subject$" will be used. $from$ - the display name or address of the RFC 822 from Expires December 6, 2001 Martin [Page 4] Internet Draft Sieve -- Notifications extension June 1, 2001 $env-from$ - the address of the RFC 821 from $subject$ - the subject of the message $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. Example: require ["notify","fileinto"]; if header :contains "from" "boss@example.org" { notify :high "This is probably very important"; } if header :contains "to" "sievemailinglist@example.org" { notify :low "[SIEVE] $from$: $subject$"; fileinto "INBOX.sieve"; } 3.2. Denotify Action Syntax: denotify [MATCH-TYPE string] [<":low" / ":normal" / ":high">] The denotify action can be used to cancel a previous notification. If the priority, ":low" / ":normal" / ":high", 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: denotify; Expires December 6, 2001 Martin [Page 5] Internet Draft Sieve -- Notifications extension June 1, 2001 notify; 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 :high # all high priority notifications denotify :is "foobar" # all notifications with id "foobar" denotify :matches "foo*" :normal # all normal priority notifications # with id that starts with "foo" Example: require "notify"; notify :method "sms" :options "408-555-1212" :id "foobar"; if header :contains "from" "boss@example.org" { notify :method "sms" :options "408-555-1212" :id "foobar" :high :message "BOSS: $subject$"; } if header :contains "to" "sievemailinglist@example.org" { denotify :is "foobar"; } if header :contains "subject" "FYI:" { # don't need high priority notification for # a 'for your information' denotify :is "foobar" :high; } 4. Interaction with Other Sieve Actions Notifications MUST be sent in all cases, unless a reject action is also executed. Users may wish to be notified of a message being discarded, for example. The reject action is given an exception because implementations may wish to restrict users from seeing the contents of a rejected message. However, notifications MAY be modified to not include any data from the original rejected message. The notify action MUST NOT cancel the implicit keep. Expires December 6, 2001 Martin [Page 6] Internet Draft Sieve -- Notifications extension June 1, 2001 The denotify action MUST NOT affect any actions other than the notify action. Failures of other actions MAY be reported in the notification. 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 concerns. 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. Acknowledgments Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, and Barry Leiba for help with this document. 7. Copyright Copyright (C) The Internet Society 1999. 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 Expires December 6, 2001 Martin [Page 7] Internet Draft Sieve -- Notifications extension June 1, 2001 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. 8. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [SIEVE]; Showalter, T.; "Sieve: A Mail Filtering Language"; RFC 3028; Mirapoint, Inc.; January 2001 9. Author's Addresses Tim Martin Mirapoint Inc. 909 Hermosa Court Sunnyvale, CA 94085 Phone: (408) 720-3835 EMail: tmartin@mirapoint.com Wolfgang Segmuller IBM T.J. Watson Research Center 30 Saw Mill River Rd Hawthorne, NY 10532 Phone: (914) 784-7408 Email: whs@watson.ibm.com Expires December 6, 2001 Martin [Page 8]