inbuxa-server/docs/spec/features/dlp-and-mail-flow-rules.md

Feature spec: data loss prevention and mail flow rules

Status: approved 2026-09-28, with the answers under Settled and the detector catalog in §2.3. Phase 1 of DLP and the rule builder, specced together because they need the same conditions, the same place in the mail path and the same record of what matched. Not a rebuild of an upstream feature, so it has no line in SPEC.md §4's table.

Provenance

Written for the record SPEC.md §3 rule 3 asks for. Sources, and nothing else:

Source	License	Used for
This repository at 0502eb4 (2026-09-28): crates/smtp/src/inbound/data.rs, crates/smtp/src/queue/, crates/jmap/src/submission/set.rs, crates/common/src/scripts/, vendor/sieve-rs, resources/schema/schema.json.gz	AGPL-3.0-only	Where a check can run, what the queue stores, what a sender sees on a refusal
inbuxa-admin at b82904c	AGPL-3.0-only	Where the pages go
ihasmail-inbuxa (the webmail) at 290bc63	AGPL-3.0-or-later	How a refused send reaches the person sending
inbuxa-drafts/queue/dlp.md, rule-builder.md	Own	What John asked for and settled
The personal-data catalog spec and the audit-hold-lock spec	Own	Roles, the audit log, legal holds, the catalog check
RFC 5321, RFC 3463 (enhanced status codes), RFC 8620/8621 (JMAP)	Public	Refusal codes and the submission error shape
The issuing authorities' published formats and check-digit rules for each identifier in §2.3 (ISO 13616, ISO/IEC 7812, ISO 7064, and each national scheme's own publication)	Public	The detector rules; each is implemented from its publication and tested against its published examples

