# tailwart — lessons learned

Hard-won notes from bringing the mail edge up. Each entry is **symptom → cause →
fix**, ordered roughly by how long it cost. Read this before re-debugging.

## 1. Postgres startup race ate cert/setting writes

**Symptom:** TLS certs (manual import *and* ACME) would validate but never
persist — Stalwart kept serving its `rcgen` self-signed fallback. Logs showed
`Failed to create tables: error connecting to server` on most boots.

**Cause:** Stalwart shares the `ts-stalwart` sidecar's netns. Its `depends_on`
only waited for the sidecar's *own* health (`/healthz` = "tailscaled up"), which
flips green **before** the tailnet route to Postgres (`the-record-prod:5432`) is
usable. Stalwart started into that gap, failed the DB connect, and any write in
that window — including a freshly obtained cert — was silently lost.

**Fix:** the sidecar healthcheck now also requires Postgres to be reachable
(`nc -z … 5432`), so `depends_on: service_healthy` can't release Stalwart into
the race. See `docker-compose.yml`. First clean boot after this: zero PG errors,
4 live connections immediately.

## 2. DNS-01 was blocked by a dead Spaceship API key

**Symptom:** `Failed to set DNS RRSet: Unauthorized` on every record; no cert
issued; no `_acme-challenge` TXT ever set.

**Cause:** the cert design is ACME **DNS-01** via the **Spaceship** provider
(bundled in caddy/lego). The stored API key was invalid (recovery debris from an
earlier config attempt). Note `STALWART_ACME_PROVIDER` / `STALWART_ACME_TOKEN`
in `.env` are **empty and not even passed through by compose** — the provider +
secret are entered in the **admin UI** (stored in the DB), not via env.

**Gotcha:** secret fields render **blank** in the Stalwart admin even when set
(the S3 secret behaves identically). A blank field is *not* evidence it's unset.

**Fix / how to verify a key directly (egresses the box's WAN IP, same as
Stalwart):**
```bash
curl -i 'https://spaceship.dev/api/v1/dns/records/<domain>?take=5&skip=0' \
  -H 'X-Api-Key: KEY' -H 'X-Api-Secret: SECRET'
# 401 application.unauthorized = bad key/secret or IP-restricted
# 200 = good
```
A fresh Spaceship key fixed it.

## 3. Stalwart's auto-ban vs PROXY protocol (the "8080 mystery")

**Symptom:** the edge box could relay mail fine but could **not** reach
Stalwart's `:8080` admin — connections accept then immediately close. Looked like
"tagged devices rejected, user phone works."

**Cause:** Stalwart's fail2ban checks the **proxied client IP** (from the PROXY
header) on the mail listeners, but the **raw connection IP** on the non-proxied
admin listener. A banned edge-box IP therefore still relays mail (ban checked
against the header IP) while direct `→:8080` is dropped (checked against the box
IP). Malformed probing of the mail ports **re-arms** the ban.

**Fix:** add `100.64.0.0/10` (and the box's WAN IP, which appears as the proxied
client when you hit the box's own public hostname) to the fail2ban allow-list.
Bans are in-memory — a Stalwart restart flushes them. **Don't rapid-poll the mail
ports** to test.

## 4. The wildcard request *required* DNS-01 (why HTTP-01 was a dead end)

With "Additional Hostnames" left empty, Stalwart requests a **wildcard**
(`*.<domain>`). Wildcards can **only** be issued via DNS-01 — HTTP-01 literally
cannot satisfy them. We burned time on an HTTP-01 + Caddy-challenge-forwarding
detour before realizing DNS-01 was the intended (and only viable) path. One
wildcard cert then covers `mail`, `mta-sts`, `autoconfig`, `autodiscover`, etc.

## 5. `:443` web endpoints need SNI pass-through, not L7 proxy

MTA-STS / autoconfig / autodiscover serve over **:443**. You cannot L7
`reverse_proxy` them through Caddy, because the **CAA** record pins issuance to
Stalwart's ACME account — Caddy can't get its own cert for those names. Stalwart
holds the wildcard, so the edge **passes TLS through** by SNI. See
`caddy/README.md` → "The HTTP side". Needed `tcp:443` added to the
`reverse-proxy → stalwart` ACL grant.

## 6. The sidecar is ephemeral — never hardcode its tailnet IP

`ts-stalwart` runs with `?ephemeral=true`, so its tailnet IP **changes on
re-registration** (an ACL re-sync did this mid-debug: `100.112.26.122 →
100.79.87.80`). Everything must use the MagicDNS name
`stalwart.tail7b1641.ts.net`. A hardcoded IP will mysteriously go
`Network is unreachable`.

## 7. Don't trust crt.sh for rate-limit checks

crt.sh was flaky/empty all session. To gauge Let's Encrypt's weekly
duplicate-cert limit, use **certspotter** instead:
`https://api.certspotter.com/v1/issuances?domain=<d>&include_subdomains=true`.
Also: LE limits are dimensioned — **failed validations** are hourly (5/hr/host,
the one a retry storm trips), **issued duplicates** are weekly (5/wk). A renewal
task hammering every 10 min trips the hourly one; consolidate to a single task.

## 8. The Stalwart container has no IPv6 — AAAA targets fail before IPv4 is tried

**Symptom:** Outbound delivery (and relay-to-smarthost) to any host with an
AAAA record fails with `I/O error: Network is unreachable (os error 101)`.
Hosts that are IPv4-only deliver fine. Pointing a relay at a *hostname* that
has both A and AAAA fails; pointing it at the raw IPv4 works.

**Cause:** Stalwart shares the `ts-stalwart` sidecar's netns, which has no
global IPv6. When it resolves a dual-stack target it tries the AAAA first,
gets `ENETUNREACH` immediately, and for a **relay next-hop it does not fall
back to the A record** — it just records the v6 failure and backs off. So a
single missing address family wedges all mail to dual-stack destinations.

**Fix:** Either (a) pin the relay/smarthost `address` to an **IPv4 literal**
(no AAAA to trip on), or (b) give the container real IPv6. Note that relaying
over the **tailnet** sidesteps this entirely — you connect to a tailnet
`100.x` address, which has no AAAA, so the v6-first trap never triggers.

## 9. Configuring IPv6 on the KVM host does NOT give the container IPv6

**Symptom:** `ip -6 addr` and `ping6 google.com` succeed on the KVM host, but
Stalwart still dies with `os error 101` on AAAA targets, and the box is still
a broken IPv6 Tailscale exit node.

**Cause:** The host's `eth0` and the container/sidecar netns are separate
network stacks. Adding the provider's `/64` to `eth0` (ifupdown `inet6 static`
+ `onlink` default route, since the gateway is in a different /64) fixes the
*host*, not the container. Docker doesn't hand IPv6 to containers by default,
and the sidecar routes via Tailscale, not eth0.

