Hacker News Reader

Comment by OJFord | Hacker News Reader

    > Unique-per-service email addresses work pretty well

and they're so easy with Gmail - anything following a '+' character after your username (or alias, if using your own/company domain) will go to the same box, but keep the distinct address.

Unfortunately, depressingly many sites validate email fields, and get it wrong - thinking '+' is not allowed.

IMO it's not even worth trying to get an email regex (or other validation) right - you're probably going to send out an activation email anyway!

View on HN

Except it's really obvious, and spammers can just remove the "+asd" section.

Other services also let you use the alias as a subdomain: example@alias.gmail.com. Wish Gmail added that feature. Do they have any place I can sent a feature request?

Another feature of Gmail is you can place dots anywhere in your email and it will still reach you: ex.am.ple@gmail.com. I haven't seen services that reject that so it is what I use when I can't use a +.

I host my email with FastMail who allow the use of subdomains. This is a great feature, and I use it frequently.

HOWEVER, you should only do so after careful consideration. This will restrict moving your email hosting to the limited number of providers who provide provide this type of service, or hosting your own server.

Alternatively, you could go and reset your email address with all of the services that you gave a subdomain email.

For myself, I have been using FastMail for years and feel confident that I will continue to use their services. In the event that I needed to move from FastMail, I know that could self host if forced to.

I'm pretty sure they do know a `+` is allowed...

I've had sites reject an email containing +.

The trouble is that no one actually implements the email standard from the IETF RFC documents. In fact, some people[0] even actively discourage doing so, despite there being little in the way of good reason to not. The argument essentially goes "well, users aren't going to be likely to use those characters, unless they're doing something bad, and they make it difficult to insert the email into the database." I feel like that's a kind of laziness - we can fairly effectively remove that risk, and there are well tested tools to do so. But I do suspect that forbidding '+' is explicitly to avoid people using tagged emails. To be honest, the inconsistency in services allowing me to use '+' has caused me to just create a separate email for services that I don't have high trust for. Now no one gets my personal email, and I only check that one if I'm expecting something important.

[0] http://girders.org/blog/2013/01/31/dont-rfc-validate-email-a...

I mean, there are good reasons laid out in that document. "By RFC, email addresses are unique by mixed-case. Most (99.9+%) email systems do not treat email addresses as such."

Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.

You -should- treat email the way that vast majority of hosted services do. "Foo Bar"@gmail.com is not allowed. Covering the million edge cases seems to not be worth the trouble, especially when it might cause difficulty for the average user

> Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.

With smartphone keyboards and the capitalization of the first letter of the first word in form input fields by default, this is a very common occurrence. If case was considered for uniqueness of email addresses, at best, people would be extremely annoyed. At worst, there would be a tremendous amount of leakage of sensitive information to random people (due to human errors in entering case sensitive addresses), chaos due to incorrectly delivered emails and fatigue in receiving mails intended for thousands of other people. In an alternate universe where this is true, email would never have been a killer application, only a quickly killed and abandoned one. :)

Email RFC is weird. Did you know email addresses are supposed to be case sensitive? Like bob@ and Bob@ are two different addresses? Some services treat them this way, most don't. That intersection (oauth2 for example from Google can return Bob.Smith@domain.com if Bob has a GA4W account, which causes trouble when the oauth handler inconsistently lower-casifies input.

Really? By my reading RFC-5321 & RFC-5322 leaves interpretation of the local-part up to the software running on the host where the mail is delivered, but since that interpretation is up to those servers, intermediate servers must treat them as case sensitive and not make modifications to the local-part.

That's my interpretation, as well. The standard is for carriers, not mailboxes. As a carrier, (or someone sending an email) you should respect case, as well as respect all of the special characters, because the server is allowed full decision power over whether those things are meaningfully used.

So? What's your point?

I've encountered a number of sites that don't permit + in emails. I've also encountered a bunch that don't permit my hyphenated last name.

Reply on news.ycombinator.com