jcoffey-dev
f44382fb09
The hold action now holds (dlp-and-mail-flow-rules spec, §2.6), where until now it blocked. - At DATA a hold decision queues the message with its release a century off (the queue's future-release mechanism, so the stored format is unchanged and an older node just never sends it), transport rules still applied, and replies 250 Held for review. A review record under R/h + queue id keeps the sender, recipients, subject, size, rules and detector counts. The sender is told when the rule asks. - smtp/queue/held.rs: release (each recipient due now, its next notice as far off as it was, its lifetime counted from the release), reject (removed from the queue, the sender told, with the reviewer's note), and expiry: the daily clean-up rejects what nobody reviewed in 7 days, recorded as the server's doing. - inbuxa:HeldMessage get/set: the review queue, sysDlpReviewGet to list and read (preview, 64 KB of text, only when asked for and recorded as blobAccess), sysDlpReviewUpdate to release or reject, a reason required and audited by the request layer; no create or destroy; server-level only. - Guards: Emails > Queue refuses to change or delete held mail; the sender can't unsend it. - Privacy catalog entry for inbuxa:HeldMessage; spec §2.6 as built. Tests: mail_rules_tests gains the whole flow (held and listed with counts, sender notified and nothing delivered, queue and unsend refused, preview recorded, reject needs a reason and tells the sender the note, release delivers, expiry returns it, decisions audited with reasons). smtp inbound, system_tests (after one BlobNotFound in antispam, the known flake, then clean), features and common unit tests.
33 lines
1.0 KiB
Rust
33 lines
1.0 KiB
Rust
/*
|
|
* SPDX-FileCopyrightText: 2026 Coffey Labs
|
|
*
|
|
* SPDX-License-Identifier: AGPL-3.0-only
|
|
*/
|
|
|
|
//! Data loss prevention and mail flow rules (dlp-and-mail-flow-rules spec).
|
|
//!
|
|
//! Mostly pure functions over text and attachment bytes, unit-tested
|
|
//! without a server:
|
|
//!
|
|
//! - [`detectors`]: find identifiers in text (payment cards, IBANs,
|
|
//! national ID numbers, keys), each by its published format and check
|
|
//! (§2.3);
|
|
//! - [`words`]: an organization's own word lists and patterns;
|
|
//! - [`extract`]: the text of an attachment, or why it can't be read;
|
|
//! - [`rules`]: what a rule is, its checks, and where rules are kept;
|
|
//! - [`engine`]: rules compiled and run against a message;
|
|
//! - [`cache`]: each node's compiled copy;
|
|
//! - [`rewrite`]: the actions that change a message.
|
|
//!
|
|
//! Nothing here writes what it finds anywhere: callers get counts, and the
|
|
//! matched text never leaves the evaluation (§2.7).
|
|
|
|
pub mod cache;
|
|
pub mod detectors;
|
|
pub mod engine;
|
|
pub mod extract;
|
|
pub mod held;
|
|
pub mod rewrite;
|
|
pub mod rules;
|
|
pub mod words;
|