RFC 3834 — Automatic Email Responses

Every campaign you send triggers automatic replies such as out-of-office (OOO) notices, and every feature that answers mail automatically can start a mail loop. RFC 3834 is the rulebook for anything that answers mail automatically: vacation and OOO notices, bots that acknowledge tickets, and responders on file servers and mail servers.

Two of its contributions matter every day to an email service provider (ESP). The first is the Auto-Submitted: header, the standard machine-readable marker that says "this was not written by a human". The second is the discipline of loop prevention, which stops auto-responders, bounces and bulk mail from feeding back into each other.

An ESP sits on both sides. Its campaigns trigger thousands of OOO replies, and its own transactional and notification traffic must not take part in loops.

Responder taxonomy

When a responder must NOT respond

Responders "MUST NOT blindly send a response for every message received":

• A responder MUST NOT respond when the response would go to a null address, that is, when the MAIL FROM or Return-Path of the subject message is <> (bounces and other notifications). This mirrors RFC 5321's rule that notifications are sent with the null sender.
• It SHOULD NOT respond to any message that carries Auto-Submitted: with a value other than no. Auto-replies never answer auto-replies.
• It MAY refuse to respond to return paths with patterns typical of responders and mailing lists: local parts that match owner-*, *-request, MAILER-DAEMON and similar.
• Personal and Group responders SHOULD NOT respond unless the recipient's address appears explicitly in a To:, Cc:, Bcc: or Resent-* field. This prevents responses to bulk mail sent as Bcc, and to much spam.
• A responder SHOULD NOT respond to messages with the Precedence: values list, junk or bulk. This is a de facto rule that the RFC endorses; Precedence is not formally standardized.
• Rate limit: send the same response to the same sender at most once within a period of several days, with 7 days RECOMMENDED as the default. Send at most one response per incoming message.
• Service responders SHOULD NOT answer badly malformed requests, and SHOULD NOT return large responses (more than a few kilobytes) without verifying that the requester authorized them. This defends against backscatter and amplification.

Where the response goes

• To the Return-Path after delivery, or to the SMTP MAIL FROM reverse path before delivery. It is "really the only [address] that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender."
• Personal and Group responders SHOULD NOT use Reply-To:. From: has the same problems, and Sender: SHOULD NOT be used either. A Service Responder MAY use From:, or an address in the payload, if the specification of its service says so.
• If Return-Path is missing, the delivery agent has a bug. Do not guess with heuristics.

What this means for an ESP: OOO replies to your campaigns arrive at your bounce address or Variable Envelope Return Path (VERP) address, not at your From: or Reply-To: address. Your return-path processor must classify them (see below). The VERP encoding tells you which recipient is away, even when the body of the reply is useless.

How a compliant response is built

• Envelope: choose a MAIL FROM that makes loops unlikely. <> MAY be used, or a dedicated response address that never responds. NOTIFY=NEVER on RCPT is RECOMMENDED where the server supports the Delivery Status Notification (DSN) extension, because an auto-responder does not want bounces of its own responses.
• Header:
  • Auto-Submitted: auto-replied.
  • From: reaches the human owner or maintainer. For personal responders, that is the recipient's name and a recognizable address.
  • To: is the single recipient of the response.
  • Subject: is a brief indication that this is an automatic response, followed by the original subject. The prefix Auto: MAY be used (followed by an ASCII space, 0x20).
  • In-Reply-To: and References: SHOULD be set from the Message-ID of the subject message, as described in RFC 2822 §3.6.4.
  • Date: is the time the response was generated.
  • Reply-To: appears only if a reply is actually wanted, and points to where the reply is expected.
• Body: brief, in text/plain. It SHOULD NOT include significant content, non-text parts or attachments from the subject message. This stops responders from rebroadcasting confidential or malicious content.

The Auto-Submitted: header field

The syntax is Auto-Submitted: value [; parameters]. The registered values are:

Extension keywords require IETF consensus. The field is the standard key for suppression: mail that carries auto-generated or auto-replied must never receive an automatic answer.

Loop prevention, summarized

Loops are prevented by defense in depth, and each layer is sufficient on its own:

1. Responses go to the Return-Path, and messages with a null return path never get responses. A responder that sends with MAIL FROM:<>, or from a response address that stays silent, can therefore never be answered by a compliant peer.
2. Auto-Submitted: auto-replied marks the response, so other responders stay silent.
3. Remembering each sender, and responding at most once per sender per 7 days, caps volume even against a peer that does not comply.
4. One response per incoming message, never more (the defense against "sorcerer's apprentice mode").

Guidance for senders (ESP operations)

• Sending automated mail: every message your platform generates that is not a direct reply (welcome mail, alerts, digests and, arguably, bulk campaigns) can carry Auto-Submitted: auto-generated. Anything that answers a user's message carries auto-replied. This costs nothing, stops storms of OOO replies coming back at you, and labels your streams honestly for filters. Never put an Auto-Submitted value other than no on genuine human one-to-one (1:1) mail.
• Never auto-respond to <> or to Auto-Submitted mail in any product feature (autoresponders, "thanks for your reply" flows, ticket bots). Doing so generates backscatter, and backscatter gets IP addresses blocklisted.
• Classifying inbound replies at the bounce address: an OOO reply is not a bounce. Detect it by Auto-Submitted: auto-replied, by subject prefixes such as Auto: or a localized "out of office", and by the absence of a multipart/report structure. Then do not suppress the recipient. An OOO reply proves that the mailbox exists and received the message, so treating it as a failure removes live subscribers. Microsoft Exchange marks OOO replies with X-Auto-Response-Suppress and auto-replied. Plenty of responders in the real world do not comply, so keep heuristics alongside the header check.
• Reply tracking features: exclude messages with Auto-Submitted != no from "reply" engagement metrics, and do not let them trigger follow-up sequences. Counting OOO replies as engagement corrupts both analytics and sending logic.
• Expect spikes in OOO volume after large business-to-business (B2B) sends, especially around holidays. They are normal and harmless. An auto-response loop between your system and a responder is not harmless, and the limits on your side (once per 7 days, once per message) are the guard against it.
• Precedence: bulk on marketing mail is still a courtesy signal that some responders honor by staying silent. It is non-standard but harmless, and it reduces OOO noise.

Related articles

• RFC 5321 (SMTP), the null reverse-path contract this builds on
• Delivery Status Notifications, the other kind of automatic mail, identified by format rather than by Auto-Submitted
• ESMTP Extensions, including NOTIFY=NEVER
• Complaint Feedback Loops