c58a236d70
Implement remediation-aware health checks across all Doctor plugin modules (Agent, Attestor, Auth, BinaryAnalysis, Compliance, Crypto, Environment, EvidenceLocker, Notify, Observability, Operations, Policy, Postgres, Release, Scanner, Storage, Vex) and their backing library counterparts (AI, Attestation, Authority, Core, Cryptography, Database, Docker, Integration, Notify, Observability, Security, ServiceGraph, Sources, Verification). Each check now emits structured remediation metadata (severity, category, runbook links, and fix suggestions) consumed by the Doctor dashboard remediation panel. Also adds: - docs/doctor/articles/ knowledge base for check explanations - Advisory AI search seed and allowlist updates for doctor content - Sprint plan for doctor checks documentation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2.3 KiB
2.3 KiB
checkId, plugin, severity, tags
| checkId | plugin | severity | tags | |||||
|---|---|---|---|---|---|---|---|---|
| check.notify.email.connectivity | stellaops.doctor.notify | warn |
|
Email Connectivity
What It Checks
Verifies that the configured SMTP server is reachable by opening a TCP connection to the SMTP host and port. The check:
- Opens a TCP socket to
SmtpHost:SmtpPortwith a 10-second timeout. - Reads the SMTP banner and verifies it starts with
220(standard SMTP greeting). - Reports an info-level result if the connection succeeds but the banner is not a recognized SMTP response.
- Fails if the connection times out, is refused, or encounters a socket error.
The check only runs when both SmtpHost and SmtpPort are configured with valid values.
Why It Matters
A configured but unreachable SMTP server means email notifications will silently fail. Release gate alerts, security finding notifications, and approval requests will never reach operators, potentially delaying incident response.
Common Causes
- SMTP server not running
- Wrong host or port in configuration
- Firewall blocking outbound SMTP connections
- DNS resolution failure for the SMTP hostname
- Network latency too high (exceeding 10-second timeout)
How to Fix
Docker Compose
Verify network connectivity from the container:
docker exec <notify-container> nc -zv smtp.example.com 587
docker exec <notify-container> nslookup smtp.example.com
Ensure the container network can reach the SMTP server. If behind a proxy, configure it:
environment:
HTTP_PROXY: "http://proxy.example.com:8080"
Bare Metal / systemd
Test connectivity manually:
nc -zv smtp.example.com 587
telnet smtp.example.com 587
nslookup smtp.example.com
Check firewall rules:
sudo iptables -L -n | grep 587
Kubernetes / Helm
Verify connectivity from the pod:
kubectl exec -it <notify-pod> -- nc -zv smtp.example.com 587
Check NetworkPolicy resources that might block egress:
kubectl get networkpolicy -n stellaops
Verification
stella doctor run --check check.notify.email.connectivity
Related Checks
check.notify.email.configured— verifies SMTP configuration is completecheck.notify.queue.health— verifies the notification delivery queue is healthy