RFC 6468

RFC 6468: Sieve Notification Mechanism: SIP MESSAGE 💖

okay so this is RFC 6468 🎀 It's a Standards Track doc, which means it's an official Internet standard, so it's giving serious. Written by A. Melnikov (Isode Limited), B. Leiba, and K. Li (Huawei Technologies). Dated February 2012, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates. ✨

Abstract ✨

tl;dr: this doc is a profile of the Sieve extension for notifications, so notifications can get sent over SIP MESSAGE. 💅

Status of This Memo 📜

This is an Internet Standards Track document. 🔥

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 5741. 🧚

For the current status, errata, and a place to send feedback, go to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read them carefully, because they explain your rights and restrictions. 🫶 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🙈

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Definition . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.1.  Notify Parameter "method"  . . . . . . . . . . . . . . . .  3
  2.2.  Notify Tag ":from" . . . . . . . . . . . . . . . . . . . .  3
  2.3.  Notify Tag ":options"  . . . . . . . . . . . . . . . . . .  4
  2.4.  Notify Tag ":importance" . . . . . . . . . . . . . . . . .  4
  2.5.  Notify tag ":message"  . . . . . . . . . . . . . . . . . .  4
  2.6.  Other Definitions  . . . . . . . . . . . . . . . . . . . .  5
  2.7.  Test notify_method_capability  . . . . . . . . . . . . . .  5
3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . . . .  5
  3.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . . .  6
4.  Requirements Conformance Checklist . . . . . . . . . . . . . .  7
5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 10

---

1. Introduction 🦋

1.1. Overview 🌸

okay so the Notify extension [RFC5435] to the Sieve mail filtering language [RFC5228] is a framework for sending notifications. You point it at a URI that says which notification mechanism to use. 💖 (Want the motivation and use cases? RFC 5435 has the tea.) This doc spells out how Session Initiation Protocol (SIP) URIs [RFC3261] get used to generate notifications through SIP MESSAGE [RFC3428]. ✨

1.2. Terminology 📚

Here's the key-word situation: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way RFC 2119 [RFC2119] describes. 🎀

This doc inherits its vocabulary from the Sieve email filtering language [RFC5228], the Sieve Notify extension [RFC5435], and RFC 3261 [RFC3261]. 🧚

2. Definition 👑

The SIP MESSAGE mechanism in this doc works by sending a SIP MESSAGE request, which tells a recipient about an email message. 💌

2.1. Notify Parameter "method" 🎯

The "method" parameter MUST be a URI that follows 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:romeo@example.com;method=MESSAGE"
                              --------------

Future specs might extend this doc and define Sieve notifications that use SIP methods other than "MESSAGE". Ooh, exciting. 🔮

The processing application MUST form a request according to the rules specified in RFC 3261 [RFC3261]. 🔥

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. 🌈

2.2. 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, it gets 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 tied to the Sieve engine 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 about SIP authentication. 📖

2.3. Notify Tag ":options" 🎀

Handling of the ":options" tag is implementation specific. This doc doesn't require any option, and it doesn't define how options get processed. 🤷‍♀️

2.4. Notify Tag ":importance" ⭐

The ":importance" tag is meant to convey the importance of the SIP MESSAGE notification, not the importance of the email message that triggered it. 💖 So the value of ":importance" MAY be transformed into the SIP "Priority" header field (in addition to or instead of including it in the message body). The Sieve ":importance" tag only has three values, so not every SIP "Priority" value can be represented in the transformation. 🙈

If this transformation happens, the value of the "Priority" header field MUST be "urgent" if the ":importance" tag is "1", "normal" if it's "2", and "non-urgent" if it's "3". There's no mapping to the SIP value "emergency", nor to any additional values that might get defined. 🚨

2.5. Notify tag ":message" 💌

If the ":message" tag is included, it MUST be transformed into the message body of a SIP MESSAGE, and that body MUST have a Content-Type value of "text/plain" with CHARSET="UTF-8". If the ":message" tag isn't included, a default message gets used. ✨

