Sieve Email Filtering: Extension for Notifications
updated by
- rfc-8580 — Sieve Extension: File Carbon Copy (FCC)
Extracted elements (29)
The mailto notification method is mandated as the one required implementation to ensure portability of Sieve notification scripts across different server environments. Other methods are implementation- and configuration-dependent.
The valid_notify_method test MUST perform exactly the same URI validation as the "method" parameter to the "notify" action, ensuring that script pre-checks are guaranteed to match runtime behavior.
A notification MUST include means to identify/track its origin so that a recipient can stop notifications or contact the sender. This is required to help track misconfigured or abusive notification origins.
If the "method" parameter contains a supported URI schema, the URI MUST be checked for syntactic validity. Invalid URI syntax or an unsupported URI extension MUST cause an error.
If there are errors sending the notification, the Sieve interpreter SHOULD ignore the notification and not retry indefinitely. The interpreter MAY throttle notifications, silently ignoring requests when throttling.
Implementations SHOULD impose restrictions on :from tag values to minimize forgery of the author value (e.g., restricting to known addresses or a particular domain). Values not satisfying restrictions SHOULD be silently ignored rather than failing the action.
Notification mechanisms MUST NOT add new Sieve tags to the "notify" action. Any method-specific behavior must be conveyed through the existing :options parameter.
Support for the mailto notification method (RFC 5436) is REQUIRED to ensure interoperability. If a URI schema is specified that the implementation does not support, the notification MUST cause an error condition at run time.
The entirety of the :message string SHOULD be sent, though implementations MAY shorten it for technical or aesthetic reasons. If :message is absent, a default containing at least the From and Subject header values is RECOMMENDED.
The "notify" action MUST NOT cancel the implicit keep. It is compatible with all other Sieve actions and does not affect their operation. Multiple executed "notify" actions are allowed.
The notify_method_capability test MUST fail unconditionally if the notification-uri is syntactically invalid or specifies an unsupported method, but this MUST NOT cause a script error. It also MUST fail if the notification-capability item is not known to the interpreter.
The capability string for this extension is "enotify". Sieve scripts must require this capability to use the notify action, valid_notify_method test, notify_method_capability test, and the :encodeurl modifier.
The :encodeurl modifier (precedence 15) is available when both "variables" and "enotify" are required. It performs percent-encoding of any octet not in the URI "unreserved" set, as defined in RFC 3986.
The :from tag specifies an author of the notification; its syntax is method-specific. Implementations SHOULD check syntax per the notification method specification and generate an error on syntactically invalid values.
The :importance tag specifies urgency with values "1" (high), "2" (normal, default), and "3" (low). If the notification method does not support importance, this parameter MUST be ignored. Notification methods SHOULD use recipient availability state to filter low-importance notifications.
The "notify" action specifies that a notification should be sent to a user. Its syntax accepts optional tags :from, :importance, :options, and :message, plus a required positional "method" parameter that is a URI identifying the notification method.
The notify_method_capability test retrieves a named capability for a notification URI and matches it against a key-list. The default match type is ":is" and the default comparator is "i;ascii-casemap". The notification-capability parameter is case insensitive.
The "online" notification-capability returns one of three values: "yes" (entity can receive notification immediately), "no" (entity not currently available), or "maybe" (availability unknown). Values MUST be lowercase.
The :options tag sends additional method-specific parameters as a list of "<optionname>=<value>" strings. The optionname ABNF is: l-d = ALPHA / DIGIT; l-d-p = l-d / "." / "-" / "_"; optionname = l-d *l-d-p.
The valid_notify_method test returns true if all notification URIs in the argument list are supported and valid both syntactically (including URI parameters) and semantically. It performs exactly the same validation as the "method" parameter to the "notify" action.
IANA created a new registry for Notification-Capability Parameters used by the notify_method_capability test. Vendor-controlled values ("vnd.<vendor-name>.<capability-name>") are First Come First Served; others require Specification Required. Initial entry is the "online" capability.
IANA created a new registry for Sieve Notification Mechanisms. Vendor-controlled names ("vnd.<vendor-name>.<mechanism-name>") are registered First Come First Served; other names require Specification Required policy. Initial registry is empty.
The "enotify" capability was registered as a Sieve extension. It adds the "notify" action, the valid_notify_method test, the notify_method_capability test, and the :encodeurl set-action modifier.
Implementations SHOULD NOT allow variables derived from the incoming email message (via header/envelope tests) to be used in the "method" parameter, as this can create an open relay allowing any sender to trigger notifications to arbitrary recipients, potentially causing financial loss.
Implementations that construct URIs internally from notify parameters (:from, :message, :options) MUST ensure all URI components are properly percent-encoded per RFC 3986 to prevent injection attacks.
Notification methods MUST provide mechanisms for avoiding notification loops, MUST allow administrators to limit the number of notify actions a script can perform, and MUST provide facilities to log notify usage for abuse tracking.
Sieve scripts that store user filtering rules MUST be protected from unauthorized modification (to prevent mail diversion) and SHOULD be protected from unauthorized retrieval (as scripts may expose private information such as mailbox names or correspondent addresses).
The notification path may be insecure; notifications can be forged or modified in transit. Timestamps in notifications should not be trusted, as they can be forged or misleading due to clock differences between systems.
Users can exploit the notify extension to extract classified information and bypass organizational data-leakage policies by forwarding message content via notification channels to unclassified networks. Policy enforcement must also cover the notification generation module.