[Form validation] Built-in email rule says 'bad@email' is a valid email.

[kmd1970]

I entered bad@email while testing form validation using the built-in email rule and it came back as valid. Is this a bug? I would say the bad@email is not a valid email.

[mfeherpataky]

While it seems that bad@mail is bad indeed, it turns out that it is a valid email address. Top Level Domain is still a domain. Email validation - trivial on the surface - gets more complicated the closer the edge is. Some reading - I Knew How To Validate An Email Address Until I Read The RFC & Stop Validating Email Addresses With Regex.

[harogaston]

Well as @mfeherpataky said, as per RFC 2822 bad@email is in fact a valid address. However, it could be a sensible approach to validate at least a trailing domain, so .+@.+\..+ would suffice.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[TwistedLogic]

Although bad@email is a valid email address for the RFC 5321, according to RFC 5322 the following regex should better suit our everyday use (source):

^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$

[certainlysylvia]

How about just adding a flag for whether it is strict - per RFC 5321 validation or less-strict, aka, practical - per RFC 5322

Then it is right for all contexts.

[y0hami]

I don't see why this is an issue if you want to use RFC 5322 then you can just specify a custom regex rule.