Could someone add some explanation to the readme as to whether this is built in a way that minimizes either false-positives or false-negatives?

It seems email validation is absurdly more complicated than I would have expected: http://stackoverflow.com/questions/46155/validate-email-address-in-javascript . While it'd be very nice to have a module that conforms exactly to the spec, it may not be feasible either because the spec is bonkers or because real use cases (ie real emails) violate the spec.

In fact, what might be best is to have two validators, one intended to have no false-positives (and thus will have false-negatives) for use in creation of email addresses, and one intended to have no false-negatives (and thus will have false-positives) for use in validation of already-created emails to send emails to. That way real emails that violate the spec can be accommodated without encouraging the same spec violations in future applications.

Interesting edge case - numbers are allowed after the final dot even though it would always be a sign of an invalid email address - for me it happened while failing to click tab and advance to the following phone number field.

It seems that not all types of the domain can be validated.
For example

• [email protected] - should be accepted
• first.last@[IPv6:::12.34.56.78] - should be accepted

I suggests to update the test regexp to something like this
/^((?:\w+[!#$%&'*+-\/=?^_`{|}~]?\w+)|\w)@((?:(?:\w+[-\.]?)+\w+\.\w+)|(?:\[IPv6:::(?:[0-9]{2}\.){3}[0-9]{2}\]))$/iu

the arrow function raised the minimum node version to 4. This library previously functioned in older environments. This should be a semver major update. Could 1.2.x be unpublished and bumped to 2.0?

Hello,

This validator returns invalid for the "[email protected]" emails pattern like.

if(EmailValidator.validate(this.email)){ alert("invalid"); }else{ alert("valid"); }

:)

Have a great day !

Exporting the expression will help a lot as I am already installing the package and it makes sense to use the same expression in my database models rather than just copy-pasting the expression each time.

I did a vulnerability test of the regex.

1. it failed in https://www.npmjs.com/package/safe-regex
2. 'Invalid' in https://www.npmjs.com/package/vuln-regex-detector, I don't know why it's invalid, will follow up.

Should I worry about the vulnerability of the regex used in the package?

Thanks!

It would be great if we can have a configuration option for custom domains. Our email domains are around 75 characters long. I propose something like
{
max: 300,
nameMax: 50,
domainMax: 250,
}

is it ok if i create a PR for this?

If quoted, it may contain Space, Horizontal Tab (HT), any ASCII graphic except Backslash and Quote and a quoted-pair consisting of a Backslash followed by HT, Space or any ASCII graphic; it may also be split between lines anywhere that HT or Space appears. In contrast to unquoted local-parts, the addresses ".John.Doe"@example.com, "John.Doe."@example.com and "John..Doe"@example.com are allowed.

https://en.wikipedia.org/wiki/Email_address

Please remove comments from index.js file and minify it.

Hi @Sembiance . I am willing to rewrite tests for this library with mocha, and travis ci and create Universal Module Definition for consuming this module in browser. Just want to confirm if i can work as there is not changes made in this module since aug 2017.
Thanks :).

https://stackoverflow.com/questions/3844431/are-email-addresses-allowed-to-contain-non-alphanumeric-characters

For example:
var validator = require("email-validator"); validator.validate("a.castañ[email protected]");

This should be true.

The mail returns valid even if the top level domain is made up of 1 character only

e.g. [email protected]

While this is theoretically correct, there are no one-character domains available. Therefore I'd advice to take this fact into account.
http://stackoverflow.com/questions/7411255/is-it-possible-to-have-one-single-character-top-level-domain-name

Hello.
I tried to validate [email protected] and it goes trough as valid.
Is there any way to have an email name that contains only special characters before @ or is this a bug?

According to RFC-2821, page 54 the character limits are as follows:
path: 256
local-part: 64
domain: 255

I propose the following changes:

index.js
line 13: if(email.length>256)
line 26: if(domainParts.some(function(part) { return part.length>255; }))

The element separator (@) is included in the total length of the path

By "personal email", I mean @google.com, @msn.com, etc.

Could you suggest any open source library?

Hi @manishsaraan,

We are using your npm module - email-validator for basic email validations in our NodeJs based application (https://www.npmjs.com/package/email-validator).

We observed that the module was last published 5 years ago with the version 2.0.4. However there are no tags or releases present in the git repo.

npm version 2.0.4 points to the Git commit - https://github.com/manishsaraan/email-validator/blob/2c16df5e6f79b34ccae1baeb62efaee218eb73ac/index.js

We are getting the following issue in the 2.0.4 version release - the email domain length check allows only 254 characters. But as per some global standards for email, the domain length can be of 255 characters.

We checked the git repository and found that some fixes have been made (for the domain length check) after the last npm publish.

PR where the issue was fixed - #53

Our application works fine with the latest master branch commit (df02ecd).

Can you please review and advise if a new npm version can be released, so that our application can fetch the latest code from npm.

Thanks,
Anupam

You have a typo in test.js, there is lenght instead of length.

Would be great there was a note on if the regex is vulnerable against ReDos.
I tested on

• https://devina.io/redos-checker
• https://makenowjust-labo.github.io/recheck/

and both say that regex is linear.

only http://redos-checker.surge.sh/ is saying that it's vulnerable but I suppose it's very old and not that smart?

Hi, I am an email-validator user and a developer who wants to keep his apps dependencies up to date. I have to migrate my email-validator from 1.2.3 to 2.0.4. I would like to know what where the breaking changes. I would like to do that without diving into the commits. That would be hard detective work and lots of slow read.

Shall I point to a good example of a release: https://github.com/socketio/socket.io/releases/tag/4.0.0

Update: found CHANGELOG.md but it did not contain any instructions for v1 to v2 migration.

I'm testing out some emails, for some reason the validator.validate("[email protected]");
is returning true for that email?

Why are emails with +'s considered invalid?

https://en.wikipedia.org/wiki/Email_address#local-part

email validation is not working

your validator returns true, for a random input [email protected] also

How to reproduce

Try use email with double hyphen, for example : [email protected]

Expected Result

[email protected] should be valid email

Actual Result

[email protected] return as invalid email

This issue is like TODO and random-access roadmap in one to transform problems and suggestions to the code.
"opt-in" features should be totally optional and tree-shakeable. The list is subject to change.

• [feat / dev] Use releases to track important changes between versions #60
• [feat / config] Some configuration #20
• [feat / important] IPv6 compatibility: #59
• [feat / important] utf compatibility. Three PRs are open regarding this. One of them is #57
• [feat / important] Load tests. Due to previous hypothetical changes, it can become slow or an attack vector. Should test execution time against some tricky dataset.
• [feat / node / opt-in] MX-record validation as opt-in. Influenced by #65
• [feat] More strict flags and/or allowed symbols somehow. Influenced by #71
• [feat] Universal esm / commonjs bundling to shake that tree being modern and a bit compatible. Will introduce some runtime requirements bump, hence major release.
• [feat / easy] #66 Maybe.
• [feat] Private domain check as a (plugin??). Influenced by #70

Hi, @manishsaraan ! Do you still maintain the lib? I see, there're a lot of old open issues.
If you just have no time, would you like to share the access to issues and PRs and possibly npm publishing ?
I don't want to create YeT AnOThEr email validation lib, but rather be sure that some of the popular is in my production.

Version 2.0.3 released, please add a changelog entry. ❤️

this library sadly totally fails in validating internationalized domain names (https://en.wikipedia.org/wiki/Internationalized_domain_name)

e.g: müller.com is a valid domain but would be considered not valid for the lib.

These are valid, but unhandled, e-mail addresses:

name(nested (comment))@example.com
"my name"@example.com

See this link for more details:

http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx/

I found that validator.validate('[email protected]') returns true. It must be false.

it("should be able to validate('[email protected]')", function() {
  expect(validator.validate('[email protected]')).toEqual(false);
});

For instance: [email protected] (notice the trailing j) is considered a valid email. This can conflict with other node validation libraries like joi used in the backend - the above would not pass joi's email test (see tlds prop here) because comj is not listed in the IANA registry

It will be nice if the readme.md says something about the features of the module , like what purpose does it serve etc . I can work on this

The async version is a worse API and not asynchronous in any way. It should be removed to simplify the API and make the package smaller.

I tried to validate an email address [email protected] and it came back false.

.info is the 8th most popular TLD https://www.icdsoft.com/blog/what-are-the-most-popular-tlds-domain-extensions/
so it seems it should probably be supported.

Webpack builds have begun to fail due to a published version with ES6 syntax if running UglifyJS (arrow function on splitting domains) here: https://github.com/manishsaraan/email-validator/blob/master/index.js#L30

#27 it looks like the module was republished with es6 code still at 1.2.1

• [email protected] (test if valid)
• [email protected] (test if invalid)

shouldn't they pass?

The following code is throwing an error whereas it should return false:

var validator = require("email-validator");
validator.validate();

validator.validate("[email protected]"); // return true

If I enter with an empty field as email ("") it doesn't return error

what is the maximum limit of requests per month?

What about returning an error message to precisely indicate what is wrong with the given value instead of just returning true or false?

well .I have already installed email-validator from npm and it's version is 1.0.3.
I just follow the instruction requiring module and using the "validate" function to my mail-address.
Nothing happens.
=-=Maybe you can change the api to something like e.validate("[email protected]",function(err,res){...}); for debugging?

EmailValidator considers an email in this format [email protected] invalid. Why? And is there a way to make it accept this format?

The following program compiles fine but fails at runtime:

import * as EmailValidator from 'email-validator';

EmailValidator.validate_async('[email protected]', (ex, result) => {
  console.log(`valid? ${result}`);
});

ohnobinki@gibby ~/repos/email-validator-play $ ./node_modules/.bin/tsc
ohnobinki@gibby ~/repos/email-validator-play $ node index
/home/ohnobinki/repos/email-validator-play/index.js:4
EmailValidator.validate_async('[email protected]', function (ex, result) {
               ^

TypeError: EmailValidator.validate_async is not a function
    at Object.<anonymous> (/home/ohnobinki/repos/email-validator-play/index.js:4:16)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
    at bootstrap_node.js:609:3

I expected it to fail at compile time.

Hello,
I experienced that an email address like "###[email protected]" is considered as a valid email address.
In the tests, "! #$%|@invalid-characters-in-local.org" is classified as invalidSupported`.
May this be a bug?

Thanks in advance & best regards