It is allowing invalid emails

[schweigert]

He is currently allowing emails like test test@gmail.com.

[estepnv]

also it accepts emojis. I looked at regex. is it really enough?

[schweigert]

The regex does not specify which characters can belong to an email. It just says it needs to be a character. Spaces and emojis fall in these cases :(

[karlwilbur]

The intent of the "loose" checking is just to confirm that there is an email-like string provided. The README makes this pretty clear.

I have a fork that maintains the earlier, more strict, validation:
https://github.com/karlwilbur/email_validator

[balexand]

@karlwilbur Thanks for all of your contributions to this project over the years. I'm no longer developing in Ruby. I've been using Elixir for the past 2 years.

Do you have any interest in taking over the official email_validator gem?

[schweigert]

This is the most beautiful action that the open source community can see

[karlwilbur]

@balexand Sure. I'd be happy to.

I'll have to sort out how I am going to support your changes to accommodate David Gilbertson's validation philosophy. While I clearly disagree with that and prefer to have more standards-compliant validation, I respect that there are others who are far less concerned with that than I. As such I don't want to break their implementations and would like to provide them the same support that the community has provided me.

I'm available to work with you to transition this over to me in whichever way you see fit.

[kapcod]

@karlwilbur I suggest maybe providing various levels of validation.
E.g. just allow EmailValidator.method = :strict (with default to :loose)

In our case, we do need constantly up-to-date exact validator, so that we stop getting these errors from email provider saying that we're trying to send emails to invalid addresses. Somehow people just love to create emails like "user@gmail" without the ".com" and even thought "gmail" IS a valid domain by domain validator, it's not a valid address and gets rejected. Or addresses like "user-@gmail.com" which turned out to also be invalid.

[karlwilbur]

@kapcod Yep, that's sort of what I have in mind. You can see what I have over at https://github.com/karlwilbur/email_validator and I'll be trying to work those changes into a new release here within the next month or so. I had hoped to get to it sooner, but 2020 just been one of those years.

What I already have does this:

validates :my_email_attribute
validates :my_email_attribute, email: {strict_mode: true}

EmailValidator.valid?('narf@example.com')
EmailValidator.valid?('narf@example.com', {strict_mode: true})

Or you can enable via your Gemfile, as explained in the README, and also via an initializer with:

EmailValidator::default_options[:strict_mode] = true

However, in your case, user@gmail is technically valid per the RFC, which is how the strict_mode works. I think that, for you, we might want to add a :require_fqdn config option similar to what I am with the :domain option. Do you think that it would work for you if we adding something like this:

# per-model
validates :my_email_attribute, email: {require_fqdn: true}
# via initializer
EmailValidator::default_options[:require_fqdn] = true

I also want to include the ability to supply a custom regexp per-model or via an initializer, but haven't started on that yet.

[kapcod]

I checked your fork, even in strict mode if matches "aaa@gmail" as valid, even though it will be rejected by any email provider as invalid. EmailValidator.regexp(strict_mode: true) === 'aaa@gmail' => true Even though 'gmail' might be a valid domain as per RFC, same as 'localhost' and 'invalid' but it's not really valid for emails.

…

On Tue, Oct 13, 2020 at 6:49 PM Karl Wilbur ***@***.***> wrote: @kapcod <https://github.com/kapcod> Yep, that's sort of what I have in mind. You can see what I have over at https://github.com/karlwilbur/email_validator and I'll be trying to work those changes into a new release here within the next month or so. I had hoped to get to it sooner, but 2020 just been one of those years. What I already have does this: validates :my_email_attributevalidates :my_email_attribute, email: {strict_mode: true} ***@***.******@***.***', {strict_mode: true}) Or you can enable via your Gemfile, as explained in the README, and also via an initializer with: EmailValidator::default_options[:strict_mode] = true However, in your case, ***@***.*** is technically valid per the RFC, which is how the strict_mode works. I think that, for you, we might want to add a :require_fqdn config option similar to what I am with the :domain option. Do you think that it would work for you if we adding something like this: # per-modelvalidates :my_email_attribute, email: {require_fqdn: true}# via initializerEmailValidator::default_options[:require_fqdn] = true I also want to include the ability to supply a custom regexp per-model or via an initializer, but haven't started on that yet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHKEBUK2QGB3F7I2T7FBS3SKRZHBANCNFSM4K4CUFYQ> .

[karlwilbur]

@kapcod, Yes. Correct. This is because "aaa@gmail" is a valid email. Is the same way, "karl@karl-desktop" is a valid email address (I successfully use karl@karl-desktop many times a day). This is per the email standards and are valid emails.

You are looking for something more than just a valid email address. You want to also require a FQDN. Do you think that my suggestion (adding a require_fqdn option) would work for you?

[karlwilbur]

@kapcod, I added that require_fqdn option and enabled it by default. You can check it out here:
https://github.com/karlwilbur/email_validator/commit/a7ec186e29c503231580729066ffa98d7d611d8b

Let me know if you think that would work for your situation.

[karlwilbur]

@kapcod The require_fqdn option was added in v2.1.0. I am closing this issue.

[karlwilbur]

Just to be clear, the :require_fqdn option is not enabled by default in the actual release. It can be enabled as detailed in the README. When :strict mode is enabled (using mode: :strict, strict_mode: true is no longer supported), the :require_fqdn is also enabled.