Nobody wrote this to anybody.

Most of the messages in a modern corporate mailbox were not written by a person. They were emitted by a ticketing system, a build server, a scheduled report, an e-signature platform, a toll transponder account, or an out-of-office responder. That mail is expensive to host, expensive to review, and — worse — it actively degrades the analytics that ECA depends on.

There is a standards-based way to identify a large share of it deterministically, at intake, before it ever becomes a review decision: the Auto-Submitted header field defined by RFC 3834. This is what it is, why it is trustworthy in a forensic corpus even though it is nearly worthless as a spam filter, and how to use it defensibly.

The problem: the notifications node

Run a communication graph over any real custodian mailbox and one node dominates the picture. It is not the CEO. It is the aggregate of no-reply senders — ticketing, expense, HR, document signature, monitoring, the parking garage. On a typical modern collection this population is not a rounding error; it is frequently a double-digit percentage of the message count, and in engineering or operations custodians it can exceed half.

This mail causes three distinct harms:

1. Cost. It is hosted, processed, indexed, and — if it reaches a linear review queue — paid for by the document.
2. Analytics distortion. Email threading, near-duplicate detection, repeated-content identification, name normalization, and clustering all assume that messages encode human communication. Ten thousand identically-templated build alerts will happily form the tightest, most confident, most useless cluster in your workspace — and the no-reply sender will normalize into a "person" who talks to everyone and hears from no one.
3. Attention. Every reviewer minute spent tagging a toll receipt is a minute not spent on the documents that decide the case.

The usual response is keyword suppression — search for "no-reply," "unsubscribe," "this is an automated message." That works about as well as you would expect: it is a guess, it is language-dependent, it is over- and under-inclusive at the same time, and it is difficult to describe to opposing counsel in a way that sounds like anything other than a guess.

There is a better signal, and it has been sitting in the message header the whole time.

What RFC 3834 actually is

RFC 3834, Recommendations for Automatic Responses to Electronic Mail (K. Moore, August 2004, Standards Track), was not written to fight spam. It was written to stop mail loops — the classic failure where two vacation responders discover each other and generate traffic until someone unplugs a server.

To solve that, the RFC needed automated systems to be able to recognize each other. So it defined a header field whose entire job is to let a message declare its own provenance:

auto-submitted-field  = "Auto-Submitted:" [CFWS]
                        auto-submitted [CFWS] CRLF

auto-submitted        = ( "no" / "auto-generated" /
                        "auto-replied" / extension )
                        opt-parameter-list

extension             = token

opt-parameter-list    = *( [CFWS] ";" [CFWS] parameter )

Four keywords are registered in the IANA Auto-Submitted Header Field Keywords registry:

The rule that makes the whole scheme work is in Section 2:

Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field … where that field has any value other than "no".

Read that carefully, because it is the load-bearing sentence for everything that follows.

Why the signal is trustworthy here — and useless as a spam filter

The obvious objection to any self-declaring header is: why would a bad actor tell the truth? Ask a spammer to stamp Auto-Submitted: auto-generated on a blast and he will decline. This is precisely why RFC 3834 never became an anti-spam mechanism. In an adversarial channel, a self-declaration made by the sender is worth nothing.

eDiscovery is not an adversarial channel. The corpus is your own client's collected mail, and the systems that produced the machine-generated portion of it are ordinary, well-behaved enterprise applications with no incentive to lie about what they are. More than that, they have a strong affirmative incentive to tell the truth:

• A system that omits the header gets auto-replied to. Every out-of-office responder on the recipient side treats it as human mail and answers it. At scale, that is a support burden, a deliverability problem, and eventually a loop.
• A system that sets the header is left alone by every conforming responder, per the Section 2 rule.

The spec is therefore self-enforcing in exactly the population we care about. Compliance is not driven by goodwill; it is driven by the operational pain of non-compliance. That asymmetry — worthless against an adversary, reliable against infrastructure — is the technical heart of why RFC 3834 is a culling tool rather than a filtering tool.