The values of the "From" and "Subject" header fields of the triggering email message are super useful to the people getting notifications, so putting 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 the actual triggering message body is never included in the notification. Not ever. 🙅‍♀️

Implementations MUST comply with the SIP MESSAGE size limits, as discussed in Section 8 of RFC 3428 [RFC3428]. 📏

2.6. Other Definitions 🧚

An implementation MUST ignore any URI parameter it does not understand (the URI MUST be processed as if that parameter were not present). 🫠 The URI "body" parameter can do the same job 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 some perks over the "body" parameter. Because ":message" is part of the "notify" statement syntax, it's easier to include in a script, and it's easier to do things like variable substitutions [RFC5229] with it. It's also easier to include non-ASCII characters in ":message", because such characters have to be encoded inside URI parameters, but they can go straight in as UTF-8 in Sieve tag values. 🌈

The policy for retrying delivery of failed notifications is in RFC 3261 [RFC3261], based on the SIP error code returned when an attempt to deliver a SIP notification fails. So, unlike some other Sieve notification methods, retries for SIP MESSAGE notifications get controlled by the notification protocol itself (SIP). 🔁

2.7. Test notify_method_capability 🔮

Without SIP extensions like [RFC3856], there's no way to know ahead of time whether the notification recipient is online and able to receive a SIP MESSAGE. 🥺 Expect the notify_method_capability test for "online" to often return "maybe" for this notification method. 🤷‍♀️

3. Examples 🍰

In these examples, the sender of the email has the address juliet@example.org. The entity to be notified has the SIP address <sip:romeo@example.com>, and the notification service has the SIP address <sip:notifier@example.com>. 💕

3.1. Example 1 🎀

Here's a basic Sieve notify action with only a method:

notify "sip:romeo@example.com;method=MESSAGE"

The resulting SIP MESSAGE request might look like this:

MESSAGE sip:romeo@example.com SIP/2.0
Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:notifier@example.com;tag=32328
To: sip:romeo@example.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Date: Sat, 13 Nov 2010 23:29:00 GMT
Content-Type: text/plain
Content-Length: 53

<juliet@example.com> wrote: Contact me immediately!

In that example, the email came from juliet@example.com and had Subject: Contact me immediately!. 😭💜

3.2. Example 2 🌟

Now a fancier Sieve notify action, with a method, importance, subject, and message:

notify :importance "1"
    :message "You got new mail!"
    "sip:romeo@example.com;method=MESSAGE?subject=SIEVE"

And the SIP MESSAGE request for it:

MESSAGE sip:romeo@example.com SIP/2.0
Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:notifier@example.com;tag=32328
To: sip:romeo@example.com
Subject: SIEVE
Priority: urgent
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Date: Fri, 08 Apr 2011 06:54:00 GMT
Content-Type: text/plain
Content-Length: 19

You got new mail!

iconic. the importance of "1" got mapped to Priority: urgent, and the message body came from the ":message" tag. 🌈👑

4. Requirements Conformance Checklist ✨

okay bestie, so Section 3.8 of Sieve Notify [RFC5435] lays out a set of requirements for Sieve notification methods 💅 and this checklist is here to show that the SIP MESSAGE notification method is conforming 🎀

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. 🫶

5. Security Considerations 💀

okay this section is very serious so pay attention 😭

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. 📜

6. IANA Considerations 🌈

the following template is the IANA registration of the Sieve notification mechanism specified in this document 🎀 this info has been added to the list of Sieve notification mechanisms maintained at <http://www.iana.org/assignments/sieve-notification>

To: iana@iana.org
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]

7. Acknowledgements 🫶

This document borrows some text from RFC 5437 [RFC5437].

Henning Schulzrinne (hgs@cs.columbia.edu) 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. 🌸

8. References 📚

8.1. 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.

8.2. 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: Alexey.Melnikov@isode.com
URI:   http://www.melnikov.ca/


Barry Leiba
Huawei Technologies

Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI:   http://internetmessagingtechnology.org/


Kepeng Li
Huawei Technologies
Huawei Base, Bantian, Longgang District
Shenzhen, Guangdong  518129
P.R. China

Phone: +86-755-28974289
EMail: likepeng@huawei.com