From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6468.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc6468.txt (limited to 'doc/rfc/rfc6468.txt') diff --git a/doc/rfc/rfc6468.txt b/doc/rfc/rfc6468.txt new file mode 100644 index 0000000..9a8508c --- /dev/null +++ b/doc/rfc/rfc6468.txt @@ -0,0 +1,563 @@ + + + + + + +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. + + + + + + + + +Melnikov, et al. Standards Track [Page 1] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + +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 + + 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]. + +1.2. 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]. + + + + + + + +Melnikov, et al. Standards Track [Page 2] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + +2. 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. + +2.1. 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:romeo@example.com;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. + +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, 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. + + + + +Melnikov, et al. Standards Track [Page 3] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + + See Section 22 of RFC 3261 [RFC3261] for more information about SIP + authentication. + +2.3. 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. + +2.4. 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. + +2.5. 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]. + + + + + + + + +Melnikov, et al. Standards Track [Page 4] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + +2.6. 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). + +2.7. 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. + +3. Examples + + In the following examples, the sender of the email has an address of + juliet@example.org, the entity to be notified has a SIP address of + , and the notification service has a SIP + address . + +3.1. Example 1 + + The following is a basic Sieve notify action with only a method: + + notify "sip:romeo@example.com;method=MESSAGE" + + + + + + +Melnikov, et al. Standards Track [Page 5] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + + The resulting SIP MESSAGE request might be as follows: + + 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 + + wrote: Contact me immediately! + + In the example above, the email message was received from + juliet@example.com and had "Subject: Contact me immediately!" + +3.2. 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:romeo@example.com;method=MESSAGE?subject=SIEVE" + + 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! + + + + + + + + + + +Melnikov, et al. Standards Track [Page 6] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + +4. 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. + +5. 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 + + + +Melnikov, et al. Standards Track [Page 7] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + + 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 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 . + + + + + +Melnikov, et al. Standards Track [Page 8] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + + 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. + + + + + + +Melnikov, et al. Standards Track [Page 9] + +RFC 6468 Sieve Notification: SIP MESSAGE February 2012 + + + [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 + + + + + + +Melnikov, et al. Standards Track [Page 10] + -- cgit v1.2.3