It is also why the signal is asserted rather than inferred. Every other culling heuristic in common use is a model of the document: a keyword guess, a classifier score, a sender-domain hunch. Auto-Submitted is a first-party statement of fact by the producing system, evaluated by a byte comparison. There is no threshold to tune, no seed set to train, no confidence interval to explain on the record.

What sets it in practice

You do not have to take this on faith; the header is emitted across the mainstream stack:

• Out-of-office and vacation replies. Exchange and Microsoft 365 automatic replies, Google's vacation responder, and any Sieve implementation — RFC 5230 states that Auto-Submitted: auto-replied SHOULD be included on any vacation message sent.
• Sieve notifications. RFC 5436 makes Auto-Submitted: auto-notified a MUST, with an owner parameter.
• Application and workflow notifications. Ticketing and project management, e-signature completion notices, HR and expense systems, monitoring and alerting, CI/CD, scheduled report deliveries, receipts and confirmations. These are the big notifications node on the communication graph.

Because it is a header field, it survives forensic processing intact, it is extractable to a metadata field, it is indexable, it is searchable, and it exports cleanly in a load file. It is not a derived score that has to be regenerated in the next platform — it is part of the RFC 5322 source and it travels with the document.

Precision, recall, and the direction of the error

Be precise about what the header does and does not prove:

• Presence with any value other than no is a high-precision positive. The producing system said so. False positives are rare and are typically misconfiguration, not ambiguity.
• Absence proves nothing. RFC 3834 does not say that a message without the header is human-authored, and plenty of bulk marketing mail and older applications simply omit it. Recall is good but not complete.

That asymmetry is a feature, not a limitation, because it points the error in the safe direction. A cull rule of "suppress messages that affirmatively declare themselves machine-generated" is conservative by construction: it can leave junk behind, but it will not sweep up a human-authored message that happened to use the wrong words. Compare that to a keyword rule, where the errors run in both directions and the inclusive error is the one that hurts.

Treat Auto-Submitted as the high-precision first pass, not the whole program. It removes a large, cleanly-defined block cheaply and defensibly; you still handle the remainder with domain analysis, list headers, and the usual tools.

The inverse signal

Auto-Submitted: no is the only value that never flags — it is an explicit declaration of human authorship. Do not merely exclude those messages from the cull; consider treating them as a mild promote signal when prioritizing an ECA population. It is uncommon (RFC 3834 says a sender MAY use it, not SHOULD), but where present it is the strongest available statement that a person sat down and wrote this to somebody.

Corroborating headers worth stacking

For a scored approach rather than a binary one, Auto-Submitted combines well with:

• Null return path. RFC 3834 recommends that responders choose a MAIL FROM that makes loops unlikely and permits <>. A Return-Path: <> on a message that also carries Auto-Submitted is strong confirmation.
• List headers. List-Id (RFC 2919), the List-* set (RFC 2369), and List-Unsubscribe with One-Click (RFC 8058) identify list and bulk traffic — a related but distinct bucket. Do not conflate the two.
• Content-Type: multipart/report (RFC 6522) for delivery status notifications, message disposition notifications, and abuse reports.
• X-Auto-Response-Suppress — Microsoft's non-standard field, useful as corroboration only.
• Precedence: bulk or junk — worth noting that RFC 3834 itself declines to recommend it, observing that the field is non-standard and its interpretation varies widely. Use it as weak corroboration, never as a primary rule.

A simple "two independent machine signals" threshold gives you a defensible middle tier for QC sampling without loosening the primary rule.

Implementation notes that actually matter

Most of the ways this goes wrong are parser problems, not policy problems.

1. Match the keyword, not the whole value. Auto-Submitted: auto-notified; owner-email="sieve@example.com" is legal and common. A parser doing string equality against auto-generated will miss every parameterized value. Take the token up to the first ; or CFWS.
2. Handle comments and folding. The ABNF permits [CFWS] around the value. Auto-Submitted: (generated by cron) auto-generated is valid. So is a folded continuation line.
3. Compare case-insensitively and expect extension tokens outside the four registered keywords — the grammar allows them, so the rule should be "present and not no" rather than an allow-list of three strings.
4. Map the field at processing. This is the one that bites in practice. Most processing engines do not extract Auto-Submitted to a metadata field by default. If it is not in your field map at intake, it is not searchable downstream — and re-processing a terabyte to add one header is not a conversation you want to have. Add it, along with Return-Path, List-Id, and Precedence, before the first ingest.
5. Only trust the top-level header block of the message itself. Quoted headers inside a reply body, or headers of an attached .eml, are content — not provenance.
6. Respect families. An attached machine-generated .eml inside a human-authored transmittal is a child of a document that must be reviewed. Cull at the family level based on the top-level parent; never orphan attachments out of a family.
7. Suppress, do not delete. Route the bucket to a suppressed or staged population with the rule that produced it recorded per-document. You want to be able to re-promote it in ten seconds when a dispute arises, and to say exactly how many documents it contained.

Defensibility, and the carve-out you will need

The reason to prefer this over a keyword cull is not only that it is more accurate. It is that it is describable. The rule fits in one sentence in an ESI protocol — "messages bearing an RFC 3834 Auto-Submitted header field with a value other than 'no' were routed to a suppressed population" — it is deterministic, it is reproducible by the other side against the same collection, and it produces the same result every time it is run. That is a materially better position than defending a classifier threshold or a list of English keywords under a proportionality challenge.

But state the obvious caveat plainly, because it is real: machine-generated does not mean irrelevant. An e-signature completion notice can establish execution and date. A workflow approval notification can establish who approved what and when. A monitoring alert can establish notice. An out-of-office reply can establish that a custodian was unavailable on a date that matters. Automated mail is frequently the cleanest timestamped evidence in the collection precisely because no human curated it.

So the practical program is: cull to a suppressed bucket rather than out of the case; carve out by sender domain or system before you run it where you already know a source is probative; sample the bucket for QC and document the sample; and keep the rule reversible.

Do it at intake

Wherever this runs, run it early — at intake, before the data lands in the environment where ECA will actually happen. Two reasons.

First, cost. This is the cheapest possible point in the lifecycle to remove volume, and every downstream per-GB and per-document charge inherits the reduction. Culling after promotion means you have already paid to host, process, and index the population you are about to set aside.

Second, and less obvious, analytics quality. Threading, name normalization, near-duplicate detection, repeated-content identification, and clustering all produce noticeably better output when the machine-generated population is not in the index competing for the model's attention. This is not a marginal effect. Templated notification traffic forms dense, high-confidence near-duplicate groups and clusters that crowd out the smaller, messier, more interesting human ones; no-reply senders normalize into pseudo-people with enormous degree and no reciprocity. Remove that population first and counsel gets a communication graph of people talking to people rather than a starburst around a no-reply address — and every population promoted downstream from there is smaller and cleaner for it.

A header defined more than twenty years ago to keep two vacation responders from arguing with each other turns out to be one of the most reliable culling signals available. It is worth mapping.

---

This article is offered for general informational purposes and is not legal advice. Culling decisions should be documented in the applicable ESI protocol and discussed with the parties.

References

• RFC 3834 — Recommendations for Automatic Responses to Electronic Mail (Standards Track, August 2004)
• RFC 5436 — Sieve Notification Mechanism: mailto (updates RFC 3834; adds auto-notified)
• RFC 5230 — Sieve Email Filtering: Vacation Extension
• RFC 2919 / RFC 2369 / RFC 8058 — list identification and unsubscribe headers
• RFC 6522 — The Multipart/Report Media Type
• IANA — Auto-Submitted Header Field Keywords registry