Hacker News Reader

Comment by tsimionescu | Hacker News Reader

This also depends a lot on why you are comparing those addresses. If you want for example to make sure that you don't easily allow the same person to register multiple accounts (say, to take advantage of a free trial period), then they are both wrong, since X@gmail.com, X.@gmail.com, X..@gmail.com etc. are all the same account and cost nothing to make.

However, if you just want to make sure this is the same user that signed in earlier, you get to chose what rules you want - it's their problem to some extent to remember what account name they gave you.

View on HN

Just a nitpick: Gmail doesn't allow consecutive periods, so X..@gmail.com doesn't work. You can do a.bc, a.b.c, ab.c etc. instead.

Oops, you're right. Did they also support user+somestring@gmail.com to be equal to user@gmail.com as well?

Yeah, they support +something. Sadly lot of websites don't accept it as a valid email address because of the +.

I wonder if that's because they know people use + to tag for later spam blocking, or is it just a lazy regex user who needs to read this article?

IME it's the latter, but not because they are lazy, but because email validation is hard. The lazy regex was in the late 90's early 00's when any email that didn't end in .com, .edu or .net failed!

The problem is insufficient laziness. Just check that the email contains an `@` sign, and validate later by corresponding with the address.

    if "@" in email:
      send_confirmation(email)

Which is truly terrible. I mean, here's a valid email that was used in the early 90s:

    sdchema!mhtsa!australia!chris@Nosc

Our website blocked it inadvertently, we were using ASP.NET Identity which has internal email validation which by default does not accept it. Just flipping a flag in the configuration is enough to allow it, but until someone reported the problem I wasn’t even aware it was blocked.

Found a mailing list ("marketing") service that allowed you to sign up with a +, but any 'unsubscribe' was a link to a URL with your email in it, with the + sign in it, and... the unsubscribe page could magically never find your address to unsubscribe you. I submitted this as a bug report to the service, and was brushed aside. At that time, I also had a couple friends who worked there, and tried to run it up the flagpole there, and I was told about half the folks there didn't understand the problem, and the other half didn't really care, because the + trick was seen as very niche. So I started reporting all the newsletters I got as 'spam' - well after I'd tried to unsubscribe.

You could sign them up using many + emails

Did you try to replace the + in the unsubscribe URL with %2B (the urlencoding of a +)? Because interpreting the URL on the server will almost certainly mean urldecoding the arguments which will turn + into a space.

Doesn’t the browser do this for you?

Nope, cause + used to mean space. So plus symbol has sometimes to be left alone, some times replaced - due to still supporting legacy stuff and the newer RFC that makes + go away.

FWIR, yes. And it didn't work. They had some weird parsing going on to deal with some weird legacy stuff from years earlier, and... it made life more complicated than it needed to be.

I ran in to the exact same thing.

My solution was subscribing "legal+i_bet_you_will_fix_it_now@service.com" to the same list.

I just wrote a post[1] about using the user+alias@example.com instead of user@example.com. Basically treat your "regular" email address as a spam target, and use user+alias for all wanted communications. The +alias can be a random string, making it harder for spammers to guess.

This works in gmail for both sending and receiving, although sending as you+alias@gmail.com requires messing around in the settings[2] and having to remember to select a non-default From: address in your outgoing mail.

[1]: https://alexshroyer.com/posts/2022-09-01-Default-Honeypot.ht... [2]: https://webapps.stackexchange.com/questions/3598/is-there-an...

If this gained widespread adoption, then spam would just +string and you'd have to allow-list.

Allow-list isn't the worst, but this isn't a long-term solution in and of itself

True, but the nice thing is it that allow-lists can be handled transparently by your email client.

Never saw this +string before? Mark as spam.

Is the +string missing? Spam.

Recognize this +string from your "Sent" folder? Keep.

Signing up for something? Generate a pseudorandom +string and add it to the allow-list.

Actually RFC 5322 says that you can't have two consecutive periods.

What RFC 5322 says you can do and what Google will allow you to do with an @gmail.com user part are two different things.

Except in this case, where they're the same thing.

Since Gmail allows this.

Not all providers are Gmail.

Which makes the problem even worse. Are you supposed to have comparison rules per provider then? Only for those that are large enough to bother in your particular use case?

It just means you cannot use email validation as a way to limit one account per person. A person could just have another email on another provider anyway.

It's part of the reason why you see many places ask for your phone number, not that I agree with that, and even this method has many flaws.

