Summary

  • RFC 5230 defined a Sieve action that generated a new message, addressed to the incoming message’s envelope sender, while tracking whether that particular sender had already received the same response.
  • Its meaningful controls were not just the away text: direct-recipient qualification, response identity, anti-loop headers and a site-bounded interval determined who would hear from the absent user, and when.

The absent user was not the only person at risk

An away message looks harmless because its content is usually short. Yet an automatic reply is an outbound act, made by a system that has not asked its owner about each recipient. It can disclose that someone is away, reply to a mailing list, or ricochet between unattended systems. A good response therefore needs more than a polite paragraph. It needs a rule for when not to speak.

That was the problem RFC 5230 addressed in 2008. It added “vacation” to Sieve, the constrained mail-filtering language: a script could say that a particular user would not answer promptly, and the interpreter could generate a separate message. The extension was the first Sieve feature able to create an entirely new message. That changed the consequence of a rule. A folder action rearranged delivery; a vacation action created communication that could leave the account and invite another message in return.

The standard chose the SMTP envelope sender as the destination. It did not simply trust the human-readable From line. A generated response should use an empty envelope sender, and where the delivery-status extension was available, the implementation should request no further notification if that response itself failed. The Auto-Submitted header marked the reply as automatic. The message’s Date, sender, recipient and threading headers described a generated response rather than disguising it as the original correspondent’s mail.

One sender, one particular answer, one interval

The most consequential state is easy to miss: the extension remembers responses by sender address over time. The same person can write again while the recipient is away, but the system does not simply resend every time. The optional :days value bounds how long the prior response suppresses another. Without one, the default is the greater of seven days or the site’s minimum. A site may set a minimum above zero and cap the maximum; values outside those bounds are clamped. The nominal number in a user’s script is therefore not necessarily the effective interval.

Suppression is not a single “already away” flag. The standard asks which response this sender has received. An explicit :handle lets related vacation statements share one identity. Without it, the identity is synthesized from the subject, From, MIME flag and reason string. A single script can thus offer separate answers to different classes of mail without confusing them into one. Conversely, two branches with the same response arguments share the same suppression history. If variables are used, their runtime expansion must not happen before this identity calculation: the key is formed from the command’s specified arguments, not from a value that changes each time the script runs.

This makes the reply interval a small policy database. Its useful key is not merely “sender” and not merely “message body,” but the pair of sender address and response identity. That distinction lets a system avoid needless repetition while still sending a different, timely explanation. It also means the script author and site operator together define the behavior: handles shape what is considered the same answer; site minimums and maximums shape how often an answer can recur.

A reply had to be addressed to the person who was away

RFC 5230 requires that the user’s address appear in To, Cc, Bcc or corresponding resent fields before a vacation response can be sent. The recipient’s identity may come from an implementation’s account records, the final envelope recipient, or a script’s :addresses list for aliases. That fallback matters for people with several addresses; it can also fail when forwarding or subaddressing makes the complete set unknowable.

Other guardrails reduce replies to machines and lists. An implementation must maintain a blocklist of addresses that should never receive vacation messages; the standard suggests daemon and mailing-list management names. It should not answer mail carrying list-management headers, and should not answer an Auto-Submitted message unless its value is no. Implementations may also suppress messages whose headers or content indicate that a response would be inappropriate. The rules do not prove that every implementation recognizes every list or automated workflow. The standard leaves some identities implementation-defined and ties safety to the details a server can actually observe.

RFC 3834 had already offered broader recommendations for personal responders. RFC 5230 says its design was intended to follow that guidance. Later work extended the edges rather than replacing the policy: RFC 6131 added :seconds, including zero for intentionally answering every message; RFC 6133 showed vacation working with presence and address-book conditions; RFC 8580 later added optional filing of a copy of the generated reply. Those later documents demonstrate design possibilities, not how commonly any feature was deployed.

A message is more than the text it contains

RFC 5230 also anticipated language and context. Responses can be UTF-8 or MIME, including multipart alternatives. A script may choose language from message fields, but the document warns that simplistic field matching can be fooled. It notes that formality may depend on whether the correspondent is a colleague or a stranger, not only on a language header. Even response text is part of a routing decision about audience.

The extension is deliberately narrow: once per script, it cannot be combined with reject or refuse, and it does not cancel Sieve’s implicit keep. Those facts situate it in the filtering language, but they are not the same question as RFC 3028’s general rules about action selection. RFC 5230’s distinctive contribution is the policy around a new outbound message: its recipient, identity, headers and repeat interval.

The historical record supports the design, not a claim that vacation replies became safe everywhere. A server cannot perfectly infer whether a message was personally addressed, whether a forwarded alias belongs to the same user, or whether a mailing-list header tells the whole story. The standard instead layers observable tests and bounded memory around a tempting shortcut. The away message was never just a saved sentence. It was permission, addressed to someone, under a clock.

Sources