There is really no point going further than this. It's more likely that someone will type the email wrong but still valid than they will type it completely invalid. There are also some completely wrong validators out there which expect the TLD to be 2-3 chars only.

The ultimate email validation is just trying to send an email to the address and confirming with a code/link.

I have had people rewrite my .io to .com because they were sure it was wrong, or something like that.

Never mind the regex, `email.indexOf("@") > 2` does the trick and faster if you happen to need to check many emails. All websites these days require verification of emails (regardless of whether or not it's necessary), and if that's not enough validation, I don't know what is!

I would use `email.includes('@')`, it only needs to be polyfilled for IE since it's in every modern browser JS engine.

Why 2? Greater than 0, sure.

The index of the first character is 0 and an email must have a local part so that means the index of "@" has to be at least 1. My guess is OP also forgot the index of the first character is 0 instead of 1 resulting in 1+1=2 (that or they meant >=).

Off by one errors are about half of working with arrays.

This is actually an uncommon example of an off-by-two error as they used strictly greater than 2.

  a@domain   fail
  ab@domain  fail
  abc@domain ok

Yeah...I have an email address I use a lot, "me@(domain)". It's perfectly valid, despite indexOf("@") == 2.

Heh, I actually meant `>=`. But as others have pointed out, that still excludes 2 letter users. Really it should be `>= 0`.

> 0 I would think, no? Can an email address be '@domain', no preface?

The regex listed there isn’t that much more complex. It’s basically a check for *@a*.* where * is some minimal whitelist of valid characters and a is an alphanumeric to start the domain name.

And even though that sounds reasonable, it is still wrong. Technically, you do not even need the dot, if you add an MX record to a whole TLD or have some other funky DNS setup.

Source: https://www.netmeister.org/blog/email.html

I'll quote the WHATWG HTML spec, which that Ruby code cites as its source (https://html.spec.whatwg.org/multipage/input.html#valid-e-ma...):

> This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

Personally, I say if it's good enough for Web browsers, it's probably good enough for your app.

The linked regexp doesn't require the TLD: https://rubular.com/r/Y9G4HR2Ox8gzqd

Yep! I know that @mil addresses used to be a thing. With the explosion of new TLDs I would be unsurprised if name@gmail addresses became a thing in the future and silly devs handled it by adding an exception to their huge regex instead of just using “.+@.+”.

This depends on your use-case. If you're writing a mail agent, then you do probably want to parse email addresses in their entirety. If you're writing a website that accepts email addresses and wants to make sure the user doesn't just type "foo", then yeah, check for `.+@.+` and call it a day.

If you are writing a webpage that accepts email addresses, then please just use <input type="email"> and check for:

    document.querySelector("[type='email']").validity.valid

This will not only give you email validation for free, but also gives users with software keyboards (e.g. on phones) a contextual keyboard.

That’s just for the client though. Best to check on the server as an authoritative source of truth.

It’s probably a waste of time for an individual developer to write a one-off complicated regex for a contact form. A team of contributors to a standard library should be optimizing regex a bit more since doing so will save so many developers time vs using even a very simple one-off regex, when testing is accounted. The optimizations here are reasonable and internationally compatible.

What about @@.@?

Interesting question. RFC1123 states that TLDs should be alphabetic, and that the first (or only) character must be a letter or a digit, which should exclude a TLD of '@'. local-parts can include most printable characters other than ()<>[];:@\,.

/^+@+$/ is easy and the false positives it allows are weird enough to accept.

People who have weird email addresses are used to them not working.

There is nothing before the first @, and nothing after the last @.

While that's true, `@@.@` fulfils "an @ symbol with something before it, and something after it".

The original comment probably meant something like this: ^[^@]@[^@]$

That's only one letter before and after.