logredact

Overview ¶

Package logredact keeps personal data out of process logs.

Container stdout is shipped to centralized log storage with long retention and broad queryability, so log lines are NOT a private scratchpad: an email subject, an external human's address, or a free-text rejection reason in a log line is personal data replicated outside the database's access controls. The policy:

• Never log message subject lines — log subject_len instead.
• Never log an EXTERNAL human's full email address — log only its domain (AddressDomain) or, for recipient lists, the count plus the distinct domain set (AddressDomains). e2a AGENT addresses are our own namespace and the primary tracing key, so they stay in full — but only once the address has RESOLVED to an agent row. An unresolved recipient is just an attacker-supplied string (SMTP RCPT runs before any authentication) and is redacted like any external address.
• Truncate connecting IPs to a network prefix (IPNetwork): /24 for IPv4, /48 for IPv6 — enough for abuse/rate-limit debugging, less identifying.
• Cap free-text human input and third-party error bodies (Truncate).
• Redact at the LOG SINK, not at the source. A value that is also stored, served by the API, or emitted in a webhook (e.g. a HITL rejection reason) must stay precise there; only its log copy is reduced.

Only the subject rule is machine-checked, by the tripwire scan in logguard_test.go; the rest is a code-review responsibility.

Every helper here runs on hostile external input on the SMTP hot path and must never panic; malformed input degrades to a safe placeholder.