Samir Boulahtit
1227567d08
Some checks failed
Hetzner Cloud silently blocks outbound TCP 25 and 465 on every Cloud Server. The block sits upstream of the VM — UFW and iptables look completely clean — so it presents as a generic "connection times out" that's easy to misdiagnose as a credential or DNS issue. Spent ~5 hours on 2026-05-30 working through swaks/tcpdump/auth-backend hypotheses before finding Hetzner's own docs that mention the policy. Two doc additions: - Step 4 (Firewall Configuration) gets a warning admonition right after the UFW status check. Explains the upstream nature of the block, gives the symptom signature (nc to 587 succeeds, nc to 465 silently times out), and includes the auto-approved unblock ticket template with sample text. - Step 19.5 (Alertmanager SMTP) gets a "live prod uses mail1.myservices.hosting:465" callout reflecting the reality that the SendGrid setup documented in that section is no longer how this prod env is wired. The callout captures the actual smarthost config (with smtp_auth_password kept gitignored, only .example ships in repo), the two prerequisites (Hetzner unblock + implicit-TLS-aware smarthost port), and the redacted swaks verification command. The rest of §19.5 stays as a reference for greenfield deploys that prefer SendGrid. Saves the next person from repeating the same hours-long detour. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>