Auto-Submitted is also a loop-prevention signal: do not let two autoresponders keep each other alive

What the standard or provider is actually evaluating

RFC 3834 defines Auto-Submitted to distinguish automatically generated or auto-replied messages from human-originated mail and recommends that automatic responders avoid responding to messages whose Auto-Submitted value is not “no.”

RFC 3834 defines the `Auto-Submitted` field so automatic responders can signal that a message was generated automatically. Values other than `no`, such as `auto-replied`, are important loop-prevention evidence. An outbound reply detector should not treat every inbound-looking message as a human response just because it came from the recipient’s domain. Out-of-office notices, ticket acknowledgements, and other automated replies can legitimately reference the original message. Parse Auto-Submitted together with common standards-based response headers and your conversation linkage, then classify the event separately from a human reply so follow-up policy can decide whether to pause, reschedule, or continue.

The shortcut that breaks the diagnosis

The header is often used only to label out-of-office mail. Its broader value is loop prevention: a system can recognize that another automated process already generated the message.

The more dangerous design is an automatic responder that replies to another automatic response. If both sides generate responses without checking Auto-Submitted and related loop controls, they can create mail storms. Do not solve that risk by ignoring all automated messages; an out-of-office can contain useful return dates, and an automated unsubscribe acknowledgement can confirm a stop action. The correct model preserves the event but changes the action. Automatic messages should not trigger another automatic reply unless a narrowly defined workflow explicitly allows it and has independent loop limits.

Build a control case before editing production

Create fixtures with Auto-Submitted:no, auto-replied, auto-generated, missing header, and an extension value. Run them through reply classification and any response-generating rules and verify only intended cases can trigger automation.

Build fixtures for a human reply with `Auto-Submitted: no` or no automatic marker, an OOO with `auto-replied`, and an automated system message that references the outbound mail. Run them through the same parser. Confirm all three are attached to the correct conversation but only the human fixture creates the human-reply event. Then feed an automated reply back into any autoresponder component and verify no response is generated. Preserve the raw field value because unknown extension tokens should not be silently normalized into “human” merely because your enum did not recognize them.

Fix the state that the evidence names

Route automatic messages to a non-human state, cancel or pause follow-ups according to policy, and never generate an automatic response solely because another automatic response arrived.

Store `message_origin = human | automatic | unknown` independently from `conversation_matched`. That lets a policy pause follow-ups during a known vacation window without pretending the prospect personally replied. Add rate/loop guards to every system capable of automatic outbound mail, and set Auto-Submitted correctly on messages your own automation generates when applicable. During incidents, inspect headers before blaming domain reputation for a burst of traffic; a responder loop can create abnormal volume from perfectly authenticated infrastructure and should be stopped at the application layer first.

An operator-sized scenario

A vacation message with Auto-Submitted:auto-replied may be useful evidence that the address is monitored, but it should not be counted as a positive human reply or used to trigger a conversational auto-response.

Out-of-office handling is a good example of why automatic and human replies need separate policy. An OOO may contain a return date or alternate contact, so the system can pause the next follow-up until after the stated window if it can parse that information confidently, or simply place the lead in a review state. It should not score the event as positive engagement, and it should not send an automatic acknowledgment back. Keep the original automatic message so an operator can inspect it. If the same mailbox emits repeated OOO notices, deduplicate them without losing the fact that the recipient remains unavailable. This approach extracts useful scheduling information while honoring RFC loop-prevention signals and avoiding artificial reply metrics.

Fields that make the decision auditable

Store the raw Auto-Submitted value, sender, Message-ID, In-Reply-To/References, classification reason, and any sequence action. Subject lines such as “Out of office” can remain secondary hints.

Do not turn this edge case into a universal rule

Missing Auto-Submitted does not prove a human wrote the message. Some systems are noncompliant or strip headers, so combine this signal with content, sender and thread evidence.

Keep unknown automatic-response patterns conservative. When a message is clearly linked to the conversation but its automation status is ambiguous, a short hold and review is safer than firing another immediate follow-up. The state can later be resolved to human, automatic, or irrelevant without losing the original message. That preserves deliverability and avoids creating a loop from a parser edge case.

Field checklist

• Capture the raw evidence for Auto-Submitted header prevent autoresponder loop outbound email before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using auto-response-rfc, message-rfc rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for Auto-Submitted is also a loop-prevention signal: do not let two autoresponders keep each other alive and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.