RFC 3834 — Automatic Email Responses

RFC 3834 is the rulebook for anything that answers mail automatically — vacation/out-of-office (OOO) notices, ticket-acknowledgment bots, file/mail-server responders. Its two contributions matter daily to an ESP: the Auto-Submitted: header (the standard machine-readable "this was not written by a human" marker) and the loop-prevention discipline that keeps auto-responders, bounces, and bulk mail from feeding back on each other. An ESP sits on both sides: its campaigns trigger thousands of OOO replies, and its own transactional/notification traffic must not participate in loops.

Responder taxonomy

Type	Acts for	Example
Service Responder	An address whose whole purpose is responding; senders expect the response	File retrieval, calendar booking
Personal Responder	One recipient, per that user's configuration	UNIX vacation, OOO
Group Responder	Many recipients under uniform criteria	Server-wide virus/quarantine notifier

When a responder must NOT respond

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

• MUST NOT respond when the response destination would be a null address — i.e., the subject message's MAIL FROM/Return-Path is <> (bounces, other notifications). This is the mirror of RFC 5321's rule that notifications are sent with the null sender.
• SHOULD NOT respond to any message carrying Auto-Submitted: with any value other than no — auto-replies never answer auto-replies.
• MAY refuse to respond to return-path patterns typical of responders/lists: local parts matching owner-*, *-request, MAILER-DAEMON, etc.
• Personal/Group responders SHOULD NOT respond unless the recipient's address appears explicitly in a To:, Cc:, Bcc:, or Resent-* field (defeats responses to Bcc'd bulk mail and much spam).
• SHOULD NOT respond to messages with Precedence: values list, junk, or bulk (a de facto rule the RFC endorses; Precedence is not formally standardized).
• Rate limit: the same response to the same sender at most once within a period of several days — 7 days RECOMMENDED as the default. One response per incoming message maximum.
• Service responders SHOULD NOT answer wildly malformed requests, and SHOULD NOT return large responses (more than a few kilobytes) without verifying the requester authorized them (backscatter/amplification defense).

Where the response goes

• To the Return-Path (post-delivery) or the SMTP MAIL FROM reverse-path (pre-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."
• Reply-To: SHOULD NOT be used by Personal/Group responders; From: has the same problems; Sender: SHOULD NOT be used. (A Service Responder MAY use From: or a payload address if its service spec says so.)
• If Return-Path is missing, that's a delivery-agent bug — do not guess with heuristics.

ESP consequence: OOO replies to your campaigns arrive at your bounce/VERP address, not your From: or Reply-To:. Your return-path processor must classify them (see below), and the VERP encoding tells you which recipient is away even when the reply body is useless.

How a compliant response is built

• Envelope: MAIL FROM chosen to make loops unlikely — <> MAY be used, or a dedicated never-responding response address. NOTIFY=NEVER on RCPT is RECOMMENDED where the server supports the DSN extension (an auto-responder doesn't want bounces of its own responses).
• Header: Auto-Submitted: auto-replied; From: reaching the human owner/maintainer (personal responders: the recipient's name and a recognizable address); To: the single response recipient; Subject: a brief auto-response indication then the original subject — the prefix Auto: MAY be used (followed by an ASCII space, 0x20); In-Reply-To:/References: SHOULD be set from the subject message's Message-ID per RFC 2822 §3.6.4; Date: = generation time; Reply-To: only if a reply is actually wanted, pointing where it's expected.
• Body: brief, text/plain; SHOULD NOT include significant content, non-text parts, or attachments from the subject message (prevents responders from re-broadcasting confidential or malicious content).

The Auto-Submitted: header field

Syntax: Auto-Submitted: value [; parameters]. Registered values:

Value	Meaning	Rules
no	Message originated with a human	Optional; its absence ≈ human origin
auto-generated	Sent by an automatic process not in direct response to another message (cron alerts, notifications, welcome mail)	MUST NOT be used on direct responses; MUST NOT label DSNs/MDNs (those are identified by their own MIME types)
auto-replied	Sent in direct response to another message by an automatic process	SHOULD be used on all auto-replies; MAY additionally appear on DSNs/MDNs

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

Loop prevention, summarized

Loops are prevented by defense in depth — each layer independently sufficient:

1. Responses go to the Return-Path, and messages with a null return path never get responses; a responder sending with MAIL FROM:<> (or a silent response address) can therefore never be answered by a compliant peer.
2. Auto-Submitted: auto-replied marks the response so other responders stand down.
3. The once-per-sender-per-7-days memory caps volume even against a non-compliant peer.
4. One response per incoming message, never more ("sorcerer's apprentice mode" defense).

Guidance for senders (ESP operations)

• Emitting automated mail: every platform-generated message that isn't a direct reply — welcome mails, alerts, digests, and arguably bulk campaigns — can carry Auto-Submitted: auto-generated; anything answering a user message carries auto-replied. This costs nothing, suppresses OOO storms back at you, and marks your streams honestly for filters. Never put Auto-Submitted values other than no on genuine human 1:1 mail.
• Never auto-respond to <> or to Auto-Submitted mail in any product feature (autoresponders, "thanks for your reply" flows, ticket bots). Violating this generates backscatter, and backscatter gets IPs blocklisted.
• Classifying inbound replies at the bounce address: an OOO is not a bounce. Detect it via Auto-Submitted: auto-replied, Auto: /localized "out of office" subject prefixes, and the absence of multipart/report structure — then do not suppress the recipient. An OOO proves the mailbox exists and delivered; treating it as a failure erases live subscribers. Microsoft Exchange marks OOOs with X-Auto-Response-Suppress and auto-replied; plenty of real-world responders are non-compliant, so keep heuristics alongside the header check.
• Reply-tracking features: exclude Auto-Submitted != no messages from "reply" engagement metrics and from triggering follow-up sequences — counting OOOs as engagement corrupts both analytics and send logic.
• Expect OOO volume spikes after large B2B sends (holidays especially); they are normal and benign. What is not benign: an auto-response loop between your system and a responder — the 7-day/once-per-message caps on your side are the guard.
• Precedence: bulk on marketing mail remains a courtesy signal some responders honor to stay silent; it is non-standard but harmless and reduces OOO noise.

See also

• RFC 5321 — SMTP — the null reverse-path contract this builds on.
• Delivery Status Notifications — the other kind of automatic mail, and why DSNs are identified by format, not by Auto-Submitted.
• ESMTP Extensions — NOTIFY=NEVER, recommended on auto-responses.
• Complaint Feedback Loops — the third automated stream a return-path processor must classify.