Page MenuHomePhabricator

Email abuse - filter to stop?
Closed, DuplicatePublic

Description

Author: and1eternal1

Description:
Hello,

Due to persistent abuse of Special:EmailUser to send trolling, abusive threats via email (see https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&oldid=471728107#Death_threat, for example), I am requesting that either a feature be added to the abusefilter to scan emails for these things as they go out, or a email blacklist (formatted and functioning along the lines of MediaWiki:TitleBlacklist) be created to block mailinator and related email addresses.

Many thanks,

Reaper Eternal


Version: unspecified
Severity: enhancement

Details

Reference
bz33761
TitleReferenceAuthorSource BranchDest Branch
update dockerfile-frontend image tagrepos/releng/buildkit!61jeltoupdate-dockerfile-frontendwmf/v0.12
fix BUILD_VARIANT for dockerfile image buildrepos/releng/buildkit!60jeltofix-build-variantwmf/v0.12
fix syntax in buildkit Dockerfilerepos/releng/buildkit!59jeltofix-dockerfile-syntax-buildkitwmf/v0.12
fix syntax in dockerfile-frontend Dockerfilerepos/releng/buildkit!58jeltofix-dockerfile-syntaxwmf/v0.12
manage dockerfile trusted runners in add-project.py scriptrepos/releng/gitlab-trusted-runner!66jeltomanage-dockerfile-runnersmain
add Trusted Dockerfile Runner types to test and prod environmentrepos/releng/gitlab-settings!59jeltoadd-dockerfile-runnersmain
add CI pipeline for dockerfile-frontendrepos/releng/buildkit!55jeltoadd-ci-dockerfilewmf/v0.12
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:03 AM
bzimport added a project: SpamBlacklist.
bzimport set Reference to bz33761.
bzimport added a subscriber: Unknown Object (MLST).

This is urgently needed on en-wiki; there is currently no way to prevent harassing e-mails from throwaway addresses and this is being taken advantage of to harass and threaten editors.

Prodego wrote:

The abusefilter isn't a very good option for this. The abusefilter records the value of its variables for each edit. It does this for debugging purposes and to ensure that false positives can be identified and fixed. This means that you'd either be publishing the text of all emails sent by EmailUser in the abusefilter log or, if you choose not to show them in the log, risk having a filter blocking emails incorrectly (including possibly all emails) going unnoticed for long periods of time. A wiki editable email blacklist isn't a good idea either, because changes to the blacklist could occur after you've confirmed your email address. This means your previously working email features would stop working. This could be partially mitigated by blocking only the ability to send emails, but it would still be confusing to the user.

john wrote:

Agreed, this isn't something to be solved by AbuseFilter. Probably a solution like SpamBlacklist, but for emails.

and1eternal1 wrote:

Using another means to solve this is fine with me. I merely presented the only two methods I could think of to stop the problem.

rolandrance wrote:

This problem has also been raised at http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive720#Being_spammed, http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive717#Abusive_Emails_3:_Return_of_the_Abusive_Emails, http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive731#Email_abuse_from_Mailinator_address, http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive726#Mailinator_addresses and http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive735#Mailinator_addresses_.28again.29. It is a serious problem, affecting many editors, some of whom have disabled email as a result. A vandal creates a new account, does not edit any pages with it, but uses it to send scores of abusive messages ( I have received about 750 over the past six months). The messages themselves are generally either gross racism, or graphic threats of maiming and death (sometimes both). The email addresses are disposable ones, usually from Mailinator. In most cases, the email address too is either a racist slur or a threat of death or maiming directed at an individual editor.

Surely there is a way to prevent accounts which have not been auto-confirmed from sending scores of abusive emails at a time, using abusive email addresses.

That's really disturbing.

One possible (temporary?) solution would be to restrict sending email to those who are autoconfirmed (Which is a trivial config change).

Prodego wrote:

This is unacceptable as contacting the blocking administrator by email is the primary way to contest blocks, and non-autoconfirmed accounts are disproportionately likely to be blocked than those that have been confirmed.

rolandrance wrote:

But contacting blocking admins does not require the ability to send several dozen identical emails to a user. And surely it would be possible to construct a filter which would prevent emails from addresses such as "(User:x) is a dirty Arab", "(User:y is a traitor to the Jewish people" or "Death to (User:z)" -- all of which I have encountered over recent months.

Ideally what we probably want, Is a method to disable signups from certain domains to prevent future abuse without retroactively blocking past accounts from usage.

john wrote:

Currently modifying SpamBlacklist to support emails, this will be a separate blacklist.

[mid-air-collision]

(In reply to comment #9)

Ideally what we probably want, Is a method to disable signups from certain
domains to prevent future abuse without retroactively blocking past accounts
from usage.

Well we could just hook into isValidEmailAddr or EmailUser (There even seems to already be code in CommonSettings.php to block specific emails). But it appears mailenator has hundreds of alternate domains so I doubt that would block much.

Another approach might be to change the email validation method from click on a link (which just demonstrates user has access to email message) to hit reply to this message (Like how older style confirm-subscription-to-mailing-list works).

(In reply to comment #8)

But contacting blocking admins does not require the ability to send several
dozen identical emails to a user. And surely it would be possible to construct
a filter which would prevent emails from addresses such as "(User:x) is a dirty
Arab", "(User:y is a traitor to the Jewish people" or "Death to (User:z)" --
all of which I have encountered over recent months.

This quickly becomes an arms race. We could certainly check to see if many identical messages are sent out, but then troll could just change each message slightly. Filtering based on specific phrases generally is fairly easily defeatable (As spam email email teaches us with 10 billion different ways to misspell Viagra) More concerningly, it would be difficult to check for false postives - since emails are generally considered private. (Otoh, just because it becomes an arms race, doesn't neccesarily imply we shouldn't try)

Perhaps a good first approach would be to log sending of emails, and if someone with 0 edits sends over 100 emails, note it for further investigation.

As an aside, it appears a user is limited to sending 200 emails a day, and 100 per hour for non-autoconfirmed (via $wgRateLimits). Perhaps that limit should be further tweaked or something (but that doesn't really address the core issue, it just slows people down)

Non autoconfirmed users need email primarily to be able to handle the situation if/when they are blocked.

How about setting their usage to a small number (say two) emails per 24 hours? That should be enough to handle an unblock, yet make mass email abuse very clunky.

Dweller

Prodego wrote:

That sounds reasonable, but I'd go a little higher - 5 or 10 perhaps.

john wrote:

Implemented in r109455

rolandrance wrote:

Could you please explain exactly what has been implemented, what it will do, and how (if it all) we can improve its working.

john wrote:

I've implemented a blacklist similar to what the Spam-blacklist does, except this works off of emails. If the user has an email address that is in the blacklist, they will not be able to send emails, or register.

rolandrance wrote:

I'm not sure that would help much, since the offensive emails usually come from disposable one-time addresses at Mailinator. So they are unlikely to appear already in the blacklist, unless all Mailinator addresses are banned.

(In reply to comment #17)

I'm not sure that would help much, since the offensive emails usually come from
disposable one-time addresses at Mailinator. So they are unlikely to appear
already in the blacklist, unless all Mailinator addresses are banned.

Even banning all mailinator addresses would be insufficient, since they have hundreds of alternate domains (I suppose we could ban all alternate domains. Not sure how we'd get a list of them all though), See my previous comment 11.

and1eternal1 wrote:

If it uses regex, we could ban *.mailinator.com. Or is it the root domain that changes?

john wrote:

(In reply to comment #18)

(In reply to comment #17)

I'm not sure that would help much, since the offensive emails usually come from
disposable one-time addresses at Mailinator. So they are unlikely to appear
already in the blacklist, unless all Mailinator addresses are banned.

Even banning all mailinator addresses would be insufficient, since they have
hundreds of alternate domains (I suppose we could ban all alternate domains.
Not sure how we'd get a list of them all though), See my previous comment 11.

It's doable, at my last position managing a gaming forum we had a pretty exhaustive list that covered all of them. It's possible to do.

(In reply to comment #19)

If it uses regex, we could ban *.mailinator.com. Or is it the root domain that
changes?

No, it's the domain that changes.

rolandrance wrote:

Whatever has been done is clearly ineffective; I have received today a further 170+ abusive emails, from three different Wikipedia accounts, using two Mailinator addresses. The addresses were "(Username) will die" and "Kill traitor (real name)"; the contents were less pleasant than the names.

(In reply to comment #21)

Whatever has been done is clearly ineffective; I have received today a further
170+ abusive emails, from three different Wikipedia accounts, using two
Mailinator addresses. The addresses were "(Username) will die" and "Kill
traitor (real name)"; the contents were less pleasant than the names.

That would be because nothing has been done yet. John Du Hart wrote some code to make an email blacklist - but it is not yet in use.

john wrote:

(In reply to comment #21)

Whatever has been done is clearly ineffective; I have received today a further
170+ abusive emails, from three different Wikipedia accounts, using two
Mailinator addresses. The addresses were "(Username) will die" and "Kill
traitor (real name)"; the contents were less pleasant than the names.

In the meantime I'm building a blacklist of throwaway domain names. Can you please give me some of the domains used for spamming? Thank you.

rolandrance wrote:

(In reply to comment #23)

(In reply to comment #21)

Whatever has been done is clearly ineffective; I have received today a further
170+ abusive emails, from three different Wikipedia accounts, using two
Mailinator addresses. The addresses were "(Username) will die" and "Kill
traitor (real name)"; the contents were less pleasant than the names.

In the meantime I'm building a blacklist of throwaway domain names. Can you
please give me some of the domains used for spamming? Thank you.

Mailinator.com is the main one. There have been a few from gmail and Hotmail, but they deal with this as soon as it's reported. Mailinator don't.

(In reply to comment #22)

That would be because nothing has been done yet. John Du Hart wrote some code
to make an email blacklist - but it is not yet in use.

This was over 20 months ago, I assume the feature it working?
At any rate, lowering priority because since $wgRateLimits was made stricter I've seen no big complaints about email abuse.

See T45228: Have emails go through the AbuseFilter for a similar bug. You can block specific email addresses or domains from registering and/or sending email through https://en.wikipedia.org/wiki/MediaWiki:Email-blacklist. Despite being avalaible for some time now, I couldn't find any documentation on how to use it, so better be careful. Best regards.