Live data from Hacker News

Lies we tell ourselves about email addresses

gitpush--force.com

91–100 of 197 posts

Re: Lies we tell ourselves about email addresses

#91

"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)

The annoying bit is that owning a domain should make email feel more stable and professional

Re: Lies we tell ourselves about email addresses

#92
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 have the same with my email address. There seriously exist people out there who think that if they start to give away everywhere an email address, this email address will become theirs. Then there are many service providers and institutions who don't verify an email but simply start sending stuff to it.

Re: Lies we tell ourselves about email addresses

#93
post #38

Earlier quoted context omitted.

There's a landlord/apartment portal where the whole login process has changed to be: 1. Enter username (e.g. an email) 2. Choose from either email or SMS on file 3. Enter the code you got somehow through the respective unencrypted channel Given that this same site is involved with bank-account details for payment, I am concerned...

It’s really rich when banking/finance apps are fully happy doing 2FA to the phone when using its own browser… Yeah — loose the phone and it’s pretty much game over.

I don't think it should be the sites' responsibility to guess whether the browser session is the have device will receive an SMS message... The fact that it is SMS is already bad anyway.

Time-code apps or passkeys are a different story.

1. You should be able to make backups.

2. There's nothing to intercept in plaintext.

3. The all can (unlike SMS features) be locked down by default and require a second layer of unlocking, so that they usually aren't accessible to someone who grabs your phone out of your hand.

Re: Lies we tell ourselves about email addresses

#94
post #14

Earlier quoted context omitted.

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…

> 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

Interesting context, thanks.

Re: Lies we tell ourselves about email addresses

#95
> In that sense, it’s actually pretty surprising that so much of the world’s population wasn’t able to put their own name, in its native written form, in an email address until just 14 years ago.

Maybe for some internal usages. but imagine someone from a country using different language and characters gives me a card with their email. It's now far less portable for me to use it. Those days, I surely could picture it and find the email most likely getting it right.

But email as means of international communication, like passport, should be readable as possible or it kills its purpose.

Even with ASCII emails I have, I already sometimes struggle to pass them over phone or other methods :)

Re: Lies we tell ourselves about email addresses

#97
> It is relatively expensive to run

Compared to sending a mail or to a customer not getting a mail they wanted?

> Try to keep it as non-restrictive as possible. Something like ^[^@]+@[^@\s]+$, which only makes sure your user has input “something@something”

Requiring a dot in the domain part is perfectly valid. It makes no sense to not validate that the address is in a format that you can actually send something to, which include a domain that you can look up and isn't specifically rejected by your MTA.

> This belief will probably be more commonly held in the English-speaking world, but I’m curious: If you’re not in the Anglosphere, do you still expect emails to require ASCII latin characters?

Yes, I do not trust Unicode with all its ambiguities and alternate forms to resolve to the same identifier on your and that I intended. ASCII-only email addresses are the norm everywhere I have seen.

Re: Lies we tell ourselves about email addresses

#98

Earlier quoted context omitted.

\.{1,100}@\.{1,100} I'd probably also have a red warning line under the input field for something really fishy and also most common typos (like "gmail.con") but other than that, I'd let it through.

Just had to update this this week - a previous dev had used 2,4 and someone came through complaining with a six character domain suffix. Apparently 24 or so is the current limit for a real domain suffix.

Even that's not the true length limit of a label in the Domain Name System. (RFC 1034 § 3, for the curious.) So someone is likely going to be fixing that, years down the line. Then of course there's the fact, as called out earlier, that there can be more than 2 labels in a domain name.

Re: Lies we tell ourselves about email addresses

#99

> In that sense, it’s actually pretty surprising that so much of the world’s population wasn’t able to put their own name, in its native written form, in an email address until just 14 years ago. Maybe for some internal usages. but imagine someone from a country using different language and characters gives me a card with their email. It's now far less portable for me to use it. Those days, I surely could picture it…

Agreed, (a subset of) ASCII as the lingua franca of identifies is very useful. Almost all languages managed pretty well with ASCII-encodings of their special characters even if some individuals choose to be offended.

Re: Lies we tell ourselves about email addresses

#100

Earlier quoted context omitted.

Honestly, I just validate that it has an @ and then let it through. The actual sender (mailgun, or whatever) can do the dirty work for me.

\.{1,100}@\.{1,100} I'd probably also have a red warning line under the input field for something really fishy and also most common typos (like "gmail.con") but other than that, I'd let it through.

Realistically, the length of the domain part is likely ultimately constrained by how large a domain name can fit into a DNS/UDP query packet (alongside EDNS0).
Post reply on HN