I don't know if it is still required but hostnames used to require a minimum of two chars and the first shalt not be an integer. Given that DNS does not put a proper boundary on host/domain, that might extend to your top level ... thingie.

However, there is absolutely no technical reason that I can think of that precludes u@x. In the end DNS query -> DNS answer. Given that say, PowerDNS has LUA built in, I can make it respond with "my little pony's stable is in {random_country}" - to A record requests, which might make the requester a little queasy!

Bugger standards, they are so 1990s!

the first shalt not be an integer

I recently came across the 3.ie domain so I guess that's more of a guideline than rule.

I believe that the rule has been deprecated due to better parsing.

In the mid-90s, 3M was a customer of the ISP I worked for. Unable to procure the domain name “3m.com” they settled for the alternate “mmm.com”: mildly hilarious considering their lines of business.

Funny to see mmm.com still works, but it loads up the 3M site without its stylesheet and shows a 404 page. I guess the redirect has been forgotten about at some point.

out of curiosity, why are you trying to validate emails?

Just a base level regex before sending emails, to avoid some errors sending to non-email addresses and logging otherwise unnecessary errors.

The best you can hope to do is reduce a small class out of possible errors. But you'll never get a test that can prevent errors like [email protected], [email protected], [email protected] etc. So is it really worth doing any checks at all?

I have a .blue email address and it's amazing how many sites still won't accept it. I keep a spare Gmail account for these.

> So is it really worth doing any checks at all?

People accidentally typing their name in the email field, stuff like that. I've done that.

The problems with your .blue is obviously completely unrelated to the "email.contains('@')" check the poster is doing.

I resent being called a poster! I am not flat, nothing was ever printed on me. I am a human being, you.. you... you piece of sheet!

The downvotes are a sign that I did not notice that my reply to the poster was not composed. I got the memo, and will take note from now on, mark my words!

.blue is 11 years old and still has issues. Same with several of the gtlds I have. I had an argument with a major backend email provider recently who refused to open an account for me as my gtld wasn't "valid." (they backed down eventually and fixed their code)

I keep a Gmail for the same reason.

I tried to add a .wiki link to a Reddit profile recently and their filters also say that domain is invalid.

> I tried to add a .wiki link to a Reddit profile recently and their filters also say that domain is invalid.

That's absurd, there's a .wiki that's almost definitely in the top 20 most visited websites in Korea, if not higher.

There's also minecraft.wiki.

In other words, /^.+?@.+$/ is a user-friendly reminder that you forgot the @ sign or something. That's all.

> But you'll never get a test that can prevent errors like [email protected], [email protected], [email protected] etc. So is it really worth doing any checks at all?

You can do quite well at this, if you're willing to not restrict yourself to regexes and commit to some amount of hackery. One system I worked on used a simple regex (just what is described here IIRC - assert the existence of an @ sign), plus did an MX check on the domain, plus warned (not errored) if the domain was within 1 or 2 Levenshtein distance of any of a list of most common email domains (yahoo, gmail, etc). Statistically it seems like we saved people a lot of grief with this simple filtering.

Does this block things like the unconventional Google-filing trick of:

  [email protected]

which gives me the “90sdev” tag for my emails, which still go squarely into my “[email protected]” address? I don’t know what the best route is, but I’ve certainly run into bad validators that block things that otherwise work, and that’s annoying. It seems to me the best thing might be to have a user twice input their address, then have the next step/confirmation done via email.

> bad validators

Possibly these validators are working exactly as intended and don't want you to know which service sold your email to spammers.

Then again maybe spammers are smart enough to strip of the + from email lists they purchase.

The latter was motivation to get my own domain so I can have unlimited unique addresses with a wildcard entry.

I never get spam that makes it through the default filter, so I am unsure if this works, but I do get zero spam in general since switching off gmail. I like giving silly businesses that ask for my email their business name @ my domain.

Most of the time they're too disinterested to notice. Oil change places always notice for some reason.

I'll look through my spam foldsr tomorrow and see who's been naughty.

I don't do blocking or differentiating. Emails are literal, for better or worse.

> unconventional Google-filing trick

Documented as "subadressing" in RFC 5233, and the default for both sendmail and postfix, amongst others. As such, often 'accidentially' supported by many mail providers even when undocumented. Google didn't introduce them, nor are they 'unconventional'.

https://www.rfc-editor.org/rfc/rfc5233

TIL

Does your regex support emoji usernames and domains? (both of which are in use, e.g. https://mailoji.com/)

My project doesn't even support emojis or unicode. In context, it's not an issue.

Both parts are limited to 7-bit ASCII or a subset thereof. Emojis have to be in punycode. You could theoretically use UTF-7 for the local-part but nothing supports it in practice.

That's the spec, for sure! The domains are converted to punycode, but the usernames? I have no idea what happens to them. My tests showed some providers delivered them, some didn't. I'm sure there are a bunch of people out there using accented characters and CJK etc in their usernames and wondering why it's not going so well...

That is officially the most cursed thing I've read all week. People really do love to do bizarre things just for the hell of it sometimes.

My site doesn't use HTML so that's not gonna help here.

You should know there is a standard regular expression for validating email addresses mentioned in an RFC.

I'm sure there is. And I'm sure many email servers deviate from it.

The real validation is the link in the confirmation email.

Tbh though ideally you would use the most restrictive validation that exists in the mail server. If mail server accepts '@tld' you do too.

Last time I checked the RFC the bit before the '@' can actually be empty. And the root zone is just '.', but we generally can leave off the trailing dot in domain names. So I believe '@' on its own is a valid email address.

Many years ago I managed to get a cctld owner to point their tld MX records at my smtp server, modified postfix to allow empty usernames (even although the RFC allows them, postfix didn't), and successfully had someone send me email to '@tld', in order to win a bet. :) (And it was a 2-letter tld.)

> So I believe '@' on its own is a valid email address.

Then the owner of "@" cannot use my site. I'm fine with that.

{1,} is just an awkward way of saying + isn't it?

But that would fail on the valid email "alice".