6 ms·
> So if you’re enforcing unique email addresses, or using email addresses as a user identifier, you need to be aware of this and you probably need to strip all
by bradleybuda 9y ago
> So if you’re enforcing unique email addresses, or using email addresses as a user identifier, you need to be aware of this and you probably need to strip all dot characters from the local-part, along with + and any text after it, before doing your uniqueness check. Currently django-registration doesn’t do this, but I have plans to add it in the 3.x series.
Please don't "normalize" email addresses like this. Not all mail systems are Gmail, and many do treat "john.doe@example.com" and "johndoe@example.com" as different identities. And even if we are talking about Gmail - it's not your identity system's job to deduplicate different logical addresses for the same physical inbox.
- jcranmer 9y agoTo emphasize your point: don't touch email addresses. You can get away with doing equality checks on NFKC case folding, but don't assume that you can store a lowercased email address and have it work properly. Lots of weird email systems exist. Don't assume that everybody works like gmail. And do test that things work right with uppercase letters in email addresses: I've been locked out of systems before because I use an uppercase letter in my email address and one half of the system was trying to match the lower cased version to the actual text.
- ubernostrum 9y agoUnfortunately, Gmail rules the world and has trained people to expect that they can be sloppy and inconsistent and enter their email address as 'johndoe' or 'john.doe' or 'JohnDoe' or 'John.Doe'... etc. and it just works, I don't understand why your site is broken, because my email works! And when that happens, trying to patiently pull a "well, technically" and explain to them about RFC this and the specs say that is a way to lose users. (I actually have extremely strong feelings about email, email addresses and the whole associated mess of specs, but had to tone it down for this article since it was mostly about the various traps you can wander into from naïvely thinking that you can just read a spec or implement something obvious and get away with it)
- kqr 9y ago> And when that happens, trying to patiently pull a "well, technically" and explain to them about RFC this and the specs say that is a way to lose users. Not in my experience. Showing compassion and agreeing with them that what happened is terrible and you wish things were different but you didn't call these shots back in the days and if they want improvement you can both go together and complain to google, the service which is actually broken. Most people just want to be listened to. If you can do that, you'll earn a loyal fan, even if you don't do exactly what they tell you to when agitated. Some will even appreciate learning more about the email systems after the fact. They may even get the feeling you went above and beyond by offering to help them with matters outside of your site.
- ubernostrum 9y agoMost people just want to be listened to. Many people, even after being listened to, and even after having things patiently explained to them, still continue to enter someone else's email address into forms which will send sensitive information to that email address, and complain that they never got their important email, or that some "hacker" has "hacked" "their" email, etc. In a perfect world this would not happen. We don't live in a perfect world and are unlikely to live in a perfect world any time soon, so we should not be asking "how can we be pedantic and tell users it's their fault for not reading the RFCs", we should be asking "how can we protect users from their ignorance of the RFCs". (when I wrote this article, I did not expect that this would be the single most controversial line in it from HN's perspective, but I guess by this point I should have anticipated it)
- ajdlinux 9y agoI suppose the tradeoff here is when you get two non-Gmail users, johndoe and john.doe, who are legitimately different people, one of whom gets very confused and is actually unable to use their correct address. On the one hand, that's a (presumably extremely) rare corner case - on the other hand, some applications must handle those corner cases.
- spc476 9y ago
- inopinatus 9y agoThe local part (left of the @) of email addresses is case sensitive by definition and this should not be controversial. RFC5321 s2.4: The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". Even though it goes on to say: However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. This doesn't prohibit a local delivery agent (such as Gmail) consolidating multiple variants into one mailbox, but everything up until that point must refrain from making assumptions.
- craigds 9y agoThat's definitely controversial, and in my experience, just plain wrong. Many, many users sign up to a service with john.doe@example.com and get confused when they later try to log in with John.Doe@example.com. we had to add a fix for this in our django user model a couple years back. We havent had any complaints with the new, case insensitive system. IMHO this sort of this should be upstreamed but it seems Django have decided to stick with the spec in spite of usability.
- craigds 9y agoOh also, we used a CITEXT field for storing email addresses. Store the case the user registers with, and use that for sending comms etc, but uniquify and match (on login etc) in a case insensitive way.
- chatmasta 9y agoThis is an especially common problem when entering email addresses on mobile. Often autocorrect will capitalize the first letter. I always make sure it’s lowercase when registering, but I can see how this could easily lead to confusion.
- lsaferite 9y agoWeb pages (and apps) that don't indicate the input box is actually an email address so auto-correct won't capitalize for you are a serious peev of mine.
- neltnerb 9y agoOh, I assumed the recommendation was to store the actual email address as entered, and then also generate the fingerprint to compare for similarity. Wouldn't you just keep both?
- mhandley 9y agoThe problem is that jo.elane@example.com and joe.lane@example.com can be different people, or jan.eton@example.com and jane.ton@example.com. On gmail, they can't, but on my university email system for example, this is the default naming convension for circa 50,000 people. If you consider them to be the same, one of them can't sign up to your service. How often this happens? Probably not all that often. But if you run a popular service, it will bite a few people.
- Alex3917 9y ago> it's not your identity system's job to deduplicate different logical addresses for the same physical inbox. The problem is that then you're adding potential attack vectors to every single web app just to cater to the .01% of email clients that insist on implementing the email RFC exactly to spec. Not deduplicating email addresses creates an attack surface for both hard-to-spot technical issues and also social engineering attacks. E.g. what if your ESP at some point adds deduplication on their end, either mistakenly or on purpose, then suddenly you're sending password reset requests to the wrong users. I think you should normalize email addresses to enforce account uniqueness, both for security purposes and usability, as long as you also store a second copy of the email address exactly as the user entered it and only send email to the latter version.
- djsumdog 9y agoAt most you're allowing duplicate accounts to the same e-mail address. If you want to enforce 1 to 1 identities with e-mail accounts, you could have an issue. But in general, it shouldn't be a security concern.
- caf 9y agoYes. The answer to the question posed in the article is actually simple - there are 3 unique email addresses listed. The fact that email addressed to some of them may end up in the same box is neither here nor there.
- Alex3917 9y ago> The fact that email addressed to some of them may end up in the same box is neither here nor there. It's not an issue if they're the same, the issue is if they're different. E.g. if I'm storing bitcoin on an exchange (I know) behind the email@domain.com, then I don't want someone else to be able to register Email@domain.com and then start looking for bugs in the service or start trying to socially engineer customer support. (The local part of the email address is case sensitive as per the spec.)
- ubernostrum 9y agoYou hit the nail on the head. People can hem and haw about the specs, but at the end of the day Gmail trained most of the world to believe email addresses are case-insensitive, dots don't matter, etc., and now we have to live with the consequences. If that means somebody can't sign up for twelve accounts using case and dot variations of their Gmail, well, so be it. And if that means they come to HN to rant about how that awful site didn't follow the RFCs, then they come to HN to rant about that, but their account will be safer in spite of it.
- slavik81 9y agoMaybe. But, if I was legitimately john.doe@example.com and you refused to allow me to register an account just because somebody else had a similar email, I'd be pretty annoyed. There's a good chance I'd take my business elsewhere. I've only once had my email address rejected by a website (for ending with an underscore), but I never bothered setting up another email just for them.
- ubernostrum 9y ago
- quickthrower2 9y agothe best way is to err on the side of allowing a single email inbox to create multiple accounts. Who cares if they do? It's not like that person couldn't create multiple email addresses anyway. E.g. abc@gmail.com and def@gmail.com can be the same person. You can't validate for that, other than other "gamification" systems (e.g. how HN treats new users - disincentivizes creating multiple accounts because why be limited on your second one when you have a good first one). by the way I have used the + trick on google to sign up for a service (and pay for it!) that wouldn't let me reuse my old account for some reason. So their relaxed validation made them money.
- zbentley 9y agoIt's a difference in difficulty. More to the point, it's a difference in asymmetry of difficulty. Say you run an online store. You offer USD $5 in first-time user credit. A lot of people (even some nontechies I know) know about the "+" trick for gmail. Assuming your signup flow is easy and fast, it's very easy for those people to sign up for multiple accounts and get multiple $5 credits. If a lot of people do that, it might significantly impact your bottom line. Not just because you have to give away a lot of inventory, but secondary effects also suck: you stop the $5-free promotional, and then all of the legitimate users who signed up during the campaign who told their friends to sign up and get some free money now have their friends bad-mouthing the site to them because "it didn't give me free shit the way you told me I should expect it to!". You might see a drop in sign-ups to below pre-promotional levels, or, worse, you might see people who signed up during the promotional trust and use your site less. I know trends/behaviors like this seem trivial--and they definitely would only affect a minority of users--but past a certain scale effects like those can have a real financial impact. Now let's say your site is "smart" about the "+" trick and doesn't let people with gmail (or google-federated emails--boy, is figuring that out a bastard) accounts sign up multiple times. You'll lose the dubious potential business of folks who like gaming promotionals. You'll still be vulnerable to people creating second email accounts and signing up using those--but the difficulty asymmetry now favors you, the vendor: it's work for a user to make a second email account; work they probably won't do, especially if you blacklist typical temp email services like guerillamail. If the promotional is large enough to entice first-time users but small enough to deter people from doing this, you have succeeded in minimizing your loss. If the user already has a fleet of accounts for this purpose they're probably going to just take your money anyway. Of course, there's another more annoying scenario which I'll mention because sites should never do it: sites that think they're being smart about the "+" trick by not storing the part of the address between the plus and the domain part. This is usually done to get email campaigns (read: almost entirely spam) to show up in the user's main mailbox rather than some filter-purgatory. It will drive users away in two main ways: first, if I'm technical enough to use the "+" trick and a filter to route mail, I probably have enough obsessive annoyance with spam to immediately either junk-flag yours or delete my account, compared to a small chance I would have actually read it otherwise. Second, more than half of sites that do this which I've audited parse and strip the content of the email address wrongly (parsing emails is very hard, after all) in such a way that what they end up storing could be a totally different person's email, or an invalid one. That means signups just won't work. Whatever you do, don't do this. This doesn't only apply to first-time-user promotionals, either. It also applies to: - Referral bonus programs. - Services that give hand-customized products to users (think a "one per user" etsy store with one person knitting cat dolls or something): multiple similar contacts from the same user would mean you spend a lot of time making their products--time which might be wasted, even if they paid for their products, compared with time spent making them for lots of different users and increasing your recognition/exposure. - The same applies to tech-support contact-us forms: one user can "bogart" your support staff, clogging the queue with (legitimate or not) requests and defeat your rate limiters by using the "+" trick, making other users wait a long time for replies. - Others I haven't thought of.
- nodesocket 9y agoCompletely agree. If somebody wants to signup for your service as ceo@company.com and ceo+sales@company.com let them. Two distinct user accounts.
- nzjrs 9y agoDear sir. I enjoyed your free trial. May I have+1 another?
- hungerstrike 9y agoDear user. Sure. Enjoy losing all of your preferences and data every 14 days.
- Hextinium 9y agoIf you wanted to continuously have free trials it is trivially easy to just create entirely new email adresses
- zbentley 9y agoI replied to this same idea above: https://news.ycombinator.com/item?id=16358625 https://news.ycombinator.com/item?id=16358625
- protopeer 9y agoyeah, i paid less than a dollar for a super cheap domain, and created a catch-all email forwarder that lets me create any random email forwarding address that all forwards to my one email. i've used this method in the past to get unlimited free things at certain establishments that offer welcome gifts to new rewards accounts.
- tbabb 9y agoMy thought would be to have two distinct fields: "normalized" and "pristine" version of the user's email. Then always mail to exactly what the user typed ("pristine"), and use the "normalized" mail to prevent multiple registrations to "john.doe@gmail" and "johndoe@gmail" and "johndoe+1@gmail" and "JOHNDOE@gmail.com" and so on. Denying registration to a suspected-duplicate seems a lot safer than mailing to a different person.
- __david__ 9y agoIf you're going to do that then only do it for email addresses where you understand the local MTA conventions (like gmail). Do not do it for domains you don't know (because you cannot predict how they work). For instance, on my email domain, david+abc@example.com, david.def@example.com, and david_ghi@example.com are all the same ('+', '.' and '_' all act like you'd expect '+' to), but david+xyz@example.com is not (it get's picked off and aliased somewhere else). Applying gmail conventions to other domains is silly and wrong.
- pawelk 9y agoYou can still do a check for the normalized address for known sevices that allow moving the dots and adding a +somthing (e.g. to catch someone creating multiple fake accounts). Just be decent about it and store the user-provided address for communication purposes.
- sarreph 9y agoIt does surprise me how many big SAAS products with generous free trials don't check for '+'s on Gmail addresses...