Catch-All E-mail Addresses

Most people have an e-mail address like firstname.lastname@provider.example where provider.example is an e-mail provider. They have only this one e-mail address and give it to every service where they sign up.

I use my domain martin-ueding.de, and I can have virtually unlimited e-mail addresses on it. For a while now I had been using the concept of service e-mail addresses. So when I created an account for buying from the renowned widget store store.example, I would give them store.example@martin-ueding.de as my e-mail address.

Advantages

This process has a couple of very nice advantages.

Legitimate e-mails that I get from them would likely have a sender address like orders@store.example such that one could filter for them. But they might also use some other domain to send e-mails from, or use a third-party sending service that sends stuff on their behalf. Since I can just group by recipient address, all these details do not matter.

Other people might try to impersonate some website and send phishing e-mails to me. But as they would only have some other e-mail address, I would see that they are not directed to the correct recipient address to be legit. Say if I would get a mail from some payment service stating I urgently need to log into my account but would have received it to an address that I had given to some other service, I would know that it is a illegitimate mail.

Most of my junk e-mail is sent to the mail address that I use with git. Some of the junk goes to addresses that have been made public in a data breach and are now used by spammers. This makes it easy to just block that recipient address and never get any of these mails any more. Also I can see whether a company actually had a breach or sold my address.

Some services allow a single person to have multiple accounts. Then having unlimited e-mail addresses makes it rather easy to set up these accounts.

This is similar to the "plus syntax" that some e-mail providers offer for filtering. One would then use firstname.lastname+store.example@provider.example to have this same filtering. My approach is non-standard and therefore people cannot easily filter away everything after the plus sign. For all legitimate purposes the plus syntax is fine, but it makes it too easy to deduce the main e-mail address.

Disadvantages

All in all this is a pretty nice setup, but there are a couple of downsides too.

Foremost in the implementation I just use a catch-all mail account such that all mail to martin-ueding.de is delivered to my inbox. This opens up to junk e-mails that is addressed to some random inbox on my domain, and there are such drive-by events every now and then. To get around this I have a couple of special mailboxes (my main one and the one I use in git) and then a special prefix that I use for these service addresses. I could then block everything that is neither a special mailbox nor starts with the prefix.

In the mail client one cannot simply reply to these mails, the sending address will always be the main one of your account. In some programs one can add additional identities, but this is a tad more work. This means that I cannot just click reply for some services unless I have the proper sending address set up.

If I bought from store.example right away, I would use something like store.example@martin-ueding.de as my mail address. But when using the broker broker.example to do my business, I would give broker.example@martin-ueding.de to that service. The broker would give broker.example@martin-ueding.de to the shop but also a hotel and other services. If the mail address broker.example@martin-ueding.de was then used for spam, I could not be entirely sure that it was the broker or the shop or the hotel.

Also if I bought from the shop already with shop.example.com@martin-ueding.de it would not recognize the address that I gave the broker. In the end I have two accounts and would have to work towards merging them later on. This also bites me when I have contact with people over these service addresses and I actually want them to use my main address eventually. So when somebody asks me for my mail address, it is a little trickier than just having a personal and work address.

Services merge or get bought. So I had different e-mail addresses for Skype and Microsoft, but now they are one thing. Also Ubuntu's Launchpad had a separate account, now I can log in with my Canonical account. This makes it a bit weird as my Launchpad e-mail address has effectively changed now.

This setup also requires me to have a whole domain for mail, which is not particularly hard. But it means that I cannot just go for a mail provider which does not support such a catch-all setup.

Leaving this system

I have a few addresses that were exposed in data breaches, and it helps to identify these and block the involved addresses. Additionally I have more confidence when it comes to phishing e-mails because I have an additional indicator. The logistics of having a different address for each service is manageable, but still an overhead.

The tipping point was reached when my primary personal address appeared in some spam lists and started to get spam as well. I cannot just change my e-mail address as I would have to notify all the people and make them update it in their address books. And it would end up getting spam at some point in the future. Somehow this does not even matter. The amount of junk e-mail that I get is already high, so I have to think about filtering it. And once I have a junk filter in place, it does not really matter how much junk I get. This is why I ended up going "all in" an just use my primary e-mail address everywhere. This makes identity management much easier and it makes it quite easier!

This required me to change my e-mail address with the various services. And it is amazing how inconsistent the address change experience is across the services.

Eventually I will be able to step back from the catch-all. As I often get the same junk e-mail to different addresses on my domain, the amount of spam might actually go down after that step. I'll have to see.