Hacker News new | past | comments | ask | show | jobs | submit login
The Case for Unique Email Addresses (tychi.me)
28 points by tylerchilds on Oct 17, 2020 | hide | past | favorite | 19 comments



I do this with fastmail. Besides privacy, another benefit is you can set up routing rules. e.g. for subscribing to newsletters, use <whatever>[email protected]. Anything that goes to an address that ends in [email protected] gets marked as read and is delivered to a folder for newsletters. I do a similar thing when signing up for services. It's kinda like what Gmail does with ML, but you have more control.


I do this with gmail, when I register an account I'll use [email protected].

Whoever with more than two brain cells would notice and strip the suffix out, but they usually don't bother with a database leak.


Do you know if they actually don't bother? The article author makes it sound like tracking companies do in fact normalize gmail addresses. I suppose my custom ___domain addresses wouldn't be too hard to normalize either if you have a way to take a ___domain and get a probability for how likely it is to be a personal ___domain. It provides a little extra friction at least, I guess.


Tyler, get to the point. I’ve been reading for 5 minutes about Facebook, Tim, and Inflection... and just got to “backstory”. The backstory has a backstory too?

Just think about focusing on your primary point.


I'm all for concision, particularly in technical writing. But not every article has to be like that. This article feels like a mix between an essay and a public journal entry, and I thoroughly enjoyed reading it.


I agree. I gave up halfway through. The author is exceptionally long-winded.


For 12 years, I have had an email setup where all emails for the ___domain go to one mailbox (postmaster style). Then, I just give each service their own, unique email address without any configuration. Any spam or unusual mail is then easily-identified. Plus, it makes for easier searching, sorting and tagging. A good, secure, backed-up email & webmail setup is necessary to make it work.

For anything I don't care about and want better anonymity, I'm fine with using random, public disposable email addresses.


I've started doing this and have ended up depending on my password manager to track which emails I need for logging in to a service, which is a bit of a hassle although I think it's still worth it for the reasons you outlined. For example, did I use [service]@___domain.com or [abbreviated-service]@___domain.com, or was it [service.com]@___domain.com...?


The only service I have that problem with is Microsoft since it's a merge of like three different accounts (MSN messenger, Skype, and Office365) so I can never remember which is the right one.

Otherwise my rule is to use the central part of the ___domain name (no www or TLD), or it's easy enough to just search my email archive for messages from whatever service.


I also find that some services don't let you use their name in your email address.

Samsung is one I remember which wouldn't let me use [email protected], I managed to get by with [email protected]. Definitely one for the password.

Then again, we should be using unique passwords for everything anyway, so a password manage is a must regardless of how you handle emails.


This also happens to some extent in real life. Often when I say that my email is "[email protected]" it's met with a "well, if you're just going to give me a fake address…". At which point I have to explain 1) catch-all email addresses, and 2) yes, you can own your own entire ___domain name.


Near enough everything is in my password manager. I use <service>.<month>.<year>.<nonce>@___domain so I have to so to speak.

Using keepassxc + its browser and mobile extensions make this easier than typing the address in myself. I was astounded at how bad the ux the paid pw mamagers I've used is


The only real reason I use unique email addresses is to handle spam from services I signed up to, and discover data breaches of my own email.

1) Companies that conveniently forget that you opted out of marketing emails every 9 months or so, now I can blacklist them.

2) Twice now has a service had a data breach and I've only found out because I've received spam to the unique email


Also interesting to note which politicians or charitable causes sell your name to which entities.


I have own ___domain and use unique address and password for each service. This lets me know which one leaked it.

When Adobe lost both my address and password I tried contacting their support (I was paying customer). The support person repeatedly said they checked and my credentials were safe. This regardless the fact I had proof. Very disappointing.

Since then I had couple other situations like that.

I guess companies assume users are idiots and use same password everywhere and so they feel safe nobody can prove it is them ho lost it.


In theory I agree. In practice I strongly disagree. As soon as I hit more than maybe 3 email addresses it became a burden to maintain and I totally regret it.

I could do <servicename>@example.com to make things easier but this is less secure than <random>@example.com


I find that <servicename> is actually adequate. Your primary adversaries are all automated and the technique is not so widely used to date as to be accounted for by the bots at large. I guess for that extra edge of security you could do it in pig latin.


Getting the mail isn't the problem. Sometimes I have to reply to those company and especially in a Mail client setup it becomes difficult to reply from <company-name>@mydomain.tld and I often end up replying from <my-first-name>@mydomain.tld and they have my main email as well. Unless of course I setup a "reply-from" for each of these <company-name> emails I used.


> Sometimes I have to reply to those company and especially in a Mail client setup it becomes difficult to reply from <company-name>@mydomain.tld

This was very easy with Unix mail clients twenty years ago — what is wrong with Mail that it doesn't support this functionality?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: