Hacker News Reader

Comment by SeanLuke | Hacker News Reader

These are waaay too complicated. Web developers can't even handle the easy stuff. My email address is of the form sean@foo.bar.baz, and email address validators on websites reject my address about 30% of the time because it has two periods.

View on HN

Discover bank, refuses to accept name@sub.example.in, but happily accepted name@example.us

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.

I've had sites correct me with an email address ending in ".fi" with "are you sure you don't mean ".fr"?

Not unreasonable if those sites are mostly serving a French audience.

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.

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

Realistically, people would need to go out of their way to have an e-mail with the domain part longer than a hundred ASCII characters (although considering Punycode, this limit perhaps should be more like 200, for CJK domains...) so if they do, well, it's their problem.

I just don't like the idea of allowing to paste 20 MiB-long text into the input field for what normally is a "short line of text", so there should be some upper limit.

Yes there should, and the maximum size of what fits into a 512-octet DNS/UDP query packet, less header and EDNS0 and whatnot, is going to be that limit, ultimately. Because SMTP-based Internet MTSes that do not look up MX resource record sets in the DNS, and do not begin at DNS/UDP, do not currently exist. (-:

Even if they magically all switched to starting at DNS/TCP, that is still only 64KiB less header and EDNS0 and whatnot. And in that case one also has to allow space for sending the actual resource record set back in the response, DNS/TCP not having DNS/UDP's luxury of truncation, so it's not even as large as that.

I've actually looked at RFC 1034 § 3 you've mentioned in another comment, and it states

    To simplify implementations, the total number of octets that represent a
    domain name (i.e., the sum of all label octets and label lengths) is
    limited to 255.

Which, AIUI, corresponds to maximum of 253 ASCII characters (including dots) in the common "subdomain.domain.tld" string format. So "\.{1,100}@\.{1,253}" it is (because, again, it's probably very likely that I wouldn't want to interact in the first place with people who think that the local part of their e-mail having more than a hundred characters is reasonable).

<input type=email> exists for a reason.

You shouldn't be going through extra effort to get things wrong. Just use the thing that you're supposed to use.

Reply on news.ycombinator.com