Keeping the Old Addresses Alive

A mail platform doesn’t replace the old one the day it goes live. Decades of accounts, contacts, newsletters, and government logins still point at old addresses, and some of them will never be updated. Migration isn’t an event, it’s a bridge you have to keep standing for years. This post covers the three pieces of that bridge on my platform.

Pulling mail nobody will forward

The clean solution for an old mailbox is forwarding: tell the old provider to send everything to the new address. Some providers, including the Belgian ISP hosting a family member’s oldest mailbox, simply don’t offer it. POP3 access, yes; forwarding, no.

So the platform pulls instead of waiting. A small fetchmail container polls the old POP3 mailboxes on a schedule and injects whatever it finds into Stalwart over SMTP, where it lands in the right person’s inbox like any other delivery. The old address keeps working, the person reads everything in one place, and the old provider is reduced to a mailbox we occasionally empty.

Fetchmail is genuinely old software, and its decades-old assumptions meeting a 2026 container stack produced my favorite absurdity of the epic. Fetchmail’s SMTP injection sends an EHLO with the machine’s hostname, and Stalwart, correctly, wants a valid FQDN there. A container’s default hostname is a hex ID, and changing it normally means privileged tricks. The fix: the entrypoint runs fetchmail inside its own UTS namespace (unshare --uts) so it can set a proper hostname without touching the host’s, which in turn means this tiny mail-polling container needs the SYS_ADMIN capability. The oldest tool in my stack demanded the strangest privilege. It also taught me that fetchmail’s config parser cares about line endings, discovered the way these things are always discovered.

The second domain

I also hold cumps.be, and mail sent there should reach us. Stalwart handles this as an alias domain: anything for name@cumps.be is rewritten inbound and delivered to name@cumps.eu. One directory of accounts, two front doors.

Receive-only is a deliberate boundary. Sending as the alias domain is a different project entirely, with its own SPF, DKIM, and alignment story, and my first attempt at the rewrite taught me why boundaries matter: the initial Sieve script rewrote recipients on every SMTP stage instead of only inbound delivery, which is the kind of thing that works until it very much doesn’t. It’s now scoped to inbound only, and outbound mail is always the primary domain. The .be domain’s SPF record also earned a documentation-reality reconciliation of its own along the way, a small preview of a lesson that gets a full post later: DNS truth and repo truth drift apart unless something forces them together.

The web half of the bridge

A domain is more than its MX records. With mail for cumps.be flowing into the platform, the web side needed an answer too: anyone typing the old domain, or following a link from an ancient signature or bookmark, should land somewhere real. So Traefik carries permanent redirects: cumps.be and www.cumps.eu both answer with a 301 to cumps.eu. A few lines of routing config in the shared KV store, and every way someone can reach for an old name, mail or web, arrives at the current one.

Redirects are also the cheapest form of canonicalization. Exactly one hostname serves content; every variant publicly declares itself a pointer. Search engines see one site instead of scattered duplicates, the variants get real TLS certificates so even the redirect happens encrypted, and nothing anyone saved, printed, or half-remembers ever dead-ends.

Combined, the three mechanisms mean the migration has no deadline pressure. Old addresses drain through fetchmail, the second domain funnels mail into the same inboxes, and its web traffic lands here. The bridge can stand for years, and it costs nearly nothing to keep it standing.

Next week is a post I couldn’t resist: the machinery serving the words you’re reading right now.