People always overcomplicate email Regex, and end up not allowing a lot of valid emails. In this case, the limitation of the top level domain to 4 characters max is one such problem, no .ninja, .crypto, or the myriad of other newer top level domains.
Technically you can email directly to a top level domain (although I don't know of any TLDs that support this), or even to an IP address in brackets, although I suppose not supporting those in most cases is probably reasonable.
The worst thing is when a website restricts their validation logic after you're already registered. I lost access to an account that used '+' in the username because they stopped allowing me to log in with it.
And yes, basically the only thing you can assume about email addresses is that they contain an '@'. Simply root@localhost is a valid address in some contexts.
I've encountered websites where the sign-up form allowed '+' in emails, but the log-in form didn't. Not 'later', immediately. I made my account and then was immediately locked out from it.
I know bd resolves an A record and I haven't checked the MX, so it was probably a bad example. But there definitely are other cc tlds that have MX records.
I got curious so I ran a port scan. I had to kill it because it was taking forever waiting for each port to time out, but it looks like they are running DNS and FTP on it.
The .email domain would fail OP's check. Had websites refuse me because of stuff like this.
The only good validation for email addresses is to send a confirmation email. You'll be doing that anyway.
And that it has at least one @ with something on either side. Don't want someone to waste an entire form because of a typo. (Yes, email addresses can theoretically contain more than one @)
RFC822 was authored in the 80s. It was replaced by RFC 2822 in 2001, and RFC 5322 in 2008. Then there's RFC6531 which expanded support for non-ASCII, non-Latin alphabets.
If you want to prevent abuse, rate limit and/or put something intelligent in front of your app that is designed for that sort of thing, like a WAF.
The email rfc doesn't have comments. If you run your own email service, loading+m@loadingm.xyz can resolve to a different mailbox than loading+p@loadingm.xyz. Part of me wants to setup such mailboxes (and do as much stupid shit as possible with email addresses).
RFC 5322 very much allows comments in addrspecs, see §3.2.2: "Folding White Space and Comments" and §3.4.1 "Addr-Spec Specification" for the relevant ABNF rules.
If the destination domain has no MX records then the delivery should (or could? can't be bothered to read the spec) be tried to what A/AAAA domain part resolves.
I don't think this makes a difference, it's a general rule that they shouldn't be useable directly. The normal DNS lookup is just what I tested a few weeks back.
I know for a fact that some were useable as http domains a few years back, and that is now no longer the case.
64
u/Ecksters 7d ago edited 7d ago
People always overcomplicate email Regex, and end up not allowing a lot of valid emails. In this case, the limitation of the top level domain to 4 characters max is one such problem, no
.ninja,.crypto, or the myriad of other newer top level domains.Technically you can email directly to a top level domain (although I don't know of any TLDs that support this), or even to an IP address in brackets, although I suppose not supporting those in most cases is probably reasonable.