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"
If you try to create a Discord account with Firefox Klar as your default browser, on Android, immediately upon signing up you'll be banned. I have to assume this is because it clears cookies and thinks you're a bot farm.
> 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
God, I fucking hate that.
I have a fucking password manager, I have various machines and things open. Just let me fucking log in.
If anyone is reading this who is in charge of the internet please stop doing this.
So agreed. It’s fucking crazy. Password manager is so much easier and more secure. If you do this dumb email or SMS OTP flow, at LEAST support passkeys for my password manager!
It’s wild that they’re like “it’s more secure to not have a password” and then choose two unencrypted delivery mechanisms for the very short OTP.
Sure, people who reuse passwords are not secure. And fair, I guess it’s a tragedy of the commons. But at least continue supporting it and make it dead simple for password managers if you actually care bout security
I seem to spend half my life logging into thing's, confirming 2fa,confirming biometric data. Then when I go back to the first thing it's timed out and I have to sign in again.
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.
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!
> 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.
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.
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.
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!
Could they have consciously chosen to remove that functionality?
E.g. to simplify code, or if they wanted all mails to have a domain (if, for example, they wanted to integrate with reputation systems that were domain oriented)?
Based on the incredibly basic bounce message, I suspect the problem is that the frontend eats the address before it even gets to delivery.
To your question, yes any product decision is possible, but enterprise/government people are surprisingly demanding about this stuff working because they have extremely weird requirements for routing mail to and through legacy systems. So I bet this still works at the mailer level and is broken in the UI.
I chuck IP address literals (both IPv4 and IPv6) on the list of things that you should care about for email if you're writing an MTA or an MUA but should otherwise generally not care about supporting if you're using email for something else (e.g., as a UID for login).
> 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.
I think the only way to deal with that right now is to hire a company whose job is to deal with it. They'll random-check your outgoing emails are indeed what you say they are, and they maintain a reputation with the big providers for checking it properly.
What pre-validation could you do that would possibly be useful?
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"
Most other providers I've used range from instant to a few minutes.
God, I fucking hate that.
I have a fucking password manager, I have various machines and things open. Just let me fucking log in.
If anyone is reading this who is in charge of the internet please stop doing this.
It’s wild that they’re like “it’s more secure to not have a password” and then choose two unencrypted delivery mechanisms for the very short OTP.
Sure, people who reuse passwords are not secure. And fair, I guess it’s a tragedy of the commons. But at least continue supporting it and make it dead simple for password managers if you actually care bout security
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!
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.
> 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.
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...
E.g. to simplify code, or if they wanted all mails to have a domain (if, for example, they wanted to integrate with reputation systems that were domain oriented)?
To your question, yes any product decision is possible, but enterprise/government people are surprisingly demanding about this stuff working because they have extremely weird requirements for routing mail to and through legacy systems. So I bet this still works at the mailer level and is broken in the UI.
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.
What pre-validation could you do that would possibly be useful?