I found your comment fairly cryptic. I had a fun twenty minutes trying to work out what you meant, and under what circumstances dotless RHS in email addresses might be legal.
I suppose from the RFC, sure the spec doesn't require dots.
For example, I can use http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate and verify that sure, '1@2!3!4' is a valid RFC822 email address. But I think e.g. UUCP-style addreses are a pathological case, and we don't _really_ want users signing up with them.
Another option would be intranets, e.g. 'baker@internal', but again I think that's being a bit pedantic, since most people on HN are writing webapps for the public Internet, not mail clients.
So can we get an email with foo@<some-dotless-string> routed across the public Internet? Even a bounce would do :)
You might be able to do a riff on xyzzy123@[23.55.211.36] (e.g xyzzy123@[389534500] or xyzzy123@[1737D324]. However, do you _really_ want your users to specify these?
There are mx records for existing TLDs (e.g. com, org, au, mx) - but all the mx records I tried refused connections on port 25. So no mail for 'xyzzy123@com' :(
So gTLDs are another option, and there was a time when it looked like xyzzy123@xyzzycorp might route (as long as it didn't collide with anything on the local resolver's search list). But it seems that dotless use of gTLDs is seriously deprecated at this point, and that ICANN will treat it as a TOS violation: http://domainincite.com/10254-why-domain-names-need-punctuat...
Basically, ICANN's conclusion was that dotless TLDs are a terrible idea for many technical reasons.
I looked into IDNs too, but of course due to the way DNS works, you can't really get around the dots.
So the conclusion of all this is that:
1) Using an RFC822 regex is a terrible way to check emails. The things it thinks are valid are MUCH wider than what you actually want.
2) You should probably check the RHS against a public suffix list if you are e.g. accepting a user email address on a signup page. If you accept dotless TLDs or other constructions (e.g. ips on RHS) there is some (low, but nonzero) risk that a malicious user could cause your systems to route mail to your other systems internally.
I suppose from the RFC, sure the spec doesn't require dots.
For example, I can use http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate and verify that sure, '1@2!3!4' is a valid RFC822 email address. But I think e.g. UUCP-style addreses are a pathological case, and we don't _really_ want users signing up with them.
Another option would be intranets, e.g. 'baker@internal', but again I think that's being a bit pedantic, since most people on HN are writing webapps for the public Internet, not mail clients.
So can we get an email with foo@<some-dotless-string> routed across the public Internet? Even a bounce would do :)
You might be able to do a riff on xyzzy123@[23.55.211.36] (e.g xyzzy123@[389534500] or xyzzy123@[1737D324]. However, do you _really_ want your users to specify these?
There are mx records for existing TLDs (e.g. com, org, au, mx) - but all the mx records I tried refused connections on port 25. So no mail for 'xyzzy123@com' :(
So gTLDs are another option, and there was a time when it looked like xyzzy123@xyzzycorp might route (as long as it didn't collide with anything on the local resolver's search list). But it seems that dotless use of gTLDs is seriously deprecated at this point, and that ICANN will treat it as a TOS violation: http://domainincite.com/10254-why-domain-names-need-punctuat...
Basically, ICANN's conclusion was that dotless TLDs are a terrible idea for many technical reasons.
I looked into IDNs too, but of course due to the way DNS works, you can't really get around the dots.
So the conclusion of all this is that:
1) Using an RFC822 regex is a terrible way to check emails. The things it thinks are valid are MUCH wider than what you actually want.
2) You should probably check the RHS against a public suffix list if you are e.g. accepting a user email address on a signup page. If you accept dotless TLDs or other constructions (e.g. ips on RHS) there is some (low, but nonzero) risk that a malicious user could cause your systems to route mail to your other systems internally.