postsleuth
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mail_dns_checkA | Check the DNS records receivers use to accept or reject your mail: MX, SPF (syntax, 10-lookup limit, whether the sending IP is authorised), DKIM selector keys (presence, key size), DMARC policy and reporting, PTR with forward confirmation (FCrDNS) against myhostname. |
| postfix_configA | Delivery-relevant non-default Postfix settings from postconf -n (relayhost, TLS policy, SASL, concurrency/rate limits, queue lifetimes, domains, milters). Secret-looking values are redacted. |
| postfix_doctorB | One-call diagnosis of a Postfix server: queue summary, qshape of the deferred queue, log outcomes for the window, DNS authentication checks, and a list of findings with next steps. |
| postfix_log_statsB | Aggregate the Postfix mail log over a time window: totals (received, sent, deferred attempts, bounced, expired, smtpd rejects), per-domain outcomes, domains still failing, grouped deferral reasons and bounce causes with category and hint, and DKIM selectors seen in signing logs. |
| postfix_log_traceA | Follow one message through the log by queue ID or email address: every line for each matching queue ID (smtpd, cleanup, qmgr, smtp/local, bounce notifications) and its final status. |
| postfix_log_trendA | Per-destination deferral rate over time buckets from the mail log: sent/deferred counts and rate per bucket, plus a direction (improving / worsening / flat / insufficient_data) comparing the early vs late half of the window. Use to see whether Gmail/Outlook/etc. is getting better or worse. |
| postfix_provider_playbookA | Recovery playbooks for the big mailbox providers: Gmail / Google Workspace (421 4.7.28 rate limit, 5.7.26-5.7.32 SPF/DKIM/DMARC, PTR, TLS, reputation), Microsoft Outlook.com / Microsoft 365 (S3150 block list with SNDS/JMRP, 5.7.606-649 banned IP, 5.7.511, 4.7.650, SC/DY/OU/RP codes, 5.7.515, 5.7.705-750) and Yahoo / AOL ([TSS04]/[TS*] deferrals, [TSS09], [BL21]/[BL23], 5.7.9). Each playbook says what the code means, whether Postfix will retry or retrying is pointless, ordered steps (Postfix-specific, e.g. a dedicated transport with destination_concurrency_limit = 1 for Gmail 4.7.28; never flush the queue at a throttling receiver), and the provider's official pages. Modes: with no arguments, scans the queue and the mail log (since, default 24h) and returns the playbooks for what is failing here with evidence counts and affected domains; with reply, looks up one pasted SMTP reply without reading the server; with id, returns one playbook. Read-only: it never contacts the providers or changes the queue. |
| postfix_queue_listA | List queued messages (queue ID, queue, arrival time, size, sender, recipients with delay reasons), filtered by queue, recipient domain, sender, reason text, reason category or minimum age. |
| postfix_queue_messageA | One queued message, from its queue file (postcat -e -h; the body is never read): which queue it is in, arrival time and size, every envelope recipient with its state (pending / delivered / canceled) and, for pending ones, the delay reason with category, hint and provider playbook; the Received route oldest first (hosts, IPs, TLS, per-hop delay); DKIM signatures and whether they align with the From: domain; the primary headers; and notes (missing Message-ID/Date, unaligned DKIM, bulk mail without one-click unsubscribe, null sender, on hold). Always redacted: local parts become [user-N] (domains kept), display names, subjects and free-text headers are hidden, credential-like headers removed. |
| postfix_queue_shapeA | qshape-style matrix of a queue: rows are recipient (or sender) domains, columns are message age buckets in minutes (5,10,20,...,1280+). Shows which destination is backing up and since when. |
| postfix_queue_summaryA | Summarise the Postfix queue (postqueue -j): counts per queue, top recipient and sender domains, delay reasons grouped and classified with hints, oldest message. |
| postfix_reason_categoriesA | List the failure categories postsleuth assigns to delay/bounce reasons, with the hint for each. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.