DLP and mail flow rules: rules, engine, and inbuxa:MailRule over JMAP

jcoffey-dev commented

2026-09-29 00:31:14 +00:00

Owner

Phase 2e of the DLP spec, two commits:

Rules and engine (features crate): the rule model and validation (§2.2–§2.4), stored under R/r; the engine (compiled word lists and patterns, priority order, exceptions, stop processing, each detector once per message; DLP decision block > hold > warn, override answers warnings only); a per-node compiled cache (30 s, or at once on a local change).
inbuxa:MailRule get/set: six permissions (ids 674–679, enum + schema labels) for mail flow rules, DLP rules and held mail; kind-separated in the handler; server-level only; administrators get all six, the server-level Compliance Officer sees DLP rules and reviews held mail (added once to existing officer roles via a new officer grant audience); every change audited; privacy catalog entry.

Nothing is wired into the mail path yet (phase 2f).

Tests: new mail_rules_tests (create, order, validation, server-set properties, update, officer sees DLP only and changes nothing, destroy, audit records), compliance_tests, system::system_tests, features 198 and common 127 unit tests, all passing locally. The officer unit test now allows held-mail review beside holds (settled answer 4).

Phase 2e of the DLP spec, two commits: 1. **Rules and engine** (features crate): the rule model and validation (§2.2–§2.4), stored under R/r; the engine (compiled word lists and patterns, priority order, exceptions, stop processing, each detector once per message; DLP decision block > hold > warn, override answers warnings only); a per-node compiled cache (30 s, or at once on a local change). 2. **`inbuxa:MailRule` get/set**: six permissions (ids 674–679, enum + schema labels) for mail flow rules, DLP rules and held mail; kind-separated in the handler; server-level only; administrators get all six, the server-level Compliance Officer sees DLP rules and reviews held mail (added once to existing officer roles via a new officer grant audience); every change audited; privacy catalog entry. Nothing is wired into the mail path yet (phase 2f). Tests: new `mail_rules_tests` (create, order, validation, server-set properties, update, officer sees DLP only and changes nothing, destroy, audit records), `compliance_tests`, `system::system_tests`, features 198 and common 127 unit tests, all passing locally. The officer unit test now allows held-mail review beside holds (settled answer 4).

jcoffey-dev added 2 commits 2026-09-29 00:31:14 +00:00

DLP and mail flow rules: the rule model, the engine and the node cache c8280de9c3

Phase 2e of the DLP and mail flow rules spec, in the features crate.

- rules.rs: a rule (§2.2) with its conditions (§2.3) and actions (§2.4),
  as JSON under R/r in the fork's subspace. validate() enforces the
  spec's shape: DLP rules check outgoing mail and have exactly one of
  block, warn or hold; transport rules have neither those nor
  detectors; lists, header names, header values (one line), addresses,
  texts, word lists, patterns and detector ids are checked.
- engine.rs: rules compiled once (word lists to automata, patterns to
  size-limited regexes) and run in priority order with exceptions and
  stop processing. Each detector runs at most once per message and
  only when a rule asks for it. The outcome lists what matched with
  each detector's count, and decides DLP strictest first: block, hold,
  warn; an override answers warnings only (§2.5).
- cache.rs: each node's compiled copy, refreshed after 30 seconds or at
  once when this node changes a rule.

Nothing calls this yet: the JMAP object and the check at DATA follow.
55 unit tests in mailflow.

DLP and mail flow rules: inbuxa:MailRule over JMAP, and its permissions

ci / fork-checks (pull_request) Successful in 15s

Details

ci / build (pull_request) Successful in 4m41s

Details

8afaee7d21

Phase 2e of the DLP and mail flow rules spec, the API half.

- inbuxa:MailRule/get and /set under urn:inbuxa:jmap. Rules convert
  through serde, so what a client sends is the stored format. A create
  or change is validated whole (Rule::validate) and refused with the
  property at fault; id, createdBy, createdAt and updatedAt are the
  server's. Every change goes through the request layer's audit record.
- Six permissions, ids 674-679 (enum and schema labels): mail flow rules
  (sysMailRuleGet/Update), DLP rules (sysDlpPolicyGet/Update) and held
  mail (sysDlpReviewGet/Update, for phase 3). Either kind's permission
  gets through the gate; the handler shows and changes each rule only
  with its own kind's. All server-level: a tenant is refused (settled
  answer 3).
- Administrators get all six; the server-level Compliance Officer gets
  DLP rules to see and held mail to review (settled answer 4), added
  once to an existing server's officer role by the grant mechanism,
  which gains an officer audience.
- Privacy catalog entry for inbuxa:MailRule.

tests/src/system/mail_rules.rs: create, list in order, validation,
server-set properties refused, update, kind-separated permissions for
an officer, destroy, audit records.

jcoffey-dev merged commit a3a36cd5d7 into main

2026-09-29 00:36:26 +00:00

jcoffey-dev deleted branch feature/dlp-rules

2026-09-29 00:36:27 +00:00

jcoffey-dev referenced this pull request

2026-09-29 01:23:35 +00:00

Release 2026.9.28.6 #107

jcoffey-dev referenced this pull request

2026-09-29 05:39:08 +00:00

Release 2026.9.29 #121

DLP and mail flow rules: rules, engine, and inbuxa:MailRule over JMAP #103