Hacker News Reader

Hacker News

Comment by nickjj | Hacker News Reader

Full thread

nickjj

The first line mentions:

> Validates email looks like an email i.e. contains an "@" and a "." to the right of it.

But what about emails coming from a hostname without a dot, or a TLD without a subdomain?

Even the HTML email field supports emails without a dot after the @ because it's technically valid.

View on HN

You could do it for a TLD without a subdomain. The TLD "tt" does in fact have MX records. But it's a very rare case that a TLD does, and prohibited for any of the new TLDs.

For non-FQDN hostnames, it's kinda pointless, as you can only use that on your own domain. So if you were to do that, just make up your own pseudo-TLD like ".x" with an alternate DNS system. You could even have it point to the regular DNS system through CNAMEs.

Wow, indeed: https://www.nslookup.io/dns-records/tt

I understand it's technically correct but this is a solution no one wants. I recently spent time fixing this in application.

Sendmail also still supports uucp bangpaths as an email address: https://www.sendmail.org/~ca/email/doc8.12/cf/m4/uucp_mailer...

Yeah, looks like they're doing super-naive address validation:

https://github.com/mfbx9da4/deep-email-validator/blob/master...

OTOH, that code looks as if it'll find the vast majority of the problems more careful analysis could find, both simply and without bad consequences.

All that happens if that naïve code fails is that it does an MX lookup that's bound to fail, and then the code returns a bad error message ("couldn't find MX" instead of more properly "syntax error in domain part").

If an MX record isn't present you can fall back on the A-record.

(If, and only if, no MX record for the domain is present, treat the domain as if it had an MX record with the given domain as the target hostname and a preference value of 0)

If you want to be pedantic... not in the relevant case, no. In the relevant case (the domain is syntactically invalid but the naïve check didn't discover that) the response without MX RRs already tells you that there won't be an A (or AAAA).

foo@2001::01 is a valid email address, no? So is using the alternative dotless representation of the IPv4 addresses.

Per the RFC 5322 addr-spec grammar production, it’s actulaly not: colons aren’t permitted in regular domain name syntax; you need to use the domain literal form: foo@[2001::01]. Same deal with HTTP URLs, IPv6 localhost port 8080 is http://[::1]:8080/.

foo@[IPv6:2001::01], since it's an IPv6 address. Without the IPv6 prefix, it must be an IPv4 address.

Ah hah, https://tools.ietf.org/html/rfc5321#section-4.1.3 defines this. I had tried briefly to find something, but not very hard, and so incorrectly guessed it was like HTTP URLs. Thanks for the correction, this is good to know. With that, I also note that exotic IPv4 address formats (such as the 32-bit integer representation) are excluded in that grammar.

At least they aren't invalidating email addresses with the plus sign like some registration forms I encountered out there..

Reply on news.ycombinator.com