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- 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). 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, 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", "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 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. <> 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, 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. <> 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", "variables"]; if header :contains "from" "boss@example.org" { notify :priority "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 :priority "3" :message "[SIEVE] ${from}: ${subject}"; fileinto "INBOX.sieve"; } Example: 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}"; } 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: denotify; 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 :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" Example: require ["notify", "variables"]; notify :method "xmpp:tim@example.com?You%20got%20mail&subject=SIEVE" :id "foobar"; 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}"; } notify :method "sms:+14085551212" :id "foobar" :priority "1" :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" :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. <> 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 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. IANA Considerations The following template specifies the IANA registration of the variables 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 This information should be added to the list of sieve extensions given on http://www.iana.org/assignments/sieve-extensions. 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] [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 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 Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, UK Email: Alexey.Melnikov@isode.com 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 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.