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

Conversation 0 Commits 2 Files Changed 27

+2468 -48

2 Commits

Author	SHA1	Message	Date
jcoffey-dev	8afaee7d21	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 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.	2026-09-28 17:29:35 -07:00
jcoffey-dev	c8280de9c3	DLP and mail flow rules: the rule model, the engine and the node cache 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.	2026-09-28 17:29:35 -07:00

Author

SHA1

Message

Date

jcoffey-dev

8afaee7d21

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

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.

2026-09-28 17:29:35 -07:00

jcoffey-dev

c8280de9c3

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

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.

2026-09-28 17:29:35 -07:00

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