Alternative gem: email_address

[cabello]

Hi 👋 ,

We've been using this gem for a while, then we started getting some "hackerish" invalid emails in our database as a result we had to look for alternative validations. At first we used the Ruby built-in regex URI::MailTo::EMAIL_REGEXP but this one has some use cases where it does not work with a valid email.

Looking at the source code I am under the impression this gem's regex is very simplistic "no spaces" plus "@ symbol" followed by "no spaces". That may result in invalid emails, also allows for stuff like <script>alert()</script>@domain.com.

I would like to promote this alternative https://github.com/afair/email_address that includes a Rails validator and has some other goodies like emails types, hashing, etc.

Thanks for sharing your project 💜

[karlwilbur]

Thanks!

You are correct in that <script>alert()</script>@domain.com is very much not a valid email address. While <script>alert()</script>@domain.com is invalid, properly escaping user input when rendered as HTML would not allow that invalid email address to be executed as JavaScript. So, the only real consideration is that a clearly invalid email address is passing the simple validation check.

The "local-part" (username) characters in an email address should be limited to only /[a-z][-a-z0-9!#$%&'*+"=?^_`{}|~]{0,63}/, per RFC 2822. Your suggested alternative is not RFC compliant either; in fact the author calls it "madness". There was, at one point, a "strict mode" for this gem which had increased validation covering some of that. However, it is worth noting that the clearly stated validation philisophy of this gem (as of 2019-03-02) is to use an extremely loose interpretation of what constitutes an email address.

Yes, I have read The 100% correct way to validate email addresses and just simply disagree with the general "epiphany". While "send your users an activation email" is indisputably the best way to validate a users email address, what happens to other email address that aren't provided as part of user registration; one to which a confirmation/validation email should not be sent? What about parsing emails from another source than typed user input? A field validator has more reason for existence than to check for a user's typos.

FWIW, I use my fork of this repo (at a much earlier version) which implements a much more strict interpretation of a "valid" email address (e.g: karl is a strictly valid email address, per the RFCs). You are certainly welcome to use my fork, but I would very much like to see this official repo have proper email validation and agree that /[^\s]@[^\s]/ is entirely insufficient. I realize that my concerns are outside the defined scope of this gem, which is why I maintain my fork. I just wish that it weren't so.