Hacker News Reader

Comment by oarsinsync | Hacker News Reader

Why would you need to make a point of allowing sub-addressing? Surely it’s whether or not you make a point of disallowing it?

View on HN

I work at a place that just recently clamped down on this. We decided to normalize the emails so that we have a column in the db like "email" and then also "normalized_email" where normalized_email has a unique key on it too. This way, people can still make their email look like whatever they want, but they also only get 1 per email inbox.

This was all because people were doing abuse more easily by churning lots of accounts while only needing 1 gmail address. Plugging this gap was a huge deal for us in reducing card testing problems.

We’ve done this for a long while too. You can use subaddressing, but you’re still limited to one account per “base email”. We also normalize dots and other methods of reusing an email account.

Just changing the delimiter would probably thwart most efforts like this. I self host so am not limited to the + character. So, I currently use name-subaddress@domain. I could easily switch to using underscore as my delimiter. Or I could just use subaddress@domain. This is dead simple and I don’t even have commercial motivation. Good luck!

I mean, sure, but it does thwart the vast majority of users who don’t even know this is an option. Most people don't know you can have an email from someone other than the major providers, let alone on a custom domain or selfhosted.

At the end of the day, nothing will thwart a determined person. But that’s not the goal. If it deters the vast majority of your users from making duplicate accounts, then it’s still a success.

Perfect is the enemy of good, after all.

Yes, and another super cool thing is the prevention of accidental screwups where someone typos their email. If the typo collides with an existing account after normalization, it could be (correctly) rejected. Without this normalization index, you could have ronx@gmail pre-existing, someone trying to type "rob.x" typos "ron.x" -- and now a bunch of emails start going out to poor "ronx" (who often doesn't understand what's going on, thinks his account is 'hacked,' etc. Ideally, the system would (for Gmail addresses) reject "ron.x" knowing it's basically tied to an existing user.

> We also normalize dots and other methods of reusing an email account.

Is that limited by domain? gmail's dot handling isn't at all standard; e.g. john.doe@outlook.com and johndoe@outlook.com are different accounts, as are john.doe@icloud.com and johndoe@icloud.com.

Yes. Some of it is handled by our email verification provider while others are done in-house based on real-world experience. We handle a bunch of the major domains that our users use.

This sounds like a very nice compromise actually. I'm surprised it helped with abuse though, since there's a lot of email providers that are easier to create an account with than gmail.

It's trivial to defeat though, all you need is your own domain and an email provider that supports catch all email addresses.

A big part of handling abuse is to recognize that you cannot win - all you can do is better. And a big part of abuse is just raising the bar of sophistication required to abuse you. We went from "any random script kiddie with a gmail account gets infinite accounts easily" to "now someone has to use a custom email domain" (which is easy for us to just banhammer the domain), which both requires sophistication and money. And it makes the banhammer-swing more on par with the amount of effort they have to put in to evade it - banning the domain means go find another domain and pay another registrar fee.

You could 'accidentally' prevent it by enforcing some incorrect regexp like [a-zA-Z0-9]@[a-z.]+

Not allowing a '+' to appear in the local part is not even that unreasonable. It's against the standard, but then "My email is this@example.com"@example.com is valid according to the standard so take the standard with a grain of salt.

What's the issue with "My email is this@example.com"@example.com? Why disallow it, or use it to argue that the standard isn't good?

> Why disallow it, or use it to argue that the standard isn't good?

Because lots of folks fat finger their own e-mail addresses and then complain that a 'site sucks' because signing up doesn't work. Sanity checking to protect people against themselves may be treated as a form of UX: it's probably why some forms insist you type (not copy-paste) your e-mail twice.

I'm perpetually flabbergasted by how anyone thinks this "no pasting" thing is a pro-accuracy idea. As though people would be copying from a bad source. I see this a lot on forms for bank account numbers -- maybe one of the least amenable formats to visually copying down and retyping, since they're never written with delimiters or punctuation. I store them in my password manager, and then some idiotic form wants me to type my 18-digit bank account number, twice, on my phone, where I can't see more than one application at a time.

It's just to illustrate that the standard is more complicated than people might realise. I think you'll have problems getting most systems to accept an email address with two @s in it, but I might be wrong. Either way it would definitely break some (not too well written) code.

Though if possible I'd err on the side of being too permissive rather than too restrictive. In the end the only true way to validate an address is to send it an email.

https://www.rfc-editor.org/rfc/rfc5322.html

This is the standard.

“Taking it with a grain of salt” results in broken websites and servers that reject valid mail addresses.

Reply on news.ycombinator.com