Decide IMAP/SMTP service endpoint architecture (imap./smtp. vs per-MX)
closedQuestion (discussion only, no code yet)
The setup guide currently points clients at one MX hostname
(mx1.sovrn.at:993/587). A friendlier and more ops-coherent option is
dedicated service names — imap.sovrn.at, smtp.sovrn.at — as A records
aimed at whichever Stalwart server is active. Related: 6ca5959
(multi-MX / failover).
Points to resolve
- Failover story: repoint A records (mind TTL) vs floating VIP vs MX priorities — which do clients actually follow for IMAP/SMTP?
- Stalwart: Automatic certs must SAN-cover the service names; Http01
then needs
:80answering for each name (Caddy challenge vhosts per name) or a wildcard via DNS-01 instead. - Caddy never proxies mail ports (no L4) — only the ACME-challenge concern above applies.
- Load balancing later: do service names become the stable client contract while mxN names stay operator-internal?
- Guide/UI copy: one service hostname per protocol instead of per-MX.
Outcome
Decision recorded here (or folded into 6ca5959), then SAN/TLS, DNS, and guide changes fall out as implementation issues.
1 Comment
Decided under bug 75966cc (cell architecture tracking — locked 2026-09-13): per-cell
MX<number>.<region>.sovrn.at(e.g.mx1.eu.sovrn.at,mx2.us.sovrn.at) is the client contract for IMAP/SMTP/MX in v1.imap./smtp.service names rejected for v1 — no extra TLS SANs, no challenge-vhost sprawl, no TTL-sensitive client failover. Clients follow their cell’s mxN hostname; failover moves the floating IP, never DNS. Closing; revisit only if a later HA phase needs stable service names.