Description

MAILGUARD

// policy-driven mail control plane

Mailguard

products/mailroute · proton-bridge · glither.mail

A mail control plane whose rules are the glither.mail dialect — messages settle to delivered/dropped or rest in quarantine, every verdict produced by a capability-sandboxed wasm policy.

MAILGUARD · GLITHER.MAIL · PROTON-BRIDGE · MCP · LITESTREAM · WASI

Mailguard is a standalone product in the RAGBAZ stack. It classifies inbound mail through a rule pipeline; its policy language is Glither (the glither.mail dialect), so verdicts run as capability-sandboxed WebAssembly rather than in-process rule evaluation.

A

Mailguard

1

policy-driven mail control plane

A mail control plane: inbound sources feed a pipeline of steps that classify each message into buckets (inbox · newsletters · quarantine · drop), governed by rules, with webhooks, a blacklist, and tamper-evident mail + audit logs.

Glither is Mailguard's rule engine. Mailguard's rules are the glither.mail dialect, the easy, degenerate case of Glither: a flat delivered/dropped verdict plus one suspended state quarantine : Pending<{delivered, dropped}> resolved by admin.release or a deadline. The same engine drives the other dialects elsewhere in the stack — Mailguard is the proving ground.

technical choicesRules compile to sandboxed wasm verdicts (not in-process eval) · edit-as-proposal workflow (propose → apply → revert, fully audited) · the pipeline path is itself recorded data.

valueSpam/spoof/malware control with a legible, reviewable, reversible policy and a tamper-evident trail — safe acceptance of less-trusted rules because verdicts run in a VM.

functionalityDKIM/DMARC/allowlist selection · quarantine with release/TTL arms · external-sender tagging · mailbox routing · blacklist · webhook delivery + log · runtime health.

interoperabilitymailstack provides mailboxes/domains/DKIM under it · webhooks push downstream · MCP tools let agents inspect & propose · Glither/WIT verdict interface is portable.

usabilityRules read like docs/examples/mailguard.glith · proposals diff against live · source/runtime status give operational visibility.

securityVerdicts execute in WASI/OCI (no exfiltration, no escape) · audit + revert bound the blast radius · capability inputs only (a rule sees handed message fields, nothing else).

work in progressGolden-rule conformance suite (message → expected verdict); per-source trust tiers → capability budgets; quarantine liveness-lint integration; tighter mailstack↔mailguard DKIM provenance.

B

Runtime & operations

2

proton-bridge · MCP · replication

deploymentDocker (proton-bridge based) at products/mailroute/caas/proton-bridge; SQLite DB bind-mounted at mailguard-data/mailguard.db (→ /data in the container).

endpointMCP/GraphQL on 127.0.0.1:8765 (the mcpgw mailguard subgraph expects http://127.0.0.1:8765/mcp/v2); 8765 avoids the :4000 supergraph clash.

durabilityLitestream replicates the SQLite DB to an off-box SFTP replica (fillmeup) so a disk loss is recoverable — added after the 2026-05-17 data loss when no off-box replica existed.

recoveryrecover-mailguard.sh rebuilds the DB + service idempotently (recreate · replica-keygen · replica-enable · status); destructive wipes require MAILGUARD_FORCE=1.