
Detect up to 1327 disposable email providers with MailChecker - fgribreau
https://github.com/FGRibreau/mailchecker
======
wanderfowl
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".

~~~
zrail
I built this kind of check into my ecommerce sites for high-value items.
They're disproportionally susceptible to fraud and carding for some reason,
and implementing a "no free email provider" check has cut fraud on those items
to zero.

~~~
mapt
I expect blocking GMail, Hotmail, & Yahoo Mail also cut your conversion rate
close to a factor of zero of what it would otherwise be.

~~~
jks
Here's how that might happen: [http://mailinator.blogspot.com/2011/05/how-to-
get-gmailcom-b...](http://mailinator.blogspot.com/2011/05/how-to-get-gmailcom-
banned-not-that-i.html)

------
therealidiot
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)

~~~
a9entroy
Seriously, if any site owner has even a half of a brain, he should stay away
from this shit.

Disposable email exists for a reason.

~~~
brianwawok
That is not true at all.

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.

~~~
tom_mellior
If a quick-and-dirty domain check on an email address is more secure for fraud
detection than credit card data, then that says a lot about how broken the
whole credit card system is. No surprise, of course. Sad that Bitcoin blew its
chance to replace this crap.

~~~
brianwawok
You don't replace, you use it in addition. Layers of security.

Now if you want to spam 500 million credit cards on my system, you are going
to need to at least make them from some common domains, which I can block down
the road. If you are using an email hiding service, way easier for you.

Not sure bitcoin matters, if I had users paying with bitcoin in an app I would
STILL blacklist certain email domains.

------
egeozcan
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.

~~~
iheartmemcache
I agree with the hard-coding being not-too-great-of-an-idea. However, I'm
going to argue that a @gmail has a way higher chance of being a legitimate
email out of a random sample space than a domain from @tempx.com.

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.

------
SNvD7vEJ
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.

------
aw3c2
> 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?

~~~
detaro
Why allow them if you think they probably are more trouble than they are
worth? (no way to contact them if there are payment issues, easier to take-
over accounts, ...)

IMHO it really depends on the kind of service if this makes sense or not.

~~~
aw3c2
Totally depends but in the majority of cases I see no issues. Why do you
assume they are up to cause trouble? I used throw-away mails hundreds of times
and the only thing I usually did was inflate their user table with another
single time visitor.

------
dogma1138
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.

~~~
pki
China's largest freemail provider (which requires a chinese national identity
number to register for) is also on that list.

Lol.

------
devit
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).

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

~~~
mkoryak
I wish that you didn't write this comment

------
spdustin
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."

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

~~~
fgribreau
In fact, there are now 1979 disposable e-mail providers

------
krapp
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.

------
detaro
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.

~~~
lcswi
I signup with bugmenot:bugmenot whenever I can to explicitly allow that.

------
vincentdm
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.

~~~
caf
Verification emails serve the purpose of ensuring that people don't sign up
other people's email addresses.

~~~
imglorp
And if they do, why is that bad?

~~~
pdkl95
Because of the script that destroys email addresses by signing them up for
5000 mailing lists.

~~~
no1youknowz
What script is that? Never heard of such a thing.

~~~
pdkl95
There were several going around in the "warez" scene in the mid-90s.

It didn't require a script, either. When mailing lists and other automatic
email sources let you add destination addresses without closing the
confirmation loop by sending a test email, you can denial-of-service email
addresses with just an SMTP client.

The really nasty part about this attack is that it's not just bandwidth
amplification. Normal amplification attacks go away when the attacker decides
to stop sending packets. With mailing subscriptions, the badly-configured
mailing lists _keep sending_ the attack on their own.

