Disposable emails - Identifying, marking

Members (beta)
#1

I have noticed a number of member signups from disposable email service providers, including:

yopmail
dispostable
sharklasers
mailinator
airmail
spambox
maildrop
guerillamail
and on and on

Some are easy to spot based on their names, others not.

I have created two labels for accounts when I run across them so I can keep a lookout for behavior in the Mailgun and Cove dashboards.

It occurs to me that it might be interesting to develop a community-sourced “blacklist” for known disposable email address providers and a module that would flag new member signups with the label “Disposable” so ghost admins can keep on top of them. Maybe the list could be hosted on github and the module could check github for updates.

#2

Hello

Like that?

(The list)

#3

That’s the start for sure.

The next step would be to do a one-way integration with Members so it can automagically flag known disposable domains in the most efficient manner.

After that, it would be nice (but maybe a lot more work) to push a newly-flagged domain to the repository.

#4

Disposable emails can be a big issue, so this feature looks promising. The question is how should we handle registration from these emails:

  1. Block registration - show error while registering
  2. Automatically add a label to the user and let the admins decide what to do

Also is there are need to enable/disable this feature in the admin? Do we also need to manually blacklist some domains?

#5

On the previous platform, Akismet was used to flag spam posts and delete them by default in a very non-helpful way – I got no notifications of the decision to label a post spam. Finding them was made more difficult because the platform supported logging in using Google or FB and so often there was no email address associated with an account or post. Double Yikes!!

  1. Any system that is devised should visibly flag members in a way that lets an admin decide what to do.
  2. The site owner should be able to enable/disable.
  3. It would make sense if there were a local greylist of domains the admins would also like to flag. There is a method for updating the list maintained by ivolo but I can’t tell immediately if that can be done through the API.
  4. There should be the ability to also set the send/not send status flag to not send when a known disposable email address is used.

As a Stripe account is required for paid memberships, a BONUS capability would be to compare the email address from a member’s Stripe account to see if they match. Again, just a yes/no notification is all that would be needed to help an admin evaluate the status of a member.

#6

Just to add something:

If you want to get rid of disposable emails, is to keep a clean member database.

I often use disposable emails to register to platforms I don’t trust. But if the platform is clever enough to detect that, I might reconsider this choice and put a real email.
So, I think it’s better to warn the user when a disposable email is detected than flagging it afterwards.

Next, if the user is paying with stripe, you are paid. Why do you want to bother this user with an email check? Just let him stay with this email and take the money.

1 Like
#7

I agree, to keep a clean member database the best way is “get rid of” disposable emails.

The question is how best to do that.

A proactive approach is to flag the use of a disposable email address in the signup process. The process could be to deny the use of known disposable email providers, requiring the use of a “legit” email provider. I can see the value of this approach …

In my experience, I do not want an automated process that does not provide visibility about the actions it is taking. So, I am okay with the proactive approach as long as I get a notification when it happens and the notification includes the full email address that was flagged. Over the course of the past thirteen years I have been an active community moderator, growing communities counting more than 20,000 members, having this information has been valuable to me in managing the member database.

So - the question is, anyone interested in working on this integration? I think it will be very useful.