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".
For other people who kind of don't trust your site, its future, or its security, but are too lazy to create extra accounts, you are forcing them to do a full evaluation in a way that adds additional weight to the possibility the site is an actual data broker today instead of an existential spam threat.
Personally, if I decided a site was bellow the threshold for my real email on an initial encounter and then I saw it perform this kind of detection, I wouldn't touch the site again.
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)
Disposable email exists for a reason.
If your site is just a chat forum and you don't mind spammers, sure let people use disposable emails.
If your site involves money or auctions or credit cards.. letting disposable emails in can be very costly.
The larger issue here is if someone is entering false information, it's likely because you don't have a good UX and are soliciting information before value is delivered.
With passport.js, it's so easy to implement authentication providers against existing FB/Twitter/LinkedIn accounts, which should suffice for your SaaS 14-day trial. When it expires, they'll enter in legitimate information if they see value added to it.
I understand everyone wants to capture e-mails for drip marketing purposes, but if you have a bunch of people entering fake information because you walled off something critical (Oracle, I'm looking at you and your JRE...), it's not an engineering problem - its a social one.
Someone using a disposable address probably does not even care about your "need". Why block them?
IMHO it really depends on the kind of service if this makes sense or not.
Lol.
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."
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.
If you're against this kind of library, I suppose you shouldn't bother with verifying e-mail addresses either.