**Fix:** Don't assume host IPv6 = container IPv6. Test from *inside* the
container's netns. For mail egress, the IPv4-literal relay (Lesson 8) or the
tailnet relay avoids needing container IPv6 at all. Enabling true container
IPv6 (Docker IPv6 + routing the /64 in) is a separate, larger task.

## 10. The VPS blocks ALL outbound SMTP ports — relay over the tailnet

**Symptom:** Direct MX delivery and relay-to-public-host both fail with
`Connection timed out (os error 110)`, and the SYN never arrives at the
destination. Not just port 25 — `465`, `587`, even alt-port `2525` all time out.

**Cause:** The KVM provider blocks all outbound SMTP submission ports to prevent
spam. Only non-SMTP ports (`443`, etc.) egress. Confirmed with:
```bash
for p in 25 465 587 2525 443; do
  timeout 5 bash -c "exec 3<>/dev/tcp/<dst>/$p" && echo "$p OPEN" || echo "$p blocked"
done
# 443 OPEN, all SMTP ports timeout
```

**Fix:** Relay over the **tailnet**. Tailscale rides WireGuard/DERP (UDP 41641 /
443), so it's immune to SMTP port filtering. Point the relay at the smarthost's
**tailnet IP** (e.g. `100.x:587`), not its public address. Long-term: ask the
provider to unblock outbound 25/587 for verified use.

## 11. The sidecar can RECEIVE on the tailnet but can't INITIATE without an ACL grant

**Symptom:** The relay to `<mailbox-tailnet-ip>:587` times out (`os error 110`),
yet the **KVM host** (same physical machine) can reach that exact IP:port over
the tailnet fine. Looks like a routing or transparent-proxy bug.

**Cause:** The Stalwart container rides the `ts-stalwart` sidecar — a **separate
tailnet node** (`tag:stalwart`) from the KVM host. The `tailwart` ACL block only
listed `tag:stalwart` as a **destination** (`"dst": ["tag:stalwart"]`). Tailnet
is default-deny, so the sidecar could receive connections but could not
*initiate* the relay back to the mailbox → silent drop → timeout. The KVM host
worked because it's a different, permitted identity, which masked the real cause.

**Fix:** Add an ACL rule granting `tag:stalwart` as a **source**:
```json
{ "src": ["tag:stalwart"], "dst": ["tag:mail"], "ip": ["tcp:587"] }
```
(mailbox is `tag:mail`). Applies in seconds, no restart. See `acl-snippet.hujson`.

## 12. Stalwart only rebuilds its MTA route table at container startup

**Symptom:** You edit an `MtaRoute` (address, etc.) via API/UI, but delivery keeps
using the old value. The datastore shows the new value; live delivery ignores it.

**Cause:** The `routing_strategy` map is built once when the process boots. The
`ReloadSettings` action reloads the datastore but does **not** rebuild the SMTP
route map. So route/strategy changes are invisible until restart.

**Fix:** After any `MtaRoute` / `MtaOutboundStrategy` change,
`docker restart tailwart-stalwart-1`. (Side effect: the ephemeral sidecar gets a
new tailnet IP each restart — anything addressing it by IP must rediscover it;
use the MagicDNS name where possible.)