5435
PROPOSED STANDARD
Sieve Email Filtering: Extension for Notifications
Authors: A. Melnikov, B. Leiba, W. Segmuller, T. Martin
Date: January 2009
Area: app
Working Group: sieve
Stream: IETF
Updated by:
RFC 8580
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 Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]
RFC 5435
PROPOSED STANDARD
Updated by: 8580
Network Working Group A. Melnikov, Ed.
Request for Comments: 5435 Isode Limited
Category: Standards Track B. Leiba, Ed.
W. Segmuller
IBM T.J. Watson Research Center
T. Martin
Endless Crossword
January 2009
<span class="h1">Sieve Email Filtering: Extension for Notifications</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/</a>
<a href="http://trustee.ietf.org/license-info">license-info</a>) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 Extensible Messaging and Presence Protocol
(XMPP), or Global System for Mobile Communications (GSM) Short
Message Service (SMS) messages will be popular. This document
describes an extension to the Sieve mail filtering language that
allows users to give specific rules for how and when notifications
should be sent.
<span class="grey">Melnikov, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Capability Identifier ...........................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Notify Action ...................................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Notify Action Syntax and Semantics .........................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Notify Parameter "method" ..................................<a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. Notify Tag ":from" .........................................<a href="#page-4">4</a>
<a href="#section-3.4">3.4</a>. Notify Tag ":importance" ...................................<a href="#page-4">4</a>
<a href="#section-3.5">3.5</a>. Notify Tag ":options" ......................................<a href="#page-5">5</a>
<a href="#section-3.6">3.6</a>. Notify Tag ":message" ......................................<a href="#page-5">5</a>
<a href="#section-3.7">3.7</a>. Examples ...................................................<a href="#page-6">6</a>
<a href="#section-3.8">3.8</a>. Requirements on Notification Methods Specifications ........<a href="#page-7">7</a>
<a href="#section-4">4</a>. Test valid_notify_method ........................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Test notify_method_capability ...................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Modifier encodeurl to the 'set' Action .........................<a href="#page-10">10</a>
<a href="#section-7">7</a>. Interactions with Other Sieve Actions ..........................<a href="#page-11">11</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-13">13</a>
<a href="#section-9.1">9.1</a>. Registration of Sieve Extension ...........................<a href="#page-13">13</a>
<a href="#section-9.2">9.2</a>. New Registry for Sieve Notification Mechanisms ............<a href="#page-14">14</a>
<a href="#section-9.3">9.3</a>. New Registry for Notification-Capability Parameters .......<a href="#page-14">14</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-15">15</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-16">16</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-16">16</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-16">16</a>
<span class="grey">Melnikov, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This is an extension to the Sieve language defined by [<a href="#ref-Sieve" title=""Sieve: An Email Filtering Language"">Sieve</a>] 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 for the
portability of scripts that use notifications, implementation of the
[<a href="#ref-MailTo" title=""Sieve Notification Mechanism: mailto"">MailTo</a>] method is mandatory. Other available methods shall depend
upon the implementation and configuration of the system.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
Conventions for notations are as in [<a href="#ref-Sieve" title=""Sieve: An Email Filtering Language"">Sieve</a>], Section 1.1, including
the use of [<a href="#ref-ABNF" title=""Augmented BNF for Syntax Specifications: ABNF"">ABNF</a>].
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 [<a href="#ref-Kwds" title=""Key words for use in RFCs to Indicate Requirement Levels"">Kwds</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Capability Identifier</span>
The capability string associated with the extension defined in this
document is "enotify".
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Notify Action</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Notify Action Syntax and Semantics</span>
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 <a href="#section-3.2">Section 3.2</a>).
However, all content specified in the ":message" parameter SHOULD be
included.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Notify Parameter "method"</span>
The "method" positional parameter identifies the notification method
that will be used; it is a URI [<a href="#ref-URI" title=""Uniform Resource Identifier (URI): Generic Syntax"">URI</a>]. For example, the notification
method can be a tel URI [<a href="#ref-TEL-URI" title=""The tel URI for Telephone Numbers"">TEL-URI</a>] with a phone number to send SMS
messages to, or an XMPP [<a href="#ref-XMPP" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">XMPP</a>] URI containing an XMPP identifier
[<a href="#ref-XMPP-URI" title=""Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)"">XMPP-URI</a>].
<span class="grey">Melnikov, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
The supported URI values will be site-specific, but support for the
[<a href="#ref-MailTo" title=""Sieve Notification Mechanism: mailto"">MailTo</a>] method is REQUIRED in order to ensure interoperability. If
a URI schema is specified that the implementation does not support,
the notification MUST cause an error condition at run time. 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. Invalid URI syntax or an
unsupported URI extension MUST cause an error. An implementation MAY
enforce other semantic restrictions on URIs -- for example, to
restrict phone numbers in a tel: URI to a particular geographical
region -- and will treat violations of such semantic restrictions as
errors.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Notify Tag ":from"</span>
A ":from" tag 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" tag is specified.
In order to minimize/prevent forgery of the author value,
implementations SHOULD impose restrictions on what values can be
specified in a ":from" tag. For example, an implementation may
restrict this value to be a member of a list of known author
addresses or to belong to a particular domain. It is suggested that
values that don't satisfy such restrictions simply be ignored rather
than causing the "notify" action to fail.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Notify Tag ":importance"</span>
The ":importance" tag specifies the importance of quick delivery of
the notification, as perceived by the Sieve script owner. 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 MAY 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
<span class="grey">Melnikov, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
herself as "busy", a notification method can require that a
notification with importance of "3" is not to be sent; however, the
user might 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, <a href="#section-3.6">Section 3.6</a>,
if one is not provided.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Notify Tag ":options"</span>
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>"
where optionname has the following ABNF [<a href="#ref-ABNF" title=""Augmented BNF for Syntax Specifications: ABNF"">ABNF</a>]:
l-d = ALPHA / DIGIT
l-d-p = l-d / "." / "-" / "_"
optionname = l-d *l-d-p
value = *(%x01-09 / %x0B-0C / %x0E-FF)
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Notify Tag ":message"</span>
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 otherwise specified
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 [<a href="#ref-Variables" title=""Sieve Extension: Variables"">Variables</a>], as
shown in the examples below.
<span class="grey">Melnikov, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Examples</span>
Example 1:
require ["enotify", "fileinto", "variables"];
if header :contains "from" "[email protected]" {
notify :importance "1"
:message "This is probably very important"
"mailto:[email protected]";
# Don't send any further notifications
stop;
}
if header :contains "to" "[email protected]" {
# :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:[email protected]";
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}";
}
<span class="grey">Melnikov, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
notify :message "${from_addr}${env_from}: ${subject}"
"mailto:[email protected]";
}
Example 3:
require ["enotify", "variables"];
set "notif_method"
"xmpp:[email protected]?message;subject=SIEVE;body=You%20got%20mail";
if header :contains "subject" "Your dog" {
set "notif_method" "tel:+14085551212";
}
if header :contains "to" "[email protected]" {
set "notif_method" "";
}
if not string :is "${notif_method}" "" {
notify "${notif_method}";
}
if header :contains "from" "[email protected]" {
# :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}"
"tel:+14085551212";
}
}
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Requirements on Notification Methods Specifications</span>
This section describes requirements for documents that define
specific Sieve notification methods.
Notification mechanisms MUST NOT add new Sieve tags to the "notify"
action.
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 that
<span class="grey">Melnikov, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
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 that can only transmit timestamps in the
textual message MAY include them in the textual message.
A notification MUST 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 with 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, <a href="#section-5">Section 5</a>, in particular for the
"online" notification-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 MAY be silently ignored. Documents describing
notification methods SHOULD describe how retries, throttling,
duplicate suppression (if any), etc. are to be handled by
implementations.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Test valid_notify_method</span>
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
valid both syntactically (including URI parameters) and semantically
<span class="grey">Melnikov, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
(including implementation-specific semantic restrictions). 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;
}
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Test notify_method_capability</span>
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 parameter 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, <a href="#section-4">Section 4</a>) 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 is not known to the Sieve
interpreter. 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 using the procedure defined in
<a href="#section-9.3">Section 9.3</a>.
The "relational" extension [<a href="#ref-Relational" title=""Sieve Extension: Relational Tests"">Relational</a>] 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.
<span class="grey">Melnikov, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
For the "online" notification-capability, the
notify_method_capability test can match one of the following key-list
values:
o "yes" - the entity identified by the notification-uri can receive
a notify notification immediately. Note that even after this
value is returned, there is no guarantee that the entity would
actually be able to receive any notification immediately or even
receive it at all. Transport errors, recipient policy, etc. can
prevent that.
o "no" - the entity identified by the notification-uri is not
currently available to receive an immediate notification.
o "maybe" - the Sieve interpreter can't determine if the entity
identified by the notification-uri is online or not.
Example 5:
require ["enotify"];
if notify_method_capability
"xmpp:[email protected]?message;subject=SIEVE"
"Online"
"yes" {
notify :importance "1" :message "You got mail"
"xmpp:[email protected]?message;subject=SIEVE";
} else {
notify :message "You got mail" "tel:+14085551212";
}
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Modifier encodeurl to the 'set' Action</span>
Usage: ":encodeurl"
When the Sieve script specifies both "variables" [<a href="#ref-Variables" title=""Sieve Extension: Variables"">Variables</a>] and
"enotify" capabilities in the "require", a new "set" action modifier
(see [<a href="#ref-Variables" title=""Sieve Extension: Variables"">Variables</a>]) ":encodeurl" becomes available to Sieve scripts.
This modifier performs percent-encoding of any octet in the string
that doesn't belong to the "unreserved" set (see [<a href="#ref-URI" title=""Uniform Resource Identifier (URI): Generic Syntax"">URI</a>]). The
percent-encoding procedure is described in [<a href="#ref-URI" title=""Uniform Resource Identifier (URI): Generic Syntax"">URI</a>].
The ":encodeurl" modifier has precedence 15.
<span class="grey">Melnikov, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
Example 6:
require ["enotify", "variables"];
set :encodeurl "body_param" "Safe body&evil=evilbody";
notify "mailto:[email protected]?body=${body_param}";
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Interactions with Other Sieve Actions</span>
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.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Security considerations are discussed in [<a href="#ref-Sieve" title=""Sieve: An Email Filtering Language"">Sieve</a>]. 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 or modify parts of valid notifications with some
notification methods.
Forgery of the ":importance" value (for example, by unauthorized
script modification) can potentially result in slowdown in
notification delivery.
Note that some components of notifications should not be trusted.
For example, the timestamp field can be easily forged or modified
when some notification transports are used. Even if the timestamp is
believed to be correct by the sender and is not modified in transit,
it might be misleading on the receiving system due to clock
differences.
<span class="grey">Melnikov, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
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 the 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. Also, allowing a
single script to notify multiple destinations can be used as a means
of amplifying the number of messages in an attack. Moreover, if loop
detection is not properly implemented, it may be possible to set up
exponentially growing notification loops. Accordingly, Sieve
notification methods:
1. MUST provide mechanisms for avoiding notification loops.
2. MUST provide the means for administrators to limit the ability of
users to abuse notify. In particular, it MUST be possible to
limit the number of "notify" actions a script can perform.
Additionally, if no use cases exist for using "notify" with
multiple destinations, this limit SHOULD be set to 1. Additional
limits, such as the ability to restrict "notify" to local users,
MAY also be implemented.
3. MUST provide facilities to log the use of "notify" in order to
facilitate tracking down abuse.
4. MAY use script analysis to determine whether or not a given
script can be executed safely. While the Sieve language is
sufficiently complex so that full analysis of all possible
scripts is computationally infeasible, the majority of real-world
scripts are amenable to analysis. For example, an implementation
might allow scripts that it has determined to be safe to run
unhindered, block scripts that are potentially problematic, and
subject unclassifiable scripts to additional auditing and
logging.
Allowing "notify" action at all may not be appropriate in situations
where Sieve scripts are associated with email accounts that are
freely-available and/or not trackable to a human who can be held
accountable for creating message bombs or other abuse.
Implementations that construct URIs internally from various notify
parameters MUST make sure that all components of such URIs are
properly percent-encoded (see [<a href="#ref-URI" title=""Uniform Resource Identifier (URI): Generic Syntax"">URI</a>]). In particular, this applies to
values of the ":from" and ":message" tagged arguments and may apply
to the ":options" values.
<span class="grey">Melnikov, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
Header/envelope tests [<a href="#ref-Sieve" title=""Sieve: An Email Filtering Language"">Sieve</a>], together with Sieve variables, can be
used to extract the list of users to receive notifications from the
incoming email message or its envelope. This is potentially quite
dangerous, as this can be used for denial-of-service attacks on
recipients controlled by the message sender. For this reason,
implementations SHOULD NOT allow the use of variables containing
values extracted from the email message in the "method" parameter to
the "notify" action. Note that violation of this SHOULD NOT may
result in the creation of an open relay, i.e., any sender would be
able to create specially crafted email messages that would result in
notifications delivered to recipients under the control of the
sender. In the worst case, this might result in financial loss by
the user controlling the Sieve script and/or by recipients of
notifications (e.g., if a notification is an SMS message).
Note that the last SHOULD NOT is not a generic prohibition of use of
variables in the "notify" action, as controlling the target of a
notification by extracting it from user-owned data stores (such as
user's Lightweight Directory Access Protocol (LDAP) entry) is
considered to be useful.
It is imperative that whatever implementations use to store the user-
defined filtering scripts protect them from unauthorized
modification, to preserve the integrity of the mail system. An
attacker who can modify a script can cause mail to be discarded,
rejected, or forwarded to an unauthorized recipient. In addition,
it's possible that Sieve scripts might expose private information,
such as mailbox names or email addresses of favored (or disfavored)
correspondents. Because of that, scripts SHOULD also be protected
from unauthorized retrieval.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Registration of Sieve Extension</span>
To: [email protected]
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 tests:
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 has been added to the list of Sieve extensions
available from <a href="http://www.iana.org/">http://www.iana.org/</a>.
<span class="grey">Melnikov, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. New Registry for Sieve Notification Mechanisms</span>
IANA has created a new registry for Sieve notification mechanisms.
This registry contains both vendor-controlled notification mechanism
names (beginning with "vnd.") and IETF-controlled notification
mechanism names. Vendor-controlled notification mechanism names have
the format as defined in the following paragraph and may be
registered on a "First Come First Served" basis [<a href="#ref-IANA-GUIDELINES" title="">IANA-GUIDELINES</a>], by
applying to IANA with the form specified later in this section.
Registration of notification mechanisms that do not begin with "vnd."
are registered using a "Specification Required" policy
[<a href="#ref-IANA-GUIDELINES" title="">IANA-GUIDELINES</a>].
Vendor-controlled notification mechanism names MUST have the form
"vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
specified in the Application Configuration Access Protocol (ACAP)
Vendor Subtree registry [<a href="#ref-ACAP" title=""ACAP -- Application Configuration Access Protocol"">ACAP</a>].
This defines the template for a new registry for Sieve notification
mechanisms, which has been created and is available from
<a href="http://www.iana.org/">http://www.iana.org/</a>. There are no initial entries for this
registry.
To: [email protected]
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. Different mechanisms MUST use different
URI schema.]
Mechanism-specific options: [the names of any Sieve notify options
(as used in the ":options" parameter) that are specific to this
mechanism, or "none"]
Permanent and readily available reference: [the RFC number or an URL
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]
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. New Registry for Notification-Capability Parameters</span>
IANA has created a new registry for the notification-capability
parameters of the notify_method_capability test. This registry
contains both vendor-controlled notification-capability values
(beginning with "vnd.") and IETF-controlled notification-capability
values. Vendor-controlled notification-capability values have the
format as defined in the following paragraph and may be registered on
a "First Come First Served" basis [<a href="#ref-IANA-GUIDELINES" title="">IANA-GUIDELINES</a>], by applying to
IANA with the form specified later in this section. Registration of
<span class="grey">Melnikov, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
notification-capability values that do not begin with "vnd." are
registered using the "Specification Required" policy
[<a href="#ref-IANA-GUIDELINES" title="">IANA-GUIDELINES</a>].
Vendor-controlled notification-capability values MUST have the form
"vnd.<vendor-name>.<capability-name>", where <vendor-name> is as
specified in the ACAP Vendor Subtree registry [<a href="#ref-ACAP" title=""ACAP -- Application Configuration Access Protocol"">ACAP</a>].
The following template must be used for registering notification-
capability parameters:
To: [email protected]
Subject: Registration of a new notification-capability parameter
Capability name: [the name of the notification-capability]
Description: [an explanation of the purpose of the notification-
capability]
Syntax: [formal definition of allowed values and their syntax]
Permanent and readily available reference(s): [the RFC number(s) or
an URL of the document that defines this notification mechanism]
Contact information: [the name and email address of the technical
contact for information about this mechanism]
Below is the registration form for the "online" notification-
capability:
To: [email protected]
Subject: Registration of a new notification-capability parameter
Capability name: online
Description: Returns whether the entity identified by the
notification-uri parameter to the notify_method_capability test
can receive a notify notification immediately.
Syntax: Can contain one of three values: "yes", "no", and, "maybe".
Values MUST be in lowercase.
Permanent and readily available reference(s): This RFC
Contact information: The Sieve discussion list
<ietf-mta-filters@imc.org>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
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, Peter Saint-Andre, Sean Turner, Cullen Jennings, and
Pasi Eronen for help with this document.
<span class="grey">Melnikov, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-ABNF">ABNF</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", STD 68,
<a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-Kwds">Kwds</a>] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
March 1997.
[<a id="ref-MailTo">MailTo</a>] Leiba, B. and M. Haardt, "Sieve Notification
Mechanism: mailto", <a href="./rfc5436">RFC 5436</a>, January 2009.
[<a id="ref-Relational">Relational</a>] Segmuller, W. and B. Leiba, "Sieve Extension:
Relational Tests", <a href="./rfc5231">RFC 5231</a>, January 2008.
[<a id="ref-Sieve">Sieve</a>] Guenther, P., Ed. and T. Showalter, Ed., "Sieve:
An Email Filtering Language", <a href="./rfc5228">RFC 5228</a>,
January 2008.
[<a id="ref-URI">URI</a>] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic
Syntax", STD 66, <a href="./rfc3986">RFC 3986</a>, January 2005.
[<a id="ref-Variables">Variables</a>] Homme, K., "Sieve Extension: Variables", <a href="./rfc5229">RFC 5229</a>,
January 2008.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-ACAP">ACAP</a>] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", <a href="./rfc2244">RFC 2244</a>,
November 1997.
[<a id="ref-IANA-GUIDELINES">IANA-GUIDELINES</a>] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
<a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>, May 2008.
[<a id="ref-TEL-URI">TEL-URI</a>] Schulzrinne, H., "The tel URI for Telephone
Numbers", <a href="./rfc3966">RFC 3966</a>, December 2004.
[<a id="ref-XMPP">XMPP</a>] Saint-Andre, Ed., P., "Extensible Messaging and
Presence Protocol (XMPP): Core", <a href="./rfc3920">RFC 3920</a>,
October 2004.
<span class="grey">Melnikov, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc5435">RFC 5435</a> Sieve Extension: Notifications January 2009</span>
[<a id="ref-XMPP-URI">XMPP-URI</a>] Saint-Andre, P., "Internationalized Resource
Identifiers (IRIs) and Uniform Resource
Identifiers (URIs) for the Extensible Messaging
and Presence Protocol (XMPP)", <a href="./rfc5122">RFC 5122</a>,
February 2008.
Authors' Addresses
Alexey Melnikov (editor)
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: [email protected]
Barry Leiba (editor)
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
US
Phone: +1 914 784 7941
EMail: [email protected]
Wolfgang Segmuller
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
US
Phone: +1 914 784 7408
EMail: [email protected]
Tim Martin
Endless Crossword
672 Haight st.
San Francisco, CA 94117
US
Phone: +1 510 260-4175
EMail: [email protected]
Melnikov, et al. Standards Track [Page 17]
Annotations
Select text to annotate