Detect up to 1327 disposable email providers with MailChecker
1–10 of 46 posts
Re: Detect up to 1327 disposable email providers with MailChecker
#2I'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)
Re: Detect up to 1327 disposable email providers with MailChecker
#3> 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?
Re: Detect up to 1327 disposable email providers with MailChecker
#4Please 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).
Re: Detect up to 1327 disposable email providers with MailChecker
#5Searching 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.
Re: Detect up to 1327 disposable email providers with MailChecker
#6> 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?
Agree, they will go to the competitor instead.
Re: Detect up to 1327 disposable email providers with MailChecker
#7Site 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.
Re: Detect up to 1327 disposable email providers with MailChecker
#8I'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)
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.
Re: Detect up to 1327 disposable email providers with MailChecker
#9If 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".
Re: Detect up to 1327 disposable email providers with MailChecker
#10Searching 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 rep…
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.