Going postal¶
Before the move, Purple Lantern’s mail was already at Proton, on the old name, and every other provider wrote to that mailbox: the registrar, the forge, the host, the bank. Email looks like a way of talking to people. In a one-woman company it is the identity system. It receives password resets, account invitations, domain notices, security alerts, invoices, recovery links, and the occasional message from somebody who has decided that “urgent” is a substitute for planning. The scrap for this layer says: the address is the identity, the mailbox is furniture.
The doorstep¶
The new address is post@purplelantern.eu. It was added to the existing Proton account, which takes custom domains
on its paid plans, and Proton handed back the records to put in the zone at Infomaniak: MX, SPF, DKIM,
DMARC, all of them. So the address exists because the domain exists, and it is routed to whichever mailbox the
MX records in that zone point at. Change the provider and the address stays. That one fact decides everything else
on this page, because it means the mailbox provider can be kept for what it does, and replaced when it stops doing
it, without telling the world and discovering a hundred and forty-seven forgotten accounts.
The provider was already in place, so instead of choosing one it got checked against the list Purple Lantern would have chosen by:
European ownership, European law, data stored in Europe
subprocessors named in public
custom domains, with the domain administered elsewhere
mail that exports, and clients that speak standard protocols
no requirement to use the provider’s registrar or hosting
account recovery that works, and termination and export procedures that are written down
Proton is Swiss, operated by Proton AG with the non-profit Proton Foundation as primary shareholder, on servers it owns, with its primary datacentre in Zurich, and it supports custom domains on every paid plan. The one item on the list it misses is standard client access. Proton Mail does not speak IMAP or SMTP directly; desktop clients reach it through Proton Mail Bridge, a local application on a paid plan that presents an IMAP server on the workstation and does the encryption in between. So there is a dependency on Proton’s software as well as on Proton’s service, and it went on the map. Thunderbird over Bridge works, and exports. It is one more piece of Proton on the machine.
Four records¶
Everything that makes post@purplelantern.eu deliverable is a DNS record at Infomaniak, and none of it is at
Proton. Proton says what to publish; the zone is where it lives, and that is the reason the provider is replaceable.
Two MX records, from Proton’s custom-domain setup, say where mail for
the domain goes. Somebody who knows DNS could rebuild the routing from the zone export without logging in to Proton.
One SPF record says which servers may send mail as the domain. Proton, like most providers, asks for an include
of its own SPF domain rather than a list of addresses, which is convenient, and which means a provider change starts
with a DNS change before the mailbox moves. The mechanics are on the SPF runbook.
Three CNAME records publish the DKIM keys. Proton holds the private signing keys and signs outgoing mail; the zone
tells the world which public keys are legitimate. When changing provider, a new selector and key go in before the
old one comes out, which makes the move less dramatic than mail migrations have historically been. The
DKIM runbook covers the self-hosted version.
One DMARC record ties the two together and tells receivers what to do when both fail. It went in at p=none,
which reports and blocks nothing, and it is the only view a small domain gets of who is sending mail in its name.
The legitimate senders get fixed, then it goes to p=quarantine, which Proton
recommends for most domains, and later to p=reject. The policy belongs
to the domain and survives a provider change. See the DMARC runbook.
Two ways to lose a mailbox¶
Two different things can go wrong with a mailbox, and they have different exits.
The first is losing the way in: a forgotten password, a lost second factor, a locked account. Proton does not hold user passwords, so it cannot reset one, and its recovery methods are a twelve-word recovery phrase, a recovery email address, a recovery phone number, and an encrypted recovery file. Which of those is set decides what the Swiss mailbox actually depends on. A Proton account whose only recovery method is a Gmail address is recoverable for as long as Google says so. One whose recovery phone is a Dutch mobile number depends on that carrier, and on nobody porting the number away. A recovery phrase on paper in a drawer depends on the drawer. For the mailbox that receives every other provider’s recovery links, the phrase and the file are the methods that answer to nobody else, and the recovery email, if set, is on a domain and a provider that share nothing with the stack.
The second is losing the provider: Proton closes the account, or goes away. Here the domain is the anchor.
post@purplelantern.eu is an address at a domain held at Infomaniak, and the MX records that route it to Proton
are in Infomaniak’s zone. If the Proton account vanishes, the MX records change to another provider’s, say
mailbox.org in Berlin, and within a day post@purplelantern.eu receives mail again, at the same address, with every
registrar and forge still writing to it. What does not come back is the old mail, unless
an export was taken while the account still opened.
So the escape hatch is two things held outside Proton: the domain, and an archive.
There is a loop in there, and it was found by drawing it. post@purplelantern.eu is the recovery address for the
registrar, and the registrar is where the domain is recovered. If the mail account breaks, the registrar’s recovery
message cannot be received. If the registrar breaks, the DNS cannot be changed and the mail stops. Email depends on
the registrar, the registrar on the domain, the domain on email: a neat little circle, right up until it is not. The
circle got broken with one recovery route outside the primary domain: the recovery codes, kept in the vault. Which
route it is weighs less than that it exists.
Sending¶
Receiving and sending are different dependencies. Outgoing mail involves the SMTP server, its authentication, TLS, the sending address, reverse DNS, SPF, DKIM, DMARC, the provider’s reputation and bounce handling. That list is why running a mail server was considered and not done: control over the server arrives with responsibility for IP reputation, blocklists, spam handling, reverse DNS, TLS, queue management, abuse complaints and deliverability. For a one-woman company a European hosted provider is a better trade than becoming an email deliverability engineer by accident.
Spam filtering went the same way. The provider’s filtering can use its own engine, third-party reputation feeds, DNS blocklists, commercial threat intelligence and external scanning, and none of those upstreams is visible from a mailbox. The provider can be changed. Its upstreams cannot, and are written down as such.
The archive¶
This is what decides whether “migration” means migration. If the provider disappears, can the inbox, sent mail, archive, folders, attachments, contacts, filters, forwarding rules and aliases be got back? Mail itself is portable. Configuration usually is not. So there is an independent archive, an encrypted local one, taken with Proton’s export tool and kept with the other backups. The only copy of the correspondence has to live somewhere other than behind the login being recovered.
Delivered¶
.eu registry
│
European registrar
│
DNS
│
┌───────┼────────┐
MX SPF DKIM, DMARC
│
European mail provider
│
┌────────┼────────┐
Bridge webmail export
│
independent clients
│
independent archive
beside it:
offline recovery
│
└── registrar, mail provider, other critical accounts
The address belongs to the domain, the routing is in Infomaniak’s zone, the mailbox is at Proton, the archive is at
home, and the recovery route does not pass through the mailbox it recovers. Authentication sits beside the chain,
not underneath it. A designation, a sanctions decision, a changed acceptable-use policy or an acquisition could still
reach Proton, and the graph says what would follow: the MX records change, the archive is already here, and losing
the mail provider is an administrative nuisance, not an identity event.
In Lancre a witch’s cottage goes to the next witch, and the village keeps leaving the eggs on the same doorstep whoever is inside.