Sieve Email Filtering: Vacation Extension
updated by
- rfc-8580 — Sieve Extension: File Carbon Copy (FCC)
Extracted elements (26)
Language selection for vacation responses is deliberately encoded in the Sieve script itself (e.g., by testing Accept-Language or Content-Language headers) rather than via an automatic mechanism, because language selection is typically intertwined with other response-selection criteria such as sender identity or organizational role.
Tracking is keyed on both the sender address and the response identity (either an explicit :handle or a hash of :subject, :from, :mime, and reason) so that different auto-reply texts can each be sent once to the same correspondent without one suppressing the other.
Variable expansion is excluded from response tracking identity so that a single vacation action with a variable subject (e.g., "Auto response to: ${1}") is treated as one logical response rather than generating a unique reply for every distinct subject line received.
The vacation extension is classified as a 'Personal Responder' under RFC 3834's terminology, and this specification is designed to comply with RFC 3834's recommendations for automatic email responses.
Vacation is incompatible with the Sieve reject and refuse actions; it is not an error to combine vacation with discard, keep, fileinto, or redirect, and vacation does not affect Sieve's implicit keep action.
An Auto-Submitted header field with value "auto-replied" SHOULD be included in every vacation response message header.
If the Sieve variables extension is used, vacation action arguments MUST NOT have undergone variable expansion before being used in response tracking identity computation, so that a single vacation statement with a variable subject does not generate a unique response per incoming message.
Implementations are free to cap the number of tracked responses, but the limit MUST NOT be less than 1000. When trimming, implementations SHOULD discard the oldest entries first.
Implementations MUST convert the :subject string to RFC 2047 encoded words if and only if non-ASCII characters are present, and MUST generate an appropriate default subject (e.g., "Auto: " followed by the original subject) when no :subject parameter is supplied.
Implementations MUST handle UTF-8 input. When :mime is used, 8-bit text in MIME headers is not allowed, and implementations SHOULD reject vacation :mime actions that contain 8-bit header material.
Implementations MUST maintain a list of addresses to which vacation MUST NOT send replies (e.g., MAILER-DAEMON, LISTSERV, majordomo, addresses ending in "-request" or beginning with "owner-"). The exact contents are implementation-defined.
Implementations SHOULD NOT respond to any message containing a List-Id, List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, or List-Archive header field.
Implementations SHOULD NOT respond to any message whose Auto-submitted header field has a value other than "no", per RFC 3834.
Sites MAY define a minimum :days value greater than 0 and MAY define a maximum :days value, which MUST be greater than 7 and SHOULD be greater than 30. If :days is omitted, the default is 7 or the minimum value, whichever is greater.
The SMTP MAIL FROM address of the vacation response envelope SHOULD be set to <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line if the NOTARY SMTP extension (RFC 3461) is available.
Vacation can only be executed once per script; a script MUST fail with an appropriate error if it attempts to execute two or more vacation actions. Vacation MUST NOT be considered an error when used with discard, keep, fileinto, or redirect.
Vacation MUST NOT respond to a message unless the recipient's email address appears in a To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc header field of the original message. Known addresses, the final envelope recipient, and :addresses values all count.
Vacation replies MUST have the In-Reply-To field set to the Message-ID of the original message; the References field SHOULD be updated accordingly. If the original message lacks a Message-ID, these fields need not be generated.
When distinct vacation responses (distinguished by :handle or by differing argument combinations) are triggered for the same sender, separate replies MUST be sent for each. This behavior is REQUIRED to allow context-specific notifications.
The ':addresses' parameter takes a string-list of additional email addresses belonging to the user; these are treated as belonging to the recipient for the purpose of the To/Cc/Bcc reply eligibility check.
The capability identifier for this extension is "vacation", for use with the Sieve capability mechanism.
The ':handle' parameter attaches a named identifier to a vacation response for tracking. All vacation statements sharing the same handle are treated as the same response regardless of other argument differences, enabling a user to suppress duplicate replies across different script branches.
The ':mime' parameter indicates that the reason string is a complete MIME entity (including MIME headers and content per RFC 2045 section 2.4), enabling rich multipart or HTML vacation responses.
The 'vacation' action syntax accepts optional parameters ':days' (number), ':subject' (string), ':from' (string), ':addresses' (string-list), ':mime' (tag), and ':handle' (string), plus a mandatory 'reason' string argument containing the auto-reply body.
This document registers the "vacation" capability in the IANA Sieve Extensions registry, with a description of generating auto-replies for absent users and contact via the Sieve discussion list at [email protected].
Implementations must correctly enforce that replies are never sent to messages not addressed directly to the recipient user, and must never send replies more frequently than the :days argument specifies (unless the script changes). Failure to enforce these rules risks creating mail loops.