Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative gem: email_address #58

Closed
cabello opened this issue May 6, 2019 · 1 comment
Closed

Alternative gem: email_address #58

cabello opened this issue May 6, 2019 · 1 comment

Comments

@cabello
Copy link

cabello commented May 6, 2019

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
Copy link
Member

karlwilbur commented May 6, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants