If your site will be sending something of value over email, then people will want to use a real address, and you don't need this. On the other hand, if you just want a user ID, then it doesn't matter what they use, and you don't need this, either.

So, if you use this, you're a site who wants a real deliverable address for some reason, but which doesn't offer enough benefit to the user to naturally compel them to share one. Put differently, if you need this, you're precisely the kind of site that shouldn't get my real address.

All that this script means is that I'm going to leave your site unregistered and frustrated, and will mentally bookmark your domain as "those twits who force you to sign in and creepily want an actual address".

I've encountered sites that do this kind of check before, and I usually just don't bother signing up.

It's usually the case that I didn't /really/ want to sign up anyway, but I needed something (that with a little effort I could find elsewhere)

Searching in a hard-coded list of strings is not the best idea, and why try to detect them anyway? You can block all the free email services as well because they can also be used as disposable mail providers with a few more steps to get going. Not to mention that it takes around 10 minutes to set up a disposable email service if you have a spare domain and when it's in this list so you let it expire, even if this repo gets updated, there'll be many sites using an older version, causing too much problems for the new owners.

Site owners that need to use this shit probably also ignores users need for privacy, like ignoring unsubscribe requests, the right to be removed from their databases, or hiding the fact that they distribute or sell user info.

> This will be very helpful when you have to contact your users

Someone using a disposable address probably does not even care about your "need". Why block them?

hushmail.com is on that list, this is an increased privacy email with built-in PGP and encryption support, and it's a paid service this is hardly a throwaway email, funny enough their alias domains (e.g. nym.hush.com) aren't on that list, if any one will use it as a throwaway email (i do) they'll use the alias function and delete or suspended the alias after the signup (that's what i do, if i need to reset a password i recreate the alias). That list seem also to contain ISP's from eastern Europe and Asia so I would go over that list very carefully before implementing it because it might break your site.

Please don't do this, unless you are being attacked and have exhausted all other options (such as fingerprinting the attackers in a more targeted way).

I appreciate all the efforts that went into making this but I wish you didn't release it.

So much vitriol in here for something I immediately thought: "damn, that'd be handy." So often we have a potential student email us, and our reply disappears into a spam folder because it came from Zendesk or Postmark, or because their own words (echoed back) trigger it. And when we finally reach those people, people who actually and legitimately want to talk to us, they're thankful that we tried to find them, and asked us to change their email entry in our database to a more reliable one. Then there are those who get angrier and angrier at our failure to respond, while our responses are piling up in a spam folder somewhere. Well THAT's a great start to what is typically a years-long relationship. Or those who just take their business elsewhere.

Incidentally, ours is a B2B market, remember that when judging how we - and others - roll. Also: we check RBLs and test deliverability frequently, use SPF/DKIM allowing the providers we use to deliver mail on behalf of our domain, and we have DMARC configured so we can better monitor deliverability issues.

I'd use this to show a brief warning on our "contact us" form: "we've found that using an email provider such as example.com may result in our reply getting filed away as spam, and we recommend using your real work address to be sure you see our reply without having to dig through all the spam on your personal email account. You don't have to change it, but we wanted to warn you in advance."

Neat, a list of 1327 disposable e-mail providers.

I think this would be more usable if the lists weren't hard-coded into the functions. Passing JSON as a parameter would be possible for any language worth using, no "templates" necessary. Requiring Node.js to rebuild an array inside a PHP function seems kind of weird.

Also, list.json doesn't appear to be a valid json file since it uses comments.

I'm not going to comment on whether or not I think it's useful.

An argument that I haven't seen yet is that some of these providers allow to choose the mail address used, allowing anybody who knows or can guess the address used to take over the account.

I wonder if all the critical commenters here feel the same about sites sending a verification e-mail before completing your registration. After all, it serves the same purpose of preventing usage of bogus e-mail addresses.

If you're against this kind of library, I suppose you shouldn't bother with verifying e-mail addresses either.