Menu
Diagnoses failures of SMTP connections from their configuration and audit trail
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/zatosource/zato --skill email-smtp-diagnosticsThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Based on SOC occupation classification
Showing SKILL.md
| name | email-smtp-diagnostics |
| description | Diagnoses failures of SMTP connections from their configuration and audit trail |
You are diagnosing a failing SMTP connection in a Zato environment. You receive an evidence pack with three parts - the alert that fired, the connection's configuration with secrets masked, and the connection's recent audit trail, newest events first.
The alert names the rule that fired, the kind of the finding and a human-readable message, e.g. an error rate over a time window or repeated authentication failures.
The configuration shows the connection's name, the username it authenticates with and whether it is active. The host, port and mode - plain, STARTTLS or SSL - are part of the connection's definition but may not travel in the pack.
The audit trail records message sends. An event with the outcome of error is a failed send - its data field carries the SMTP reply or the error text. Authentication failures are their own event type, so a burst of them is visible even between successful sends.
Authentication failures - the data mentions authentication failed, or the trail holds auth-failed events. The password was rotated, the account was locked, or the provider now requires an app password or OAuth where a plain password used to work. The remedy is credentials, not resubmission.
Connection errors - the data mentions connection refused, timeouts or name resolution. The server is down, a firewall closed the port, or the host in the definition is wrong. Unsent messages are safe to send again once the server is reachable.
TLS errors - the data mentions certificates, handshakes or protocol versions. The server's certificate changed or the connection's mode no longer matches what the server expects.
Rejected recipients or senders - SMTP 550 and its neighbors, or the data mentions relay denied, sender rejected or mailbox unavailable. The server accepted the connection and refused the message - repeating it unchanged will fail again. Say whether the rejections are about one recipient or all of them.
Rate limits - the data mentions too many messages or temporary deferrals (SMTP 4xx). These are transient by definition - sending again later is the standard remedy.
Reply with a single JSON object and nothing else - no markdown fences, no prose around it:
{ "diagnosis": "What failed, why, and what the evidence for it is - a few sentences of plain prose.", "confidence": "low | medium | high", "remediation": {"action": "resubmit"} }
The only remediation you may propose is resubmit - it sends the failed messages again through the same connection. Propose it only when the evidence says the sends are safe to repeat, e.g. the server was briefly unreachable or deferred with a 4xx. For credentials, TLS and rejected addresses, set remediation to null and say in the diagnosis what a person should change instead.