My favorite issue with phone number-based identity verification is that it doesn't account for multiple different countries well at all. In some regions, getting more than one 'legit' phone number (i.e. not on any of the VoIP blocklists) per person is nearly impossible, while in other regions, even in the Western world, it's very much possible to buy a lot of pay-as-you-go plans, keep the numbers from expiring, and use them to retain perhaps dozens of accounts at no to minimal cost, making it yet another measure that affects legitimate users disproportionately compared to it affecting illegitimate users.

I really wish there was something that was easy to get as a company but hard to get as an individual. As a B2B SaaS, I want to do the organization-level equivalent of KYC — "Know Your Corporate Buyer"? — but there's no such thing.

Instead, all anyone offers in this vein are identifiers that are really annoying to get and that nobody already has as a matter-of-course of registering a company; such that many real companies can't (or won't bother to) pass them. DUNS numbers are a common choice. Our company is five years old and doesn't have a DUNS number. It takes two weeks to get one. So how could I expect our customers to bother getting one just to try our product?

"can you set this value in a TXT field on your DNS" or another domain-level challenge-authentication mechanism would be one. Sure, anyone can buy a domain but in theory that is what Extended Verification is supposed to represent, so if you get a valid handshake from an EV domain then in theory you're talking with someone representing the organization that the EV certificate was issued for.

Of course in principle you can get an EV cert for any company as well, but now we're talking about determining whether a company is sufficiently well-known to accept, which is not something that can fully be solved deterministically since that's a human judgement, there will always be some grey areas. But, there are certainly a lot of companies that could probably be "automatically verified" in some fashion (ford motor company? reasonably well-known, and this is their domain...) given some sort of authoritative domain -> stock mapping, and that's not impossible to do if you trust the EV scheme.

Anyway, not perfect, but challenges based raises the bar a lot from "register domain with godaddy and sign up for let's encrypt" to "first you have to get an EV certificate..."

Of course, since such a mechanism is not widely used... not exactly going to find tons of official support for using it like that. But the mechanisms are there!

Isn't a company itself a thing that is easy to get as an individual, in certain jurisdictions?

Yeah, but not usually easy enough that you can make hundreds/thousands of them quickly for a single purpose and then throw them away.

Also, as a slight tweak, I'd hope that this authentication scheme would only admit legal companies that are at least a week old. People who do these sorts of bulk-registration attacks tend not to be patient people, willing to wait around for their credentials to gain reputation before using them. They create them and then try to use them right away. Whereas no real company would be signing up for most B2B services in its first week of legal existence. (Google Workspace? Sure. Accounting software? Probably not.)

Ultimately this depends on what the attack is.

If it's targeted to X company for a specific reason, they'll wait however long they need. If it's generic and X company is just caught in the crossfire, then maybe.

>Whereas no real company would be signing up for most B2B services in its first week of legal existence. (Google Workspace? Sure. Accounting software? Probably not.)

When I've registered companies in the past, it's when I have sales. Before then, it's just an idea to see if we get users. But the company with the service can determine that.

Corporate Number/Tax ID?

You can, however, use email parsing + heuristics as a way to detect people who are trying to register accounts that look like they ever could be part of a set of "related" addresses — and just reject even the first member in that set. (I.e. just reject registrations with a + in the username part in the first place.)

