Live data from Hacker News

Lies we tell ourselves about email addresses

gitpush--force.com

41–50 of 197 posts

Re: Lies we tell ourselves about email addresses

#41

> 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-i…

That's why the article says "verify, not validate". Send an email, have a process for them to confirm they received it.

If the user gets the email and completes the validation, the email is valid. If they fucked up, they don't get the email and the account never gets created.

No one ever gets prevented from creating an account with a legitimate email address, as opposed to "opinionated validation" where that absolutely will happen. Speaking from years of experience having a .info domain which isn't even all that odd, and at one point using gmail-style + addresses regularly. "Opinionated validation" has forced me to use my .com domain without a plus dozens of times.

I know part of this is intentional, those who know they plan to sell your email addresses don't want you to use the plus addresses, but that doesn't make the advice to not filter addresses any less correct.

Re: Lies we tell ourselves about email addresses

#42
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.

Re: Lies we tell ourselves about email addresses

#43
post #42

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.

I get scammers using my email to sign up for websites, but they very obviously cannot login to my account. I often wonder what is in it for them. I'm sure someone on HN can tell me!

Re: Lies we tell ourselves about email addresses

#44
post #3

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 passwor…

Claude, for my non Gmail domain, expects me to click a magic link on every device I wish to use it. Its wild that a product like that cannot take a password, or a passkey.

Re: Lies we tell ourselves about email addresses

#47
post #9
post #7

Earlier quoted context omitted.

> 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.

The people in charge of the internet are "cybersecurity" "professionals" who can't even follow NIST guidance.

A lot of those same people seemed perfectly capable of insisting on 60 day password rotation back when they could use nist guidance as an authority to appeal to (for about five years after the recommendation changed too).

Re: Lies we tell ourselves about email addresses

#50
post #8

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 ca…

> "[IPv6:2001:etc:etc::192.etc.etc]" I'm trusting this is a throwaway example and that you used a real IPv6 address literal in this test, without the "IPv6" and with only colons and no dots (unless you mean to use v4 mapped address with dots)? Because this IPv6 literal is so malformed that I'm hardly expecting it to do something sane and changing that to "@2001" is nasal-demons quality undefined behavior. I tried wit…

All address literals other than IPv4 must be prefixed by a tag, such as "IPv6:". The form that I gave is a syntactically valid v6v4 address literal.

https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.3

Post reply on HN