Sieve Notification Mechanism: SIP MESSAGE
Extracted elements (21)
SIP authentication is performed in the context of the Sieve engine (not the end user) to avoid the security risk of the Sieve engine having access to end-user SIP authentication credentials. The engine may use server-wide credentials or per-user credentials for auditing.
Using the ':message' tag is preferred over the URI 'body' parameter because it integrates naturally with Sieve script syntax, supports variable substitutions (RFC 5229), and allows non-ASCII characters to be included directly in UTF-8 without URI encoding.
Only SIP and SIPS URI schemes are defined as Sieve notification methods in this document; future extensions might define other Sieve notification methods using SIP through other URI schemes or using SIP methods other than MESSAGE.
All SIP authentication, including challenges and client certificates, SHOULD be done in the context of the Sieve engine rather than using end-user SIP credentials, to avoid security issues.
An implementation MUST ignore any URI parameter it does not understand, processing the URI as if the parameter were not present.
An implementation MUST NOT include any extraneous information not specified in parameters to the notify action.
An implementation of the SIP MESSAGE notification method SHOULD NOT modify the final notification text, except to comply with SIP MESSAGE length limits.
If both the ':message' tag and the URI 'body' parameter are present, the Sieve processing MUST ignore the 'body' parameter.
If the ':message' tag is included, it MUST be transformed into the SIP MESSAGE body with Content-Type 'text/plain' and CHARSET='UTF-8'.
Implementations MUST comply with the SIP MESSAGE size limits as discussed in Section 8 of RFC 3428.
The 'method' parameter MUST be a URI conforming to the SIP or SIPS URI scheme and MUST include the URI parameter 'method' with the value 'MESSAGE'.
The processing application MUST form a SIP MESSAGE request according to the rules specified in RFC 3261.
The value of the ':from' tag MUST use SIP 'From' header field syntax; if valid, the notification SHOULD include the 'From' SIP header field containing that value.
The ':importance' tag MAY be transformed into the SIP 'Priority' header field: importance '1' maps to 'urgent', '2' to 'normal', and '3' to 'non-urgent'. There is no mapping to the SIP value 'emergency'.
The notify_method_capability test for 'online' will frequently return 'maybe' for the SIP MESSAGE notification method, as it is generally impossible to tell in advance whether the recipient is online and able to receive a SIP MESSAGE.
The policy for retrying delivery of failed SIP MESSAGE notifications is specified by RFC 3261 based on the SIP error code returned; unlike some other Sieve notification methods, retries are controlled by the SIP protocol itself.
This document registers a new Sieve notification mechanism named 'sip-message' with mechanism URI SIP/SIPS (as specified in RFC 3261) in the IANA Sieve notification mechanisms registry at http://www.iana.org/assignments/sieve-notification.
As required by RFC 3428, user agents supporting SIP MESSAGE MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms; without these, man-in-the-middle attacks can expose credentials and message content.
If SIP MESSAGE requests are billed per message or deplete a user's quota, an attacker sending many notifications could cause significant expense to the recipient; users should be warned of potential costs when setting up SIP MESSAGE notifications.
Notification loops are prevented by the SIP protocol itself; however, in scenarios where a SIP MESSAGE notification triggers an email that generates another notification, rate detection and limiting may be necessary to prevent loops.
Sending a notification can be comparable to forwarding mail; care must be taken not to send confidential information (such as sender and subject) into an insecure environment. SIPS URIs or omitting sensitive fields may be required depending on the environment.