(You don't have to be petty about it; no need to send them to a "you're an attacker" page or anything. Just redline the form-field, explain the problem clearly, and let them modify the address until it's less duplicable.)

Yes, this doesn't stop people from manually registering multiple times, since, as you say, people can have multiple addresses; or even email service from multiple providers. But it does stop low-effort automated bulk-registration attacks. And some services — those with any sort of free-tier especially — get a lot of those!

That + sign as a label to the same inbox is a Gmail thing.

It's a 100% valid character to use. Doesn't have to mean it's a label in another hostname. Goes back to what others have said. You either end up with a ton of rules, or go with the fact that email isn't the best solution to identify unique users.

https://en.wikipedia.org/wiki/Email_address#Local-part

> The local-part of the email address may be unquoted or may be enclosed in quotation marks.

>If unquoted, it may use any of these ASCII characters:

> - uppercase and lowercase Latin letters A to Z and a to z

> - digits 0 to 9

> - printable characters !#$%&'*+-/=?^_`{|}~

> - dot ., provided that it is not the first or last character and provided also that it does not appear consecutively (e.g., John..Doe@example.com is not allowed).[5]

> If quoted, it may contain Space, Horizontal Tab (HT), any ASCII graphic except Backslash and Quote and a quoted-pair consisting of a Backslash followed by HT, Space or any ASCII graphic; it may also be split between lines anywhere that HT or Space appears. In contrast to unquoted local-parts, the addresses ".John.Doe"@example.com, "John.Doe."@example.com and "John..Doe"@example.com are allowed.

(it keeps going on the wikipedia page)

I know that it's allowed; but — given that we're a B2B company serving highly-technically-literate customers — I don't think I want the business of anyone who thinks it'd be a good idea to use it even when it is allowed, given how it'd affect their own deliverability to imperfectly-implemented MTAs.

(It's a similar "you're really relying on perfect competence from the whole rest of the ecosystem to get you out of this" feeling as e.g. putting a space in your user name — and thus your home directory path — in Linux. Sure, the core GNU/BSD/etc tooling has been tested for that use-case — but are you really going to trust random tools and shell-scripts to handle argument tokenization perfectly? Or are you just going to ditch the space to be safe?)

>serving highly-technically-literate customers

It would probably be the other way.

The more technical literate a user is, the more they'll understand and figure out how things work, the nuances, and use those things.

You know that core tooling that works? It's because technical literate users, tried it, found the issue, and fixed it.

Same way with me using é on my name. If something breaks on a website, email, etc, I create an issue and starts emailing. My name doesn't have an e, it has an é.

Yes, if you want to know if two addresses refer to the same account, you need to keep up with the actual rules for each provider that you decide to care about.

But, if you're using the email as a username just for convenience, you get to decide what rules you have for username comparison. You can absolutely decide that A@gmail.com and a@gmail.com are different accounts for your service, even though emails you send to these accounts will likely reach the same inbox. You can also decide that they are the same account, but that haşim@gmail.com, HAŞIM@gmail.com and HAŞİM@gmail.com are all different accounts. It's entirely up to you to know what is important for your users.

In this case, a@googlemail.com is also the same as a@gmail.com

you are supposed to not use email as a token of user uniqueness, because it's not.

the fundamental problem here is assuming that "emailA == emailB" could ever conceivably be used as a proxy of the equality "userA == userB". Unicode tarpits aside (that's a legitimate problem where even if you did everything exactly right, libraries or api calls etc might not) the idea of "do these mailboxes belong to the same user" (in the sense of stripping '+' suffixes from gmail boxes etc) cannot be answered period. You cannot affirmatively confirm this nor can you disprove the assertion either, without some additional information about the behavior of the receiving mail transport agent.

even if you understand the behavior of the receiving MTA, you cannot prove that they don't have an email account somewhere else, so that is not sufficient either.

email is not a key for user uniqueness, period. It's a channel for contacting a user. You don't mess with it, and you simply send an email and see if the session user can authenticate it. If you want identity verification that happens at another layer, not email.

"transforms" like lowercasing or mailbox-suffix-stripping are only window dressing patching around this fundamental issue. There is no way to affirmatively go from "email address" to "user identity" without more information from another layer. It's a communication channel, not an identity provider. You can (reasonably) use it as a medium to talk to the user while you verify them against something else (although like SMS it can of course be hijacked unless your IDP protocol accounts for this possibility) but "email verification" is not and can never be an IDP in itself. Gmail addresses are free.

I don't think I know a single person, tech-savvy or not, that only has one email address.

> (in the sense of stripping '+' suffixes from gmail boxes etc)

I have a few accounts. Those + suffixes drive a bunch of rules on them to get me to take action. They forward to my primary email address if it's important.

Some of them get scraped and mailed in a weekly summary. Some of them send text messages alerting me.

When they mess with them, I'll probably just not see it unless I have to login for some other reason to that account.

Yes - other providers have their own strange ideas of what it means for two emails to be equal.

My point is that there is no standard that you can use to decide if two email addresses refer to the same inbox.

Each provider has their own rules for what emails they consider identical, and you need to either invent your own rules, or learn what theirs are, depending on why you are doing this.

Using Unicode aware string comparisons doesn't solve the issue any more than byte-wise comparison or ascii case-insensitive comparison.

But you can't just say "if hostname == gmail.com", since it should also be done for any domain that uses Google Workspace for email.

Of course. That's the problem.

You can't reliably say that a.b@ and ab@ are the same user except in a very small population (gmail.com) because you don't know how other domains will handle it.

Email is not a unique identifier which is how they're wanting to use it.

GMail users are anything but a small population.

Not users wise, but domain wise. Just one domain vs all the domains out there.

Badly worded on my part.

Reply on news.ycombinator.com