No Enterprise-only file or snippet was used, and no third-party DLP product was consulted for design: the detectors are public checksum and format rules (Luhn, ISO 13616 mod 97, the SSA's published SSN rules).

What it is

1. Data loss prevention (DLP). Policies that look at mail as someone sends it, find what shouldn't leave (card numbers, bank accounts, national ID numbers, words and patterns an organization names, attachments of a kind), and then block it with a notice, warn and let the sender send anyway with a stated reason, or hold it until a reviewer releases or rejects it.
2. Mail flow rules. The same engine, for ordinary transport rules an administrator writes in a form instead of in Sieve: disclaimers, banners, headers, copies, redirects, refusals.
3. One record of what matched, in the audit log, and a review queue for held mail.

Settled before this spec (John, 2026-09-27 and 2026-09-28): DLP's first version checks outgoing mail only, content and attachments, as it's sent; its actions are block with a notice, warn with an override (audited), and hold for review. A record-only action was not chosen. The rule builder goes alongside DLP, one design; journaling comes after both.

Out of scope (later specs): inbound DLP, files and calendar sharing, scanning mail already stored, a machine-learning classifier (the local AI model could add one later; nothing here depends on it), mobile and ihasmail screens, journaling.

Nothing in code, docs, UI text or output claims the product meets a legal standard or prevents every leak. The pages say what a policy checks and what it did.

1. What exists today

Checked by reading the code at 0502eb4:

Need	Today
A place in the send path that sees every outgoing message	Yes. SMTP submission and webmail sends both reach Session::queue_message (inbound/data.rs); JMAP submission builds a local session and runs MAIL, RCPT and DATA (jmap/src/submission/set.rs ~L690–760). Nothing reaches the queue around it.
Order at DATA	Authentication checks → spam filter → milters → MTA hooks → the DATA system Sieve script → headers, DKIM signing → queue.
Rules without code	System Sieve (x:SieveSystemScript): one script per stage, chosen by an expression on x:MtaStageData.script. Hand-written only; the console has a text field.
Refusing a message	A 5xx at DATA. The webmail gets forbiddenToSend with the text Server rejected DATA: <reply> and nothing structured.
Holding a message	Nowhere. "Quarantine" in the code is only DMARC's disposition. The queue's recipient status is Scheduled, Completed, TemporaryFailure, PermanentFailure, archived with rkyv.
Reading attachments	Text and HTML parts only. There's no PDF or Office text extraction: search indexes text parts and file names.
Recording what happened	The audit log, with system actors, reasons and outcomes (AU-1…AU-12).
Who is allowed	Roles with per-permission grants; server and tenant levels; the compliance roles from the catalog spec.

2. Design

2.1 One engine, native, after the system script

Rules are evaluated by a new native engine at DATA, after the system Sieve script and before headers and DKIM signing. Mail flow rules and DLP policies are two views of the same rule list.

Why not generate Sieve: holding a message, a warning the sender can override, counted detectors with checksums, and a per-rule match record are all things Sieve doesn't have. Adding them means new extensions in vendor/sieve-rs, which widens the fork of a crate we'd otherwise take from upstream, and a generated script would have to share the single DATA script with whatever an administrator wrote by hand. A native engine leaves hand-written Sieve exactly as it is: it still runs, first, and the rules see its result.

The engine lives in crates/features/src/mailflow/ (pure evaluation over a parsed message and an envelope, unit-testable), called from data.rs behind one // inbuxa: marked block.

2.2 Rules

A fork-owned JMAP object, inbuxa:MailRule, stored in inbuxa's own subspace like legal holds (not a registry object, so upstream schema imports never touch it):

Property
name, description
kind	dlp or transport: which page shows it and which permission edits it
enabled
priority	Order; lower runs first
direction	outgoing (authenticated senders), incoming, or any. DLP rules are outgoing only in this version.
conditions	All must match (list below)
exceptions	Any matching one skips the rule
actions	What happens (list below)
stopProcessing	Later rules don't run for this message
tenantId	Always none in this version: rules are server-level (settled answer 3); a Tenant condition narrows a rule to tenants
createdBy, updatedAt

Every create, update and delete is audited with its before and after, like any setting, and appears on the compliance Overview's Changes that affect review.

2.3 Conditions

Shared by both kinds:

Condition	Matches when
Sender	the sender is one of the chosen accounts, or in a chosen group, domain or tenant
Tenant	the sender is in one of the chosen tenants
Recipient	any recipient is one of the chosen addresses, domains, groups
Recipient outside	any recipient isn't at a domain this server hosts
Subject or body contains	any of a list of words or phrases (whole words, case-insensitive)
Subject or body matches	a regular expression (the regex crate: linear time, no backtracking)
Header	a header exists, or its value contains or matches
Attachment	its detected type, extension or name matches; its size is over a limit; there are more than N
Can't be inspected	an attachment is encrypted or password-protected (ZIP, PDF, Office), or bigger than the inspection limit
Message size	over a limit

DLP adds detectors. Each counts what it finds, and a rule sets a minimum (for example "5 or more card numbers"). A detector is one of two strengths:

• Checked: the identifier has a published check digit or checksum, so a random number rarely passes. Found on its own.
• Needs a word: the format is too common to trust alone (nine digits, a date). Counted only with a corroborating word nearby, within 50 characters either side, in the languages where the identifier is used ("passport", "Reisepass", "pasaporte"...).

The catalog (settled answer 6: the recognized, protected identifiers, not a chosen few). Each row is one table entry and one check function in crates/features/src/mailflow/detectors/:

Region	Detector	Strength	Rule
Any	Payment card number	Checked	13–19 digits, spaces or dashes allowed, a known issuer prefix (ISO/IEC 7812), Luhn
Any	IBAN	Checked	country code, length for that country, ISO 13616 mod 97
Any	SWIFT/BIC	Needs a word	8 or 11 characters, a valid country code in positions 5–6
Any	Email addresses, in bulk	Checked	a count of distinct addresses (a customer list leaving), not one address
Any	Phone numbers, in bulk	Needs a word	a count of distinct numbers in international or national form
Any	Date of birth	Needs a word	a date beside "born", "DOB", "date of birth" and their translations
Any	Passport number	Needs a word	the formats of the issuing countries in this table
Any	Private key	Checked	a PEM or OpenSSH private-key block
Any	Cloud and service credentials	Checked	the published prefixes and lengths: AWS access key IDs, GitHub tokens, Slack tokens, Stripe live secret keys, Google API keys
US	Social Security number	Checked	AAA-GG-SSSS, or nine digits with a word; never area 000, 666 or 9xx, group 00, serial 0000
US	ITIN	Checked	9XX-GG-SSSS with the IRS's group ranges
US	EIN	Needs a word	a valid IRS prefix and seven digits
US	Bank routing number (ABA)	Checked	nine digits, a valid Federal Reserve prefix, the 3-7-1 checksum
US	Driver's license	Needs a word	each state's published format
US	Medicare Beneficiary Identifier	Checked	CMS's 11-character pattern and excluded letters
US	National Provider Identifier	Checked	ten digits, Luhn over the 80840 prefix
US	DEA registration number	Checked	two letters, seven digits, DEA's check digit
UK	National Insurance number	Checked	two letters (HMRC's excluded prefixes), six digits, A–D
UK	NHS number	Checked	ten digits, mod 11
UK	Unique Taxpayer Reference	Needs a word	ten digits
Canada	Social Insurance Number	Checked	nine digits, Luhn
Australia	Tax File Number	Checked	weighted mod 11
Australia	Medicare number	Checked	ten digits, weighted check digit
EU	Germany: tax ID (Steuer-ID)	Checked	eleven digits, ISO 7064 MOD 11,10
EU	Germany: ID card number	Checked	nine characters, the 7-3-1 check digit
EU	France: social security number (NIR)	Checked	fifteen characters, mod 97 key
EU	Spain: DNI and NIE	Checked	eight digits and the mod 23 letter
EU	Italy: codice fiscale	Checked	sixteen characters, the check letter
EU	Netherlands: BSN	Checked	nine digits, the eleven test
EU	Belgium: national number	Checked	eleven digits, mod 97
EU	Poland: PESEL	Checked	eleven digits, weighted check digit
EU	Sweden: personnummer	Checked	a date, three digits and a Luhn check digit
EU	Denmark: CPR number	Needs a word	a valid date and four digits
EU	Finland: personal identity code	Checked	a date, a century sign, three digits, the mod 31 character
EU	Ireland: PPS number	Checked	seven digits, one or two letters, mod 23
EU	Portugal: NIF	Checked	nine digits, mod 11
EU	Austria: social insurance number	Checked	ten digits, weighted check digit
Europe	Norway: national identity number	Checked	eleven digits, two mod 11 check digits
Europe	Switzerland: AHV number	Checked	756, then ten digits, EAN-13 check
Asia	India: Aadhaar	Checked	twelve digits, Verhoeff
Asia	India: PAN	Needs a word	five letters, four digits, a letter
Asia	China: resident ID	Checked	eighteen characters, ISO 7064 MOD 11-2
Asia	Japan: My Number	Checked	twelve digits, weighted check digit
Asia	Singapore: NRIC and FIN	Checked	a letter, seven digits, the check letter
Asia	South Korea: resident registration number	Needs a word	thirteen digits with a valid date
Americas	Brazil: CPF and CNPJ	Checked	two mod 11 check digits
Americas	Mexico: CURP	Checked	eighteen characters, the check digit
Africa	South Africa: ID number	Checked	thirteen digits with a valid date, Luhn
Any	Word list	—	a list the organization maintains, counted
Any	Pattern	—	the organization's own regular expression, counted

Some protected data has no number to find: health conditions, religion, union membership, sexual orientation, criminal records. No detector claims to recognize those; a word list is how an organization covers its own terms for them, and the console offers editable starting lists (medical terms, diagnosis codes as ICD-10 patterns) rather than presenting them as detection.

Templates, so a policy doesn't pick forty detectors one at a time. Each is a named set, editable once added, and named for what it finds, never for a law: Payment cards and bank accounts, US personal identifiers, UK personal identifiers, EU national identifiers, Health identifiers (the NHS number, the US Medicare Beneficiary Identifier, NPI and DEA numbers, the Australian Medicare number), Credentials and keys, Contact lists.

The catalog grows by table entry: a new identifier is one row, one check function and its published examples as tests.

What the detectors read: the subject, every text and HTML part (as text), and attachments whose detected type is text (text/*, CSV, JSON, XML). Office documents (DOCX, XLSX, PPTX, ODT, ODS, ODP) are read too (settled answer 2): they're ZIP files of XML, unpacked and read in-house with limits on unpacked size and entry count. PDF files count as can't be inspected in this version, so a policy can still act on them. Inspection stops at a limit per message (proposed 10 MB of text), and what's past it counts as can't be inspected too.

2.4 Actions

Transport actions (both kinds): add a disclaimer (text and HTML, top or bottom, once per thread), add or remove a header, prefix the subject, add a recipient (a copy), redirect to other recipients, refuse with a text, send through a chosen route (an existing x:MtaVirtualQueue).

DLP actions, exactly one per DLP rule:

Action	Sender sees	Message
Block	SMTP 550 5.7.1 with the rule's notice text; in the webmail, the notice in the send dialog	Not accepted; nothing is stored
Warn	The notice and, once they give a reason, can send anyway	Sent after an override; the reason is audited
Hold for review	Accepted with "held for review"; a notice mail from the server if the rule asks	Waits in the queue for a reviewer

When several DLP rules match, the strictest wins: block, then hold, then warn.

2.5 Warn and override

Webmail (JMAP). The first submission fails with a new error type, inbuxa:dlpWarning, carrying the matched rules' names and notice texts (never the matched text). The webmail shows them and asks for a reason; it resubmits with inbuxa:dlpOverride: {"reason": "..."} on the EmailSubmission create (capability urn:inbuxa:jmap). The server passes the reason into the local SMTP session as trusted session data, not as a header, so it can't be forged from the message. An override covers only the rules that warned; if a block or hold rule also matches, that still applies.

Mail apps (SMTP). They show whatever text the server returns, so the refusal says how to override: 550 5.7.1 <notice>. To send anyway, start the subject with [override: your reason]. On the next attempt the engine strips the tag before DKIM signing, and records the reason (settled answer 1).

A block's refusal uses the same error path with inbuxa:dlpBlocked in the webmail.

2.6 Hold for review

A held message is queued normally but not scheduled: its due time is set to never, and a review record inbuxa:HeldMessage (queue id, sender, recipients, subject, size, matched rules and counts, held at, expires at) is written in inbuxa's own subspace. The queue's stored format is untouched, so a node still on the previous version during a rolling upgrade reads the message fine and simply never sends it.

The sender gets 250 2.0.0 Held for review, and the rule may send them a notice mail. The message stays in their Sent folder as usual.

A reviewer, under Management › Compliance › Held mail:

• sees the list, and opens one to read it (each opening is audited, like any access to someone else's mail);
• releases it with a reason: it's scheduled at once and delivered as normal;
• rejects it with a reason: it's removed from the queue and the sender gets a notice with the reviewer's note, not their name.

Unreviewed mail is rejected back to the sender after 7 days, with a notice (settled answer 5); the number is a setting. Emails › Queue shows held mail as held and refuses Retry on it, so nobody can deliver it around the review. The sender can't unsend it either once it's held (the webmail says so).

Held messages count against no one's quota. Each held message and each decision is in the audit log.

2.7 What's recorded

Every DLP match writes one audit record: actor DLP (a system actor), target the message (queue id, sender, recipient domains), the rules and each detector's count, the action, and for an override the sender's reason. Never the matched text: the log would otherwise become a second copy of what the policy was keeping in. A card number isn't written, even masked.

Transport rules that change a message record the rule and action the same way. Unmatched mail writes nothing.

2.8 Permissions and who does what

New permissions (ids from 674):

Permission	Gives
sysMailRuleGet / Update	See / change transport rules
sysDlpPolicyGet / Update	See / change DLP rules
sysDlpReviewGet	See held mail and open it
sysDlpReviewUpdate	Release or reject held mail

Administrator has all. Compliance Officer (server-level) has sysDlpPolicyGet, sysDlpReviewGet and sysDlpReviewUpdate: officers see the rules and review held mail, administrators edit (settled answer 4), so "officers change no setting" stays true. Tenant roles get none: rules and the review queue are server-level (settled answer 3).

2.9 Privacy catalog

New entries, so the catalog check passes: inbuxa:MailRule (administrator identities), inbuxa:HeldMessage (sender, recipients, subject: held until reviewed or expired, then removed), and the held message's content in the queue (content, the sender's and correspondents'). The DLP audit records are covered by the audit log's entry.

2.10 Mixed versions and clusters

Rules and review records live in the shared data store, so every node sees the same ones. During a rolling upgrade a node still on the old version doesn't check mail against rules; the Overview can't tell. The console says so when nodes report different versions, and the release notes say to enable DLP rules after every node is upgraded.

2.11 Cost

Rules are compiled once when they change (regexes, word lists as an Aho-Corasick automaton) and shared by every session. Detectors only run on mail that some enabled rule could match (direction, sender, recipient checks first). The inspection limit caps the worst case.

3. Console

• Management › Compliance › Data loss prevention: DLP rules, a form with conditions, exceptions, detectors and the action; the notice text; what matched in the last 30 days (from the audit log).
• Management › Compliance › Held mail: the review queue.
• Settings › Mail flow › Rules (with the settings reorganization's approved order): transport rules, same form, ordered, with Stop processing.

Every form previews the rule in words ("If a recipient is outside and the message contains 5 or more card numbers, hold it for review").

4. Webmail (ihasmail-inbuxa)

• A warning dialog: the notice, a reason field, Send anyway and Edit message.
• A block dialog with the notice.
• A held message shows as Held for review in Sent, and its undo is gone.

5. Tests

Unit: each detector against valid and near-miss numbers (Luhn-failing cards, IBANs with a wrong check, SSN areas 000/666/9xx), word lists, regexes, the inspection limit, the can't-be-inspected cases, rule order and stop processing. Integration (tests/src/smtp/, tests/src/jmap/): block, warn and override over SMTP and JMAP, hold then release and reject, expiry, Retry refused on held mail, audit records carrying no matched text, a message queued by a node without the engine (held message format unchanged).

6. Phases

1. This spec, approved.
2. Engine, conditions, the detector framework and the catalog in §2.3, Office text extraction, transport actions; DLP block and warn over SMTP and JMAP; audit records; catalog entries. The detector catalog may land in more than one PR (by region), each with its published test vectors.
3. Hold for review: review records, release, reject, expiry, queue guard.
4. Console: DLP rules, held mail, mail flow rules.
5. Webmail dialogs; docs; a row in inbuxa-drafts/divergence-log.md.

Each phase is its own PR with tests; releases as John decides.

Known gaps

• Mail a user's own filter forwards automatically to an outside address isn't checked in this version (it leaves as generated mail, not a submission).
• What a mail app keeps in its own Sent folder, or sends through another server, is outside what this server sees.
• Detectors find formats, not meaning: a card number in a harmless test message matches; a number written in words doesn't.

Settled

John, 2026-09-28, all six as recommended, with 6 widened:

1. Override from mail apps: the [override: reason] subject tag, stripped before sending (§2.5).
2. Office and PDF: Office documents are read in this version; PDF counts as can't be inspected (§2.3).
3. Tenants: server-level rules only, with a Tenant condition (§2.2, §2.8).
4. Who edits DLP rules: administrators; compliance officers see the rules and review held mail (§2.8).
5. Unreviewed held mail: rejected back to the sender after 7 days, with a notice (§2.6).
6. Detectors: the five proposed "and any other recognized and protected PII", which §2.3 turns into a catalog of identifiers with published formats and checks, plus templates. Data with no number to find (health, religion...) is covered by word lists, not claimed as detection.