Sieve Working Group A. Melnikov, Ed.
Internet-Draft Isode Limited
Intended status: Standards Track B. Leiba, Ed.
Expires: August 4, 2007 W. Segmuller
IBM T.J. Watson Research Center
T. Martin
BeThereBeSquare Inc.
January 31, 2007
Sieve Extension: Notifications
draft-ietf-sieve-notify-06
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 August 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 August 4, 2007 [Page 1]
Internet-Draft Sieve Extension: Notifications January 2007
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-05
o Fixed XMPP URI in one example.
o Addressed Michael's issue with how timestamp are described.
o Renamed "valid_notif_method" to "valid_notify_method".
o Added text about truncation of a textual part when it is stored in
a variable using extract_text.
o Changed tagged :method argument to positional argument.
o Added text about notification throttling, identifying notification
source and restricting values of the :from parameter.
o Added a requirement on documents describing notification methods
to list which URI parameters must be ignored.
Changes since draft-ietf-sieve-notify-04
o Made notification method required.
o Defined "mailto" as a mandatory-to-implement method.
o Added normative reference to mailto.
o Clarified that :importance may be treated as a transport
indicator.
o Clarified that :importance value can be included in the default
:message, if one is not specified.
o Made the default :message implementation specific.
o Renamed the capability name from "notify" to "enotify"
o Updated IANA registration.
o Moved text about ManageSieve capability to the ManageSieve
document itself.
Melnikov, et al. Expires August 4, 2007 [Page 2]
Internet-Draft Sieve Extension: Notifications January 2007
o Removed reference to IANA registry for options.
o Some miscellaneous text cleanup and clarification.
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.
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.
Melnikov, et al. Expires August 4, 2007 [Page 3]
Internet-Draft Sieve Extension: Notifications January 2007
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 August 4, 2007 [Page 4]
Internet-Draft Sieve Extension: Notifications January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Conventions used in this document . . . . . . . . . . . . . 6
2. Capability Identifier . . . . . . . . . . . . . . . . . . . 6
3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 6
3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 6
3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 7
3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 7
3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 8
3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 8
3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Requirements on notification methods specifications . . . . 11
4. Extract_text Action . . . . . . . . . . . . . . . . . . . . 12
5. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13
6. Interactions with Other Sieve Actions . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 18
Melnikov, et al. Expires August 4, 2007 [Page 5]
Internet-Draft Sieve Extension: Notifications January 2007
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 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] method is mandatory. Other available
methods shall depend upon the implementation and configuration of the
system.
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 "enotify".
3. Notify Action
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).
However, all content specified in the :message parameter SHOULD be
included.
3.2. Notify parameter "method"
The method positional parameter identifies the notification method
that will be used; it is a URI [URI]. For example, the notification
Melnikov, et al. Expires August 4, 2007 [Page 6]
Internet-Draft Sieve Extension: Notifications January 2007
method can be an SMS URI [SMS-URI] containing a phone number, or an
XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI].
The supported URI values will be site-specific, but support for the
[MailTo] 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.
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.
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.
Melnikov, et al. Expires August 4, 2007 [Page 7]
Internet-Draft Sieve Extension: Notifications January 2007
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, however an
implementation MAY include the importance value in the default
message Section 3.6, if one is not provided.
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>" [[Alexey 3: Should we say something about
implementation prefix for implementation specific options? Something
like "x-Vendor-zzz". If we don't say it now, it might be too late to
say it later.]]
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], as
shown in the examples below.
3.7. Examples
Melnikov, et al. Expires August 4, 2007 [Page 8]
Internet-Draft Sieve Extension: Notifications January 2007
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";
}
Melnikov, et al. Expires August 4, 2007 [Page 9]
Internet-Draft Sieve Extension: Notifications January 2007
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";
}
Melnikov, et al. Expires August 4, 2007 [Page 10]
Internet-Draft Sieve Extension: Notifications January 2007
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";
}
}
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.
Melnikov, et al. Expires August 4, 2007 [Page 11]
Internet-Draft Sieve Extension: Notifications January 2007
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.
Notifications SHOULD includes 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
and which ones must be used in the resulting notification.
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.
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. In either case the actually stored data MAY be truncated
to conform to implementation specific limit on variable length and/or
on MIME body part length.
If the message being processed doesn't contain any text/* part, the
action will set the variable identified by varname to the 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.
Melnikov, et al. Expires August 4, 2007 [Page 12]
Internet-Draft Sieve Extension: Notifications January 2007
Note that this action is only available when the Sieve script
specifies both "variables" [Variables] and "enotify" capabilities in
the require statements.
Example 4:
require ["enotify", "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 :importance "1"
:message "BOSS: ${subject}; ${msgcontent}"
"sms:+14085551212";
}
}
5. 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 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 5:
if not valid_notify_method ["mailto:",
"http://gw.example.net/notify?test"] {
Melnikov, et al. Expires August 4, 2007 [Page 13]
Internet-Draft Sieve Extension: Notifications January 2007
stop;
}
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. Specific notification
methods MAY allow multiple notifications from the same script to be
collapsed into one.
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 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. [[Michael suggested
to delete this example: 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.
8. IANA Considerations
The following template specifies the IANA registration of the notify
Sieve extension specified in this document:
Melnikov, et al. Expires August 4, 2007 [Page 14]
Internet-Draft Sieve Extension: Notifications January 2007
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; also adds the 'extract_text' action for extracting
a part of the first textual bodypart.
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.
9. 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 and Peter Saint-
Andre for help with this document.
10. References
10.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.
[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.
[Variables]
Homme, K., "Sieve Extension: Variables", work in
progress, draft-ietf-sieve-variables, December 2005.
Melnikov, et al. Expires August 4, 2007 [Page 15]
Internet-Draft Sieve Extension: Notifications January 2007
10.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
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
Melnikov, et al. Expires August 4, 2007 [Page 16]
Internet-Draft Sieve Extension: Notifications January 2007
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 August 4, 2007 [Page 17]
Internet-Draft Sieve Extension: Notifications January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 August 4, 2007 [Page 18]
