postsleuth
<p align="center"><img src="assets/logo.svg" width="72" alt="postsleuth logo"></p>
# postsleuth
**Why isn't Postfix delivering?** postsleuth reads the queue (`postqueue -j`), the mail log and DNS, groups every stuck message by *why* it is stuck, and tells you what to do next. It works as a CLI and as an MCP server, so an AI agent can investigate a mail server without being able to touch it.

<sub>Demo uses generated snapshot data (`testdata/gen.py`) via `--queue-file` / `--log`.</sub>
## Install
```sh
go install github.com/Blackman99/postsleuth/cmd/postsleuth@latest
```
or grab a binary for Linux, macOS or Windows from [Releases](https://github.com/Blackman99/postsleuth/releases/latest).
## Use
```sh
postsleuth doctor # queue + qshape + log + SPF/DKIM/DMARC/PTR, with next steps
postsleuth queue --domain .outlook.com
postsleuth shape --by sender # who filled the deferred queue
postsleuth trend --domain gmail.com # deferral rate over time — getting better?
postsleuth playbook # Gmail 4.7.28, Outlook S3150, Yahoo [TSS04]…: the provider's way back
postsleuth message F543B5DFCE # one queued message: route, DKIM, headers, redacted
postsleuth trace bob@example.org # one message, start to finish (from the log)
postsleuth dns example.com --ip 203.0.113.7
```
When Gmail, Microsoft or Yahoo is the one refusing you, `playbook` (and the `PLAYBOOK` section of `doctor`) names the provider code, says whether Postfix's retries can succeed, and gives ordered recovery steps written for Postfix with links to the provider's own pages: 18 playbooks, from Gmail's 4.7.28 rate limit and 5.7.26 DMARC failures to Outlook.com's S3150 block list (SNDS, JMRP) and Yahoo's [TSS09]. `postsleuth playbook --reply "…"` looks up a single reply.
When one message is the question, `message QUEUE_ID` reads its envelope and headers with `postcat -e -h -q` (never the body) and shows which queue it sits in and since when, each recipient's status and delay reason, the `Received:` route with TLS, whether its DKIM signature aligns with From:, and header problems that get mail refused, such as bulk mail without RFC 8058 one-click unsubscribe. Output is redacted by default: domains stay, local parts become `[user-1]@example.com`, the subject and display names are hidden, credential headers are removed. `--unredacted` exists on the CLI only.
Postfix in a container or on another box: `--wrap "docker exec -i mailserver"` or run it over `ssh`.
## MCP
```json
{"mcpServers": {"postsleuth": {"command": "postsleuth", "args": ["mcp"]}}}
```
All tools are read-only, and `postfix_queue_message` is always redacted. Requeue, flush, hold and delete exist only when the server is started with `--allow-mutations`, and each call still needs `confirm: true`.
**[Docs](https://blackman99.github.io/postsleuth/docs/)** · [Website](https://blackman99.github.io/postsleuth/) · [Goal](GOAL.md) · [Roadmap](ROADMAP.md) · MIT
TDQS
Scored across 12 tools
Queue tools split cleanly by granularity (summary/counts, shape/age matrix, list/filtered rows, message/full detail), and log tools split cleanly by axis (stats/aggregate, trace/single message, trend/time buckets). The only mild overlaps are postfix_doctor, which bundles summary + log stats + DNS into one call, and postfix_queue_summary vs postfix_log_stats, which both report deferral reasons with hints; descriptions make the intended use distinct enough to avoid misselection.
Eleven tools follow a clean postfix_<component>_<action-or-object> snake_case pattern (queue_summary, log_trace, queue_message, config). The single mail_dns_check breaks the postfix_ prefix, a minor inconsistency but still readable and semantically sensible.
12 tools is well within the ideal band for a Postfix diagnostics server, and each tool earns its place by covering a distinct facet (queue, log, DNS, config, provider playbooks, reference data). No filler or redundant variants.
The read-only diagnostic surface is thorough: queue inspection across four granularities, log aggregation/tracing/trending, DNS authentication checks, config review, and provider-specific recovery playbooks. The main gap is actionability — no tools to retry, flush, hold, or remove queued messages — though the server explicitly frames itself as read-only, so this is a minor, workable gap.