Recommendations for Automatic Responses to Electronic Mail
updated by
- rfc-5436 — Sieve Notification Mechanism: mailto
Extracted elements (30)
The Auto-Submitted field concept originates from X.400/MHS (X.420); RFC 2156 defined an 'Autosubmitted' field for X.400-to-Internet gatewaying. The RFC 3834 definition is a simplification of a prior Internet-draft by Jacob Palme that passed Last Call but stalled on non-substantial objections.
The Return-Path address is the only message header field that can be expected, as a matter of protocol, to be suitable for automatic responses not anticipated by the sender. The From and Reply-To fields are used in too many context-dependent ways for reliable automatic use.
The Subject field prefix 'Auto:' is specified only as an aid to humans and SHOULD NOT be machine-parsed as proof of automatic submission, because mail user agents may translate it just as they translate 'Re:' — making it an unreliable programmatic signal.
DSNs (RFC 3464) and MDNs (RFC 3798) are separate specifications governing their own generation and format; this document does not alter those specifications. Responses that fit DSN or MDN criteria should be generated per those specs rather than per RFC 3834.
Some widely-deployed SMTP implementations incorrectly use the 'auto-generated' keyword to label non-delivery reports; these should be changed to use 'auto-replied' instead, per the semantics defined in this document.
An automatic responder MUST NOT blindly send a response for every message received. Reasons include loop prevention, avoiding spam amplification, and thwarting denial-of-service attacks.
Automatic responses SHOULD be sent to the Return-Path field if generated after delivery; if generated prior to delivery, they SHOULD be sent to the reverse-path from the SMTP MAIL FROM command.
Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field with any value other than 'no', to prevent response loops between automatic responders.
For responses from Service Responders, the From field SHOULD contain an address to reach the human maintainer of the service; for Personal Responders it SHOULD contain the recipient's name and a recognizable address.
If a reply is expected by the responder, the Reply-To field SHOULD be set to the address at which the reply is expected. Responders which request replies to be sent to other responders MUST prevent mail loops and sorcerer's apprentice mode.
New Auto-Submitted extension keywords and optional parameters must be published as RFCs and approved using the IETF Consensus process. Keywords beginning with 'x-' are reserved for experiments and consenting parties.
Personal and Group absence-notification responders SHOULD NOT be issued unless a valid address for the recipient is explicitly included in a To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc field of the subject message.
Personal and Group responses intended to notify the sender of a recipient's temporary absence SHOULD NOT issue the same response to the same sender more than once within a period of several days; a 7-day period is RECOMMENDED as a default.
Personal Responders MUST allow the From field of a Personal Response to be set by the recipient on whose behalf the responder is acting, to protect privacy (e.g., not exposing login names or server hostnames).
Responders MUST NOT generate any response for which the destination would be a null address (e.g., SMTP MAIL FROM or Return-Path is <>), since such a response would not be delivered to a useful destination.
Service Responders SHOULD NOT return large responses (more than a few kilobytes) without specific knowledge that the request was actually authorized by the party associated with the response destination address, to avoid being used for denial-of-service attacks.
The auto-generated keyword MUST NOT be used on manually generated messages, on messages issued in direct response to another message, or to label DSNs or MDNs.
The auto-replied keyword MUST NOT be used on manually generated messages or on messages generated by automatic periodic processes that are not responses to other messages.
The Auto-Submitted field with a value of 'auto-replied' SHOULD be included in the message header of any automatic response, to facilitate automatic filtering of such messages.
The From field and the Sender field SHOULD NOT be used as the destination for automatic responses, as these fields are used in varied ways and may list multiple addresses.
The Reply-To field SHOULD NOT be used as the destination for automatic responses from Personal or Group Responders, because it may target mailing lists or multiple recipients and the responder lacks context to interpret sender intent.
The SMTP MAIL FROM address SHOULD be chosen to make mail loops unlikely; a MAIL FROM of <> MAY be used. The NOTIFY=NEVER parameter of the RCPT command is RECOMMENDED if the SMTP server supports DSN.
The To header field SHOULD indicate the recipient of the response, and there SHOULD be only one recipient of any automatic response, to minimize the potential for sorcerer's apprentice mode and denial-of-service attacks.
The Auto-Submitted header field indicates that a message was originated by an automatic process rather than a human. Its defined keyword values are 'no', 'auto-generated', and 'auto-replied', with optional parameters and extension keywords also permitted.
Three classes of automatic responders are defined: Service Responders (permanently associated with a service address), Personal Responders (acting on behalf of a single recipient), and Group Responders (acting for a significant set of recipients). Appropriate behavior differs per class.
Section 8 notes that if new Auto-Submitted keywords or optional parameters are approved through IETF Consensus in the future, it may be appropriate for IANA to create a registry for such keywords or parameters. No registry is formally created by this document.
Automatic responders can be exploited to relay harmful content (worms, viruses, spam), mount denial-of-service attacks by flooding mailboxes, construct mail loops, enumerate valid addresses, and disclose personal information about recipients including their mailbox usage patterns.
Automatically-generated responses SHOULD NOT include personal information about the recipient that is not already known to the sender, such as personal telephone numbers. User interfaces for configuring response text SHOULD warn that the text will be exposed to the entire Internet.
Because email addresses are easily forged, attacks remain possible for any responder that does not limit access and require authentication. The recommended mitigations (rate limiting, brief plain-text responses, Auto-Submitted marking) limit damage but cannot entirely prevent attacks.
The Auto-Submitted field is defined using ABNF: 'Auto-Submitted:' followed by one of 'no', 'auto-generated', 'auto-replied', or an extension token, optionally followed by a semicolon-delimited parameter list. At most one Auto-Submitted field may appear in a message header.