Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)
Extracted elements (22)
The ':importance' tag is mapped to an XMPP SHIM 'Urgency' header rather than having mandatory behavior, because the tag has no special meaning for XMPP notifications and implementations may choose to handle it differently or include it in the message body instead.
The XMPP 'from' attribute MUST NOT be generated from the Sieve ':from' tag to preserve the identity of the notification service; the ':from' value is instead conveyed via a SHIM 'Resent-From' header to avoid spoofing the XMPP sender identity.
The notify_method_capability test for 'online' should only return 'yes' if the requesting entity is authorized to know the XMPP entity's presence (e.g., via explicit presence subscription per XMPP-IM); otherwise 'maybe' should be returned.
An implementation MUST ignore any XMPP URI action or key it does not understand, processing the URI as if the unknown action or key were not present. It is RECOMMENDED to support the XMPP 'message' query type with 'body' and 'subject' keys.
An implementation MUST NOT include any extraneous information not specified in parameters to the notify action.
An implementation SHOULD NOT retry delivery if it receives an XMPP error of type 'auth' or 'cancel', MAY retry for 'wait' errors, and MAY retry for 'modify' errors only with appropriate modifications. The number of retries SHOULD be limited to between 3 and 10.
For the notify_method_capability test for 'online', an implementation SHOULD return 'yes' if it has knowledge of an active XMPP presence session for the notification URI; otherwise it SHOULD return 'maybe'.
If the ':from' tag is included, it MUST be an electronic address conforming to the 'Mailbox' rule in RFC 5321. If transformed to XMPP syntax, it MUST be encapsulated as the value of an XMPP SHIM header named 'Resent-From'.
If the ':message' tag is included, that string MUST be transformed into the XML character data of an XMPP <body/> element, generated according to Section 3.6 of the NOTIFY specification.
If the Sieve notify ':message' tag is included, it MUST be mapped to the XMPP <body/> element, overriding any 'body' key in the XMPP URI.
The 'method' parameter MUST be a URI conforming to the xmpp URI scheme that identifies an XMPP account associated with the email inbox. The processing application MUST extract an XMPP address from the URI per RFC 5122 rules, and the resulting address MUST be encapsulated as the value of the XMPP 'to' attribute.
The 'method' parameter value MUST be a URI (not an IRI) per RFC 3986, and XMPP URI generation rules from RFC 5122 MUST be followed. All data sent over XMPP MUST be encoded in UTF-8.
The 'method' URI SHOULD NOT include an authority component or fragment identifier component, though it MAY include a resource identifier and/or query component.
The value of the XMPP 'from' attribute MUST NOT be generated from the Sieve ':from' tag; it SHOULD be the XMPP address of the notification service or the entity to be notified.
The XMPP <message/> stanza MUST include a <body/> child element. The ':message' tag value takes precedence over the 'body' key from the XMPP URI query component; otherwise, the 'body' key value SHOULD be used, or fallback configurable text.
The XMPP notification MUST be an XMPP <message/> stanza. The 'type' attribute MUST be 'headline' or 'normal', and the stanza MUST include a <body/> child element.
The ':importance' tag MAY be transformed into an XMPP SHIM header named 'Urgency', where importance '1' maps to 'high', '2' to 'medium', and '3' to 'low'. This mapping is optional and the tag has no special mandatory meaning for the xmpp notification mechanism.
The XMPP <message/> stanza SHOULD include a URI hint for locating the email message, encapsulated in a <url/> child of an <x/> element in the 'jabber:x:oob' namespace. The URI SHOULD be an IMAP URL but MAY be HTTP or POP3.
RFC 5437 registers the 'xmpp' Sieve notification mechanism with IANA. The mechanism URI is RFC 5122, there are no mechanism-specific options, and the registration contact is Peter Saint-Andre at [email protected].
Implementations MUST conform to the security considerations in the NOTIFY, SIEVE, and XMPP specifications. Sending a notification can be comparable to forwarding mail, so care must be taken to avoid sending confidential information into an insecure environment.
The Sieve engine MUST NOT use a user's presence information when processing scripts on behalf of a script owner other than the user, unless the engine has explicit knowledge that the script owner is authorized to know the user's presence.
The XMPP notification service MUST NOT auto-reply to XMPP messages it receives, to prevent notification loops caused by auto-replies. XMPP itself prevents forwarding-based loops since it does not support message forwarding between addresses.