alt Hacker NewsLies we tell ourselves about email addresses
Comments
"Email addresses always have a 'normal' TLD"
I registered a ".consulting" domain for my little company when they became available, and it has proved highly problematic ever since. Strangely (or perhaps not) it seems to be the larger players that have the most problems. I would at lest have expected ISPs and comms companies to keep up with this (looking at you, Three)
Email is just like physical mail and thankfully just as endearingly human (sometimes).
Once upon a time (1970/80s) I lived on and off in a mystic land called West Germany. Our postal addresses ended with incantations such as BFPO 40.
Around 1985ish my granny send a Christmas card to us. I should note that she was at this time nearly seventy and sadly suffering from Parkinsons. She addressed the card, in rather crabbed but legible handwriting, to:
Graham and Heath BFPO 40
My mum's name is abbreviated - her daughter. At that time Rheindahlen (nr Moenchengladbach) had a pretty large contingent of Brits in it - it was HQ (BAOR).
The card arrived well before Chrimbo and it took about a week judging by the post mark, which was petty normal in those days. She shoved it into a post box in Ipplepen, nr Newton Abbot, Devon and it found its way to an obscure address in another country. I seem to recall she also forgot the stamp but it still got through.
I'm sure mail like that becomes a point of honour to deliver and HM PO and BFPO did the job admirably.
That attitude is how email MTAs are generally designed to work. They cling on to the good old days and sadly the world is a bit shit. Case sensitivity ... lol!
https://fightingforalostcause.net/content/misc/2006/compare-...
This is one of my favorite articles on validating emails using RegEx, I fondly remember reading it over 15 years ago. It's stuck with me ever since.
You really did -- in your domain name, didn't you?
> It’s likely that more people out there are being filtered by badly-implemented form validation than there are being filtered by their own need of hand-holding.
I wish this was asserted with evidence. The author might suggest this because they have unrealistic views of some users.
> In the year of our lord 2026, you can reasonably expect your users to know how to type their own email address - or even better, auto-input from their OS, browser, keyboard app, or password manager.
This really depends on who your users are.
I have multiple family members who have healthy memory, but can't accurately remember their email address everytime: the localpart, the domain, the syntax, everything.
Sending an email verification isn't sufficient, because if the user has typo'd ".com", they might never receive that email, and the user might never be back, or then have to escalate to support.
Meanwhile, if a site is opinionated on TLDs, they might prevent those users facing issues.
I'm sure there are many sites were users have a large variety of odd email addresses, but also there are sites that cater to mostly non-technical users within 1-2 locales, and so may find the friendliest UX is having opinionated validation.
I have a gmail address that at least three other people think is their address. I constantly get emails for the dumb stuff they sign up for. NONE of them ever have an "I didn't request this" link. I mean, I get it. That won't make them money, but oh man is it annoying.
These are waaay too complicated. Web developers can't even handle the easy stuff. My email address is of the form [email protected], and email address validators on websites reject my address about 30% of the time because it has two periods.
Another one is that you can tell “professional” from “personal” email addresses or that every address even cleanly fits into just one category.
A lot of small business owners use gmail or a longstanding ISP account. A lot of people have personal email addresses you can’t easily distinguish from professional ones, between college alumni addresses, personal domains, and obscure ISP and email providers that aren’t in your database.
Add the lie "emails are delivered instantly, so the user can click a link I email them within 1 minute"
And the lie "users always read emails on the same device they're logging into a website with"
And the lie "users can always view HTML email so no need to send a plaintext equivalent, especially if I have a long complex URL I want them to click"
And the lie "Clickable links sent in email are more secure than passwords so I'll stop supporting passwords and instead rely on email delivery of a link for all logins. Whoever clicks that link first is definitely the user who wanted to log in"
I would like to point out that the "suggested" validation pattern, ^[^@]+@[^@\s]+$, can filter out valid addresses. "user@something"@example.com is a valid address, and excluding @'s in the user part rejects it.
I enjoyed the deep dice. A lot of sensible advice, and enjoyed the deep dive. A lot of articles do not get a lot of that as right as this article does.
Anyone who also enjoyed it would probably get a kick out of my article on the same subject that goes into the regex (which has some valid use cases): https://hackernoon.com/on-the-practicality-of-regex-for-emai...
IIIRC in terms of clients mutt (&co) will actually handle “@“ in the local part correctly.
> But the real reason I do that is just because I just like to sit in anger whenever this breaks the user experience because of programming errors or inconsistencies.
Genuinely delighted by the fact that I’m not alone in that.
And even if you know that an email address is perfectly valid it still could be simply wrong because of a tpyo.
One thing I have learned about verification is:
Don't just put a link into your mail that directly verifies an email when visited. At least put some button or code input field there.
Why? There are mail clients that will automatically open links for users and if that link is now invalid the user is confused about being able to click them.
I think most of these issues are easy to resolve by being more permissive and supporting what the technical standard allows for.
The Big Problem™ however is case sensitivity in the local-part, because there multiple incompatible things collide:
1. Users are not universally aware of case (in)sensitivity in one direction or the other
2. Existing systems may or may not interpret case at all
My preferred solution would be to adjust the standard to ignore case in the local part by forcing it to lowercase. That aligns with most of the systems and mental model of technically proficient users anyways. It makes much more sense from an UX standpoint since the goal is to be imambiguous.
If we were to enforce the opposite: case sensitivity in the local part this would have multiple downsides:
1. It is inconsistent with itself by making the local part case sensitive but the host part not, that is harder to explain
2. You have to train users to be precise about case on entry. As someone who worked in IT-support, this is a very bad idea. This includes second-order issues like phishing attacks by silbling emails where just the case differs
3. If your service stores email addresses it will need to know whether that specific Mailserver/client/etc treats the email as case-sensitive or not
In my eyes email servers that allow case sensitive local-parts are functionally broken, even if they don't break any rules.
Soooo, let's just send a validation email and if they confirm the code, then it's a valid email?
Functionally there's no false positives or false negatives
The plus sign is a pet peeve of mine, too. But I stopped keeping a list of bad sites when their number has become double digit!
> It turns out that allowing senders to omit dots is common but by no means universal!
I think this is mostly common with Gmail-heavy countries and does not apply to Europe? At least I do not know of anyone that thinks so.
[Old man voice] Back in my day these kinds of articles loved pointing out that, well, the email address could be a UUCP address and that's a whole different parsing situation.
Of course, even then in the mid 90ies, UUCP was not something one really encountered outside of "so you think you're going to parse an email address with regexp?!" articles.
This article says that Gmail can't handle address literals. I personally wrote the IPv6 address literal support for Gmail, so this annoys me. I just tested it and it shortened "[IPv6:2001:etc:etc::192.etc.etc]" down to "@2001" then generated an extremely terse mail delivery subsystem notification that I've never seen before. Which is why you should never just rewrite software without understanding why all the test cases are in the test suite!
> TL;DR: Don't overthink it, just send a verification email.
pretty bad advice, if taken only as written, without adding more flavor on top.
the major email providers will penalize you if you generate too many undeliverable emails. thus, if you just send a verification email without any pre-validation, it's pretty easy to get into a DoS situation where current/valid users don't get important email sent to them, or that email is significantly delayed, plus incur huge operating cost to resolve the problem.
some form of rate limiting is needed, plus IMHO it's better to use a verifier service or your own heuristic or ML model to test for email validity including valid but fake/spammy/disposable addresses.
sorry, but we are way past the point of being able to have nice things, esp. when we're talking about email.
the "lies" part of the content is great. people do assume all those wrong things. however the TLDR is just wrong, and potentially harmful.
This is cute and all. But for anyone coming here for real-world advice: just use a regex, normalize to lowercase, and surface any errors to users so they know if their email got rejected. This will avoid 99.9% of issues and work for 100% of real human users. This is what everyone else does, and if you have a user with an esoteric email, they will still be able to furnish another one that passes this validation.
We have a UK client in the healthcare industry who registered the domain clientname.healthcare, and they rapidly found that the NHS imposed regexes which rejected [email protected] emails.
Aside from regexes though, I also think the new TLDs confuse quite a lot of people. [email protected] just doesn't click as an email address as quickly as [email protected], and I'm in tech so I'm sure it's much more confusing for people outside that space.
In fact, that reminds me that we built a site for another client for use inside an exhibition space which was spacename.house and against our advice they put that - without www or https:// - on exhibition panels for use on mobile phones. I am absolutely convinced that most people didn't realise it was a web address.