SchemaRegEx.Email is not entirely valid about meteor-simple-schema HOT 6 CLOSED

It might be best to have a few different varieties built in, perhaps add an IntranetEmail expression but leave the current as is. At the time I was initially writing the built-in expressions, I know I researched and tested half a dozen different expressions and settled on this one as the most correct for most general uses. However, I don't remember much about my decision process anymore. I was probably thinking that 9 times out of 10 we don't want domains without TLDs. I might not have considered the use case for "+" at all. I'm definitely open to PRs for additional built-in expressions, or possibly we can adjust Email to allow the "+" but still require the TLD. Others are welcome to comment their thoughts.

from meteor-simple-schema.

I strongly advise to keep regex-based email validation as permissive as possible. [email protected] is enough. The only way to validate an email address is to send an email.

from meteor-simple-schema.

@steph643 what is your reasoning? The new top-level domains would seem to make pattern matches a little more difficult, though it is still in the best interest of UX to try & detect issues and notify the user.

Also, it isn't like this isn't a solved problem. I'd look to projects like WordPress to see what pattern matching it employs.

@aldeed I would like to see '+' supported if it isn't currently.

from meteor-simple-schema.

There are many discussions about this on the Internet. Google: regex email validation.
From an API provider perspective, I think the safest way (unless you want to spend endless hours in support and debates) is to only check [email protected], then to allow users to provide an alternate algorithm.

from meteor-simple-schema.

My goal really is just to give a simple built-in option for people who want to get up and running quickly. You can, of course, provide any regex you find online or create yourself rather than using the built-in. You can also reset SimpleSchema.RegEx.Email to any regex you wish. So I don't think the aim is to please everyone.

On the other hand, if a package like this can provide a few different expressions that meet the most common validation needs, then that potentially saves a lot of time for a lot of people who would otherwise have to research and find/write their own.

So I still think it might be best to provide a few different options. Maybe the default should indeed be the most permissive, and then one or two less permissive alternatives can be available. Regarding "[email protected]", one could argue that "anything@anything" (i.e., contains one "@" that is not the first character or the last character) is more accurately the bare minimum because, according to the spec, the domain could be an IP address or "localhost".

from meteor-simple-schema.

Didn't see PR #89 until after responding. I think that PR matches pretty well with what I said. Anyone else have comments on it?

from meteor-simple-schema.