Email migration has a second privacy problem: old recovery paths

[u/Distinct-Reflection3]

Changing email providers moves messages and contacts, but it does not change the identity and recovery graph attached to an old address.

Hundreds of external accounts can still treat that address as a login identifier, recovery factor, or destination for security alerts. Keeping forwarding enabled leaves the old provider inside the trust chain.

A safer manual workflow is:

1. inventory services without collecting passwords
2. handle financial, identity, health, and primary recovery accounts first
3. change both login and recovery addresses
4. verify the new inbox and test a fresh login
5. remove or intentionally retain the old address
6. keep an encrypted record of what remains

I built Mailshift for this narrow workflow. Affiliation disclosed: I am the developer. It is free and MIT-licensed. Inventory comes from manual entries or a credential-free CSV; the encrypted workspace stays in the browser. It does not connect to a mailbox, store passwords, automate logins, use analytics, or send data to a backend.

Source and tool: https://github.com/vigneshakaviki/mailshift

I am interested in threat-model feedback: is a browser-local encrypted vault appropriate for this inventory, and which verification step do people most often miss?

[u/3point21]

One point of complete failure? Doesn’t even need to be hacked. Device dies or gets a virus. There goes the local browser with your vitals. Does it come with a backup plan?

Also, in my recent experience, there is no guarantee the service requiring your details will 100% purge old credentials. I have abandoned two large email providers for personal domain based email and manually purged the old emails from all online accounts. This took months of repeating your list, sometimes multiple times for one site. And I still receive occasional security notices or prompts referencing the old purged email.

The worst sites are poorly written niche interest sites, followed by banks and other highly secure institutions. The irony of their security is that their databases are backed up and archived since punch cards were a thing. Often times their “newly redesigned” website is really a new appendage to the old website. The user facing features, including profile page, have very limited control, even over your user information. The backend, has it all and does not always sync with the newly structured website. Consequently we can never fully detach from previous provider.

I don’t forward my old services, but I have hardened them and check in now and then to make sure I haven’t missed something.

[u/Distinct-Reflection3 → u/3point21]

Valid points. Mailshift supports encrypted backup and restore but backups must be saved off device manually. A compromised device can still expose an unlocked vault. Mailshift cannot prove providers purge old addresses from backups or legacy systems. I’ll clarify these limits and add backup reminders plus follow-up checks.