Since I’ve been changing my email address on so many different online accounts over the past few weeks, I’ve developed some strong feelings about best practices and worst practices for how companies handle this stuff.
It’s generally a good practice to send out notifications to both old and new email addresses, preferably with a confirmation link in the email sent to the new address. And it’s a good practice to avoid including any key details in the email sent to the old address, in case the user is changing the address because the old account has been compromised. That’s the way most services handle things, but I’ve seen some that send no confirmations at all, which is a little alarming, from a security standpoint.
The weirdest thing I’ve seen so far in that area is from one of my credit cards, which has sent me a daily notice that I’ve changed my email address every day for the last four days, to both addresses. I’m hoping that’ll stop eventually, but I think maybe they’re caught in a loop, and I’m going to get a notice every day for the rest of my life.
Another bad practice that a lot of companies seem to do relates to email newsletters. Changing your email address for an online account should really change over any newsletter subscriptions that are related to that account. What I’ve seen instead is usually one of the following:
- The systems are entirely separate, and changing the account address has no affect on newsletter subscriptions.
- The change automatically subscribes you to newsletters at the new address, but doesn’t stop the newsletters going to the old address.
- The change automatically subscribes you to newsletters at the new address, even if you’ve previously unsubscribed from newsletters at the old address.
And, also, most newsletter management systems don’t provide any way to change your email address. So you need to unsubscribe from the old address and resubscribe with the new one.
I found that the NY Times did a good job in this area, smoothly migrating over all of my newsletter subscriptions when I changed my email address on my account. The New Yorker, on the other hand, required me to unsubscribe and resubscribe to everything. And their subscription management system somehow subscribed me to all of their newsletters at my new address, so I’ve had to unsubscribe from a bunch of them.
Another bad practice is related to handling “plus alias” email addresses. These are supported in both Gmail and FastMail, and I often use them when subscribing to newsletters to make filtering a little easier. But I’ve found that a lot of online systems don’t recognize a plus sign as valid within an email address. (At this point, I could go down a rat hole, complaining about bad practices around email regex validations, but I’ll restrain myself.) It’s not so bad when the address is rejected on the front-end, but I’ve gotten into some situations where the email address is accepted initially, but then causes some problem later on down the line.
FastMail also supports something they call “subdomain addressing”, which allows you to get around the “plus sign” issue, but I didn’t want to start using that, since I didn’t want to set up a lot of stuff that would make it too hard to switch my domain from FastMail to a different provider. (Plus aliases are supported by multiple providers, including Google and ProtonMail, but I don’t think subdomain addressing is.)
Also, I just read the FastMail support doc that I linked above and noticed this statement:
If the part after the “+” matches the name of one of your folders (see below for how the matching works), the message will automatically be delivered there instead of your Inbox. You don’t even need to create an explicit rule!
That’s really cool, but I’m kind of annoyed that I didn’t know about it until now, after I’ve already set up a bunch of rules. Oh well. I’ll keep it in mind for new stuff.
Speaking of rules, I now have about sixty of them set up in FastMail. I could probably cut that down a bit by getting a little creative with them, but that’s not a ludicrous number, I think.