Sieve Notification Mechanism: mailto
updates
- rfc-3834 — Recommendations for Automatic Responses to Electronic Mail
Extracted elements (23)
Because mailto uses a store-and-forward system (SMTP), the Sieve processor should not need to retry notifications. This is why SHOULD use normal SMTP retry mechanisms for initial submission but MUST NOT resubmit — unlike interactive notification methods, delivery is delegated to the mail system.
The owner-token parameter in Auto-Submitted was added to allow identification of the Sieve script owner while protecting the owner's privacy. This is a non-obvious design choice: owner-email reveals the actual address, whereas owner-token is opaque and only meaningful to the originating administrative domain.
The notify_method_capability test for 'online' may return 'yes' or 'no' only if the Sieve processor can determine with certainty whether recipients are online and logged in; otherwise it returns 'maybe' for the mailto notification method.
Header fields normally related to an individual new message, such as 'Message-ID' and 'Date', MUST be generated fresh for the notification message and MUST NOT be copied from the triggering message. Any URI headers with those names MUST be ignored.
Implementations MUST allow messages with empty envelope senders to trigger notifications. If the envelope sender of the triggering message is empty, the envelope sender of the notification message MUST be empty as well to avoid message loops.
Implementations MUST take steps to avoid mail loops. The required inclusion of an 'Auto-Submitted:' field in all notification messages also helps in loop detection and avoidance.
Implementations SHOULD consider limiting notification messages and SHOULD NOT send duplicate notifications to the same address from the same script invocation. Batching of notifications within a short time to the same address is also recommended.
Implementations SHOULD NOT trigger notifications for messages containing 'Auto-Submitted:' header fields with any value other than 'No', to prevent generating notifications in response to other automated messages.
Once the notification message is submitted, implementations MUST NOT resubmit it, as resubmission is likely to result in multiple notifications and increases the danger of message loops. Implementations SHOULD use normal SMTP submission and retry mechanisms for the initial submission only.
The 'Auto-Submitted: auto-notified' header field MUST include one or both of the owner-email and owner-token parameters. At least one is required to allow identification or contact of the Sieve script owner.
The envelope sender of the notification message SHOULD be set to the value of the ':from' tag if specified, valid, and has email address syntax; otherwise SHOULD be set to the envelope 'to' of the triggering message or a notification system address. This MUST NOT be overridden by a 'from' URI header, which MUST be ignored.
The 'From:' header field of the notification message SHOULD be set to the ':from' tag value if valid; otherwise SHOULD be set to the triggering message's envelope 'to' or a notification system address. A 'from' URI header MUST NOT override this and MUST be ignored.
The header field 'Auto-Submitted: auto-notified' MUST be included in every notification message. mailto URI headers with hname 'auto-submitted' are considered unsafe and MUST be ignored.
The ':options' tag is not used by the mailto notification method.
The 'Subject:' field SHOULD use the ':message' tag value if present; if absent but a 'subject' URI header exists, that SHOULD be used; otherwise the subject SHOULD be retained from the triggering message. The ':message' tag value SHOULD NOT normally be truncated.
URI headers with hname 'received' are considered unsafe and MUST be ignored. The 'Auto-Submitted' header field MUST be placed above any 'Received:' fields retained from the triggering message.
The 'Auto-Submitted: auto-notified' header field MUST include at least one of two parameters: 'owner-email' (a quoted addr-spec identifying the Sieve script owner) or 'owner-token' (an opaque token allowing owner identification while protecting privacy). It is treated as a trace field, placed above any 'Received:' fields copied from the triggering message.
The mailto notification mechanism generates a new email message (a 'notification message') to notify a recipient about a 'triggering message'. It uses standard mailto URIs, which may contain URI headers consisting of a header name and value, distinct from message headers.
RFC 5436 creates a new IANA registry 'Auto-Submitted Header Field Keywords' using the 'Specification Required' policy. Initial entries registered are: 'no' (human-authored message), 'auto-generated' (automatic, not a direct response), 'auto-replied' (automatic direct response), and 'auto-notified' (generated by Sieve notification, requires owner-email or owner-token parameter).
RFC 5436 registers the 'mailto' Sieve notification mechanism with IANA, referencing RFC 2368 as the mechanism URI, with no mechanism-specific options.
Automated sending of email notifications exposes the system to mail loops. Implementations MUST protect against loops; rate-limiting (e.g., no more than 30 notifications per user in 60 minutes) is suggested. Administrative mechanisms MUST be available to re-enable disabled notifications or terminate slow loops that evade automatic detection.
Notification recipients might not own the addresses specified in the Sieve script, enabling scripts to be used for mail-bomb attacks or generating unwanted notifications due to mistyped or reassigned addresses. Forgotten scripts left running indefinitely are a specific risk. Domains that enable this extension MUST be prepared to respond to complaints using the Auto-Submitted owner-email or owner-token to identify and disable faulty scripts.
When notification messages pass through gateways to other services (e.g., SMS), critical information including trace headers and Auto-Submitted fields may be lost, removing the ability to detect loops, contact script owners, or resolve problems. Gateway developers should preserve this information.