Hacker News Reader

Comment by chunk_waffle | Hacker News Reader

I shipped an international package with USPS today and there was an option to add an email. I used my email address with a .family TLD.

They couldn't add the email, they said the system was telling them it was an invalid email. Inaccurate email validation in the wild... I suspect the system has a list of known TLDs and that didn't exist when their system was created. Or even worse, they have some hardcoded list of known email providers...

View on HN

I own a .co domain. Frequently when entering my email address the validator tries to correct me - “Did you mean .com?”. No, I meant the thing I entered.

The real problem is when I give my email address to someone else and then they get corrected by their email client. For some reason, people place implicit trust in these validators. This results in emails getting sent to the wrong TLD.

.co was released in 1991, and it’s easier than ever to launch a TLD. Email validators need to stop validating TLDs. It doesn’t help anyone.

When I was in charge to implement the email validation at my previous employer, the only thing I did was checking for "." and "@" in the correct order.

The sales-focused part of the company complained that they would still receive invalid email-addresses for their newsletter.

Turns out what they really wanted was an email address where they could send stuff to. So we implemented a MX-check for the host part of the email address. However, that check was mostly a warning, in the sense of "Hey, are you sure the email you entered is correct?".

The discover bank doesn't even accept an email at indian tld like hello@example.in The reason given by support was that .in email will work only in India & discover operates only in USA. I tried to reason that people move from India to USA all the time & keep the same email accounts.

Also, if some system accepts such a domain it sill likely it gives it a red flag.

I'm using .email domain for a long time, in many cases it's not accepted on registration. When it's accepted and it's an e-commerce website then half the time I get an automated email that the sale was either declined, or they require additional proofs. Or, in some cases, the order just gets ignored, and when you physically call them they can't even find the email in their system, so my guess some anti-spam system just blocks it.

Or a regex with a \.[a-z]{2,3} suffix. I’ve had similar problems with my email at a newer TLD.

This wouldn’t even let in .info…

Yes... You didn't make a point, so I'm guessing it's just an observation.

Or, seriously, not supporting .info won't stop a lot of people from adopting and keeping a system, not a lot of developers from doing things this way.

You'd be surprised. Especially if you are building B2B and users want to use their company emails. Blocking any non-standard TLDs will create a customer service pain for any reasonably large business.

I’ve been exclusively using email address(es) at my .info domain for over twelve years now. To my recollection, I’ve had issues due to the domain name exactly once, about two years ago; in that case it was a website with a bad email validation regex, and, being a web developer, I was able to bypass it, and the backend accepted it.

Now I do recall noticing things that would baulk at five-character TLDs once or twice more. (Actually-deployed stuff, this is—if I counted example email address validation regular expressions I’ve seen from Stack Overflow and similar and “see how good/bad/otherwise this LLM is”, it’d be quite a few more.)

Judging by the amount of problems I had with an email address on a subdomain (@students.univerity.tld), it seem about 5% of all registration forms use a regex similar to .*@[a-z0-9]\.[a-z]{2,4}

I wonder what the success-rate with unicode domains looks like

This would lock out countries that use .co.uk and similar

> it seem about 5% of all registration forms use a regex similar to .*@[a-z0-9]\.[a-z]{2,4}

That matches @0.ab, but not mail@example.com.

I think you mean: .+@[a-z0-9]+\.[a-z]{2,4}

Newer? My .at (est. 1988) email address is still occasionally rejected for its "invalid" TLD.

Kind of surprising that a country (Austria) tld would not be accepted.

> Or even worse, they have some hardcoded list of known email providers...

I still remember humblebundle rejecting my mailbox.org email as invalid, I'm guessing because of that. They fixed it at some point, fortunately.

Judging by the amount of infosec dorks I’ve seen kvetching on twitter over .zip, it’s probably blocking less popular TLDs.

Emails can theoretically be sent to TLDs, right?

Yes

Reply on news.ycombinator.com