RFC6468
Internet Engineering Task Force (IETF) A. Melnikov Request for Comments: 6468 Isode Limited Category: Standards Track B. Leiba ISSN: 2070-1721 K. Li
Huawei Technologies
February 2012
Sieve Notification Mechanism: SIP MESSAGE
Abstract
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6468.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Contents
Introduction
Overview
The Notify extension RFC5435 to the Sieve mail filtering language RFC5228 is a framework for providing notifications by employing URIs that specify the notification mechanism. (See RFC 5435 for details about the motivation and use cases.) This document defines how Session Initiation Protocol (SIP) URIs RFC3261 are used to generate notifications via SIP MESSAGE RFC3428.
Terminology
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 RFC 2119 RFC2119.
This document inherits terminology from the Sieve email filtering language RFC5228, the Sieve Notify extension RFC5435, and RFC 3261 RFC3261.
Definition
The SIP MESSAGE mechanism defined in this document results in the sending of a SIP MESSAGE request to notify a recipient about an email message.
Notify Parameter "method"
The "method" parameter MUST be a URI that conforms to the SIP or SIPS URI scheme (as specified in RFC 3261 RFC3261) and that identifies a SIP or SIPS recipient of the notification. The URI MAY include the resource identifier portion of a SIP address and URI parameters. The URI MUST include the URI parameter "method", with the value "MESSAGE". Example:
notify "sip:[email protected];method=MESSAGE" --------------
Note that future specifications might extend this document and define Sieve notifications that use SIP methods other than "MESSAGE".
The processing application MUST form a request according to the rules specified in RFC 3261 RFC3261.
Note that other URI schemes can also trigger SIP processing, but only SIP and SIPS are defined here. Future extensions might define other Sieve notification methods that use SIP through other URI schemes.
Notify Tag ":from"
The value of the ":from" tag MUST use the SIP "From" header field syntax; if the ":from" value is specified, has valid syntax, and is valid according to the implementation-specific security checks (see Section 3.3 of Sieve Notify RFC5435), then the notification SHOULD include the "From" SIP header field containing the value of the ":from" notify tag. If the specified value is not valid, then it is ignored.
All SIP authentication, including challenges and client certificates, SHOULD be done in the context of the Sieve engine -- the Sieve engine is the identity being authenticated. This avoids security issues associated with the Sieve engine's having access to the end user's SIP authentication credentials. The Sieve engine MAY use server-wide credentials (including applicable certificates) that are the same for all scripts. Alternatively, it MAY, for auditing purposes, use different sets of Sieve-engine credentials when operating on behalf of different users.
See Section 22 of RFC 3261 RFC3261 for more information about SIP authentication.
Notify Tag ":options"
Handling of the ":options" tag is implementation specific. This document doesn't require presence of any option and doesn't define how options are processed.
Notify Tag ":importance"
The ":importance" tag is intended to convey the importance of the SIP MESSAGE notification, not the importance of the email message that generated the notification. The value of the ":importance" tag MAY, therefore, be transformed into SIP "Priority" header field (in addition to or instead of including it in the body of the message). Note that because the Sieve ":importance" tag only has three values, not all SIP "Priority" values can be represented in the transformation. If this transformation is done, the value of the "Priority" header field MUST be "urgent" if the value of the ":importance" tag is "1", "normal" if the value of the ":importance" tag is "2", and "non-urgent" if the value of the ":importance" tag is "3". There is no mapping to the SIP value "emergency", nor to any additional values that might be defined.
Notify tag ":message"
If the ":message" tag is included, it MUST be transformed into the message body of a SIP MESSAGE, which MUST have Content-Type value of "text/plain" with CHARSET="UTF-8". If the ":message" tag is not included, a default message will be used. The values of the "From" and "Subject" header fields of the triggering email message are particularly useful to users receiving notifications, and including them in the default message is generally a good idea, as shown in Section 3.2 below. (However, see the Security Considerations, Section 5.) The default body might also include the value of the ":importance" tag, if one is specified.
Note that in no case is the actual triggering message body included in the notification.
Implementations MUST comply with the SIP MESSAGE size limits, as discussed in Section 8 of RFC 3428 RFC3428.
Other Definitions
An implementation MUST ignore any URI parameter it does not understand (the URI MUST be processed as if the parameter were not present). The URI "body" parameter can serve the same purpose as the Sieve ":message" tag, providing the message body of the SIP MESSAGE request. If both are present at the same time, the Sieve processing MUST ignore the "body" parameter.
Using the ":message" tag has advantages over using the "body" parameter. Because the ":message" tag is part of the "notify" statement syntax, it can be easier to include it in a script, and to do things such as variable substitutions RFC5229 with it. It is also easier to include non-ASCII characters in the ":message" tag because such characters have to be encoded if they are within URI parameters, but can be included directly in UTF-8 in Sieve tag values.
The policy for retrying delivery of failed notifications is specified in RFC 3261 RFC3261, according to the SIP error code returned during an attempt to deliver a SIP notification. In other words, unlike the situation with some other Sieve notification methods, retries for SIP MESSAGE notifications are controlled by the notification protocol itself (SIP).
Test notify_method_capability
Absent use of SIP extensions such as RFC3856, it is impossible to tell in advance whether the notification recipient is online and able to receive a SIP MESSAGE. Expect the notify_method_capability test for "online" to frequently return "maybe" for this notification method.
Examples
In the following examples, the sender of the email has an address of [email protected], the entity to be notified has a SIP address of <sip:[email protected]>, and the notification service has a SIP address <sip:[email protected]>.
Example 1
The following is a basic Sieve notify action with only a method:
notify "sip:[email protected];method=MESSAGE"
The resulting SIP MESSAGE request might be as follows:
MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:[email protected];tag=32328 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Date: Sat, 13 Nov 2010 23:29:00 GMT Content-Type: text/plain Content-Length: 53
<[email protected]> wrote: Contact me immediately!
In the example above, the email message was received from [email protected] and had "Subject: Contact me immediately!"
Example 2
The following is a more advanced Sieve notify action with a method, importance, subject, and message:
notify :importance "1"
:message "You got new mail!"
"sip:[email protected];method=MESSAGE?subject=SIEVE"
MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:[email protected];tag=32328 To: sip:[email protected] Subject: SIEVE Priority: urgent Call-ID: [email protected] CSeq: 1 MESSAGE Date: Fri, 08 Apr 2011 06:54:00 GMT Content-Type: text/plain Content-Length: 19
You got new mail!
Requirements Conformance Checklist
Section 3.8 of Sieve Notify RFC5435 specifies a set of requirements for Sieve notification methods. A checklist is provided here to show conformance of the SIP MESSAGE notification method.
1. No new Sieve tags have been added to the "notify" action.
2. An implementation of the SIP MESSAGE notification method SHOULD
NOT modify the final notification text, except to comply with
SIP MESSAGE length limits. Deployments MAY make operational
decisions about notification text, for reasons such as privacy
and confidentiality. Modification of characters themselves
should not be necessary, since the SIP MESSAGE body is encoded
in UTF-8 RFC3629.
3. An implementation MAY ignore parameters specified in the
":importance" and ":options" tags.
4. A default message is suggested in Section 2.5.
5. A notification sent via the SIP MESSAGE notification method MAY
include the Date header field containing the date-time of the
moment when the SIP MESSAGE notification was generated.
6. The notification source is identified through the SIP "From:"
header field, via the Sieve Notify ":from" tag (see
Section 2.2).
7. An implementation MUST NOT include any extraneous information
not specified in parameters to the notify action.
8. An implementation MUST ignore any URI parameters it does not
understand (i.e., the URI MUST be processed as if the action or
parameter were not present). See Section 2.6 for more details.
9. The notify_method_capability test for the "online" notification-
capability behaves as described in Section 2.7.
10. The policy for retrying delivery of failed notifications is
specified in RFC 3261 RFC3261, as noted in Section 2.6.
Security Considerations
Depending on the information included, sending a notification can be, from a confidentiality point of view, comparable to forwarding mail to the notification recipient. Care must be taken when automatically forwarding information, such as the sender and the subject of a
message, to ensure that confidential information is not sent into an insecure environment or over an insecure channel. Depending upon the environment, this might entail using SIPS URIs, not sending information about the subject and/or the sender, or applying heuristics to the message to determine what may be sent.
As required by RFC 3428, user agents that support the SIP MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms. At the time of this writing, there is not widespread deployment of SIP end-to-end security, so there can be cases where it is not possible to use it, even though it is implemented on one end. It's important to note that such situations are open to exposure of user credentials, message content, and other private information via man-in-the-middle and other passive attacks.
The Sieve Notify extension specifies that notification methods MUST provide mechanisms for avoiding notification loops. In this case, the SIP protocol itself prevents loops, and no explicit work is needed within the notification mechanism. In situations where a SIP MESSAGE notification can result in an email message that could generate another SIP MESSAGE notification, loop prevention through rate detection and limiting might be necessary. An implementation might detect too many notifications within a given time period, too many triggered by a particular sender, too many with the same subject, or the like, and shut off the affected notifications for a period of time or until manual intervention turns them back on.
If SIP MESSAGE requests might be billed by the message, or the use of them might deplete a user's quota of messages, notification by this mechanism can present a situation where someone using a large number of messages to generate a large number of notifications will cause a significant expense to the recipient. Because there is no external way an attacker can tell that this is the case, such an attack would likely be a random or nuisance attack. Nevertheless, users might be warned of potential costs when they set up SIP MESSAGE notifications.
Other security considerations given in the Sieve base specification RFC5228, the Sieve Notify extension RFC5435, and RFC 3261 RFC3261 are also relevant to this document.
IANA Considerations
The following template provides the IANA registration of the Sieve notification mechanism specified in this document. This information has been added to the list of Sieve notification mechanisms maintained at <http://www.iana.org/assignments/sieve-notification>.
To: [email protected] Subject: Registration of new Sieve notification mechanism Mechanism name: sip-message Mechanism URI: SIP/SIPS as specified in RFC 3261 RFC3261 Mechanism-specific options: none Standards Track/IESG-approved experimental RFC number: RFC6468 Person and email address to contact for further information:
See authors of RFC6468
Acknowledgements
This document borrows some text from RFC 5437 RFC5437.
Henning Schulzrinne ([email protected]) was a special contributor to this document, with early work and reviews.
The authors would like to thank Adam Roach and Eric Burger for their helpful comments. Ben Campbell did a very thorough RAI-team review, as well as a follow-up review to make sure we resolved all of his issues satisfactorily. This document was greatly improved by their input.
Qian Sun contributed text to this document.
References
Normative References
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC3261 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
RFC3428 Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
RFC3629 Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
RFC5228 Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008.
RFC5435 Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"Sieve Email Filtering: Extension for Notifications",
RFC 5435, January 2009.
Informative References
RFC3856 Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
RFC5229 Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, January 2008.
RFC5437 Saint-Andre, P. and A. Melnikov, "Sieve Notification
Mechanism: Extensible Messaging and Presence Protocol
(XMPP)", RFC 5437, January 2009.
Authors' Addresses
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
EMail: [email protected] URI: http://www.melnikov.ca/
Barry Leiba Huawei Technologies
Phone: +1 646 827 0648 EMail: [email protected] URI: http://internetmessagingtechnology.org/
Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R. China
Phone: +86-755-28974289 EMail: [email protected]
