Page MenuHomePhabricator

Have emails go through the AbuseFilter
Open, LowestPublic

Description

Relevant thread: Wikipedia:Administrators'_noticeboard/Incidents#More_email_abuse

It should be possible to filter/disallow certain emails from being sent, using AF rules.

This could also cause some privacy issues since email log is restricted to CUs (as I understand it), however the contents of the email would be available to users with 'abusefilter-view-private'.


URL: https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&oldid=528619495#More_email_abuse
See Also:

Details

Reference
bz43228

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 12:54 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz43228.
bzimport added a subscriber: Unknown Object (MLST).

I've started working on an implementation, gerrit change #39536.

I see the benefits of having the Abuse Filter to review emails to avoid spam, for example. But I have several privacy concerns about this.

The contents of the email must not be avalaible for anybody because that will be egregiously unlawful in several jurisdictions. If a user receives an abusive email and feels concerned enough about its content, the user should contact the Police or fill a lawsuit against the sender.

Please note that CheckUser results indeed do tell us that User:X has sent an email, but we can't know to which user sent it (the recipient name is encrypted with a hash), nor the contents of such email.

Regards.

Per above, suggesting WONTFIX.

I can see the points raised... maybe this could/ should go into a separate extension?

You could take a look at how ArticleFeedbackv5 does its AF integration as a reference. Furthermore we nowadays have a reasonable amount of hooks in AF you could make use of.

(In reply to comment #4)

You could take a look at how ArticleFeedbackv5 does its AF integration as a
reference. Furthermore we nowadays have a reasonable amount of hooks in AF
you could make use of.

I'm not sure I understand the comparison to ArticleFeedbackv5 here. As I understand it, AFTv5 still exposes and stores the attempted submitted feedback. For example, https://en.wikipedia.org/wiki/Special:AbuseFilter/examine/log/8253191 was an attempted disallowed feedback post. The new_wikitext variable holds the attempted feedback: "Yessum\nGive more poop".

The issue here is that storing the attempted submission (in a public or private filter) would violate user privacy in an unacceptable manner.

(In reply to comment #3)

Per above, suggesting WONTFIX.

I completely disagree. If you look at the WIP patch I submitted, there is a variable called $wgAbuseFilterCheckEmails which is default set to false. Unless that is enabled, emails aren't filtered.

Marco's comments are completely valid, however that should affect whether the change is enabled on Wikimedia wikis. (Looking at it now, there are probably enough legal and privacy hurdles that this may never happen.) This feature may be useful for other non-WMF wikis, and is a reason to continue development.

(In reply to comment #2)

The contents of the email must not be avalaible for anybody because that will
be egregiously unlawful in several jurisdictions. If a user receives an
abusive
email and feels concerned enough about its content, the user should contact
the
Police or fill a lawsuit against the sender.

Right. In my patch I added another configuration variable, $wgAbuseFilterCheckEmailText, which would enable the filter to check against the subject line and email body.
Even without the text information, it would still be able to set up an effective filter using throttles. Something like "user_blocked & email_to rlike "userwhokeepsgettingabusiveLTAemails"" with a lower throttle than the MediaWiki default would be useful in my eyes.

Please note that CheckUser results indeed do tell us that User:X has sent an
email, but we can't know to which user sent it (the recipient name is
encrypted
with a hash), nor the contents of such email.

Regards.

One way around this (potentially) would be rather than revealing the recipients name, you could simply add a variable with the recipient's username hashed. This would still allow you to do what I mentioned above since you can calculate the hash beforehand.

(In reply to comment #5)

(In reply to comment #4)

You could take a look at how ArticleFeedbackv5 does its AF integration as a
reference. Furthermore we nowadays have a reasonable amount of hooks in AF
you could make use of.

I'm not sure I understand the comparison to ArticleFeedbackv5 here. As I
understand it, AFTv5 still exposes and stores the attempted submitted
feedback.

Yes, but my idea behind that was to not have this functionally in the WMF deployed AbuseFilter. Furthermore doing it like the ArticleFeedbackv5 extension does would allow us to not log the action at all or only log it partly (without having to cripple the AbuseFilter class even more)

Change 39536 abandoned by Legoktm:
(bug 43228) WIP Add AbuseFilter hook for Special:EmailUser

Reason:
Will move into a separate extension when I get the time.

https://gerrit.wikimedia.org/r/39536

Lego: should this still be assigned to you?

(In reply to comment #9)

Lego: should this still be assigned to you?

Probably not.

Just noting per T198057 (good merge!) - could we not filter against the action of emailing?

I'm sure somewhere there is a throttle for Special:EmailUser which hopefully prevents mass email attacks (that being said, I got 100+ over the course of an evening a couple of days ago from a few LTA socks), but having the action available to filter against could be helpful in the prevention of abuse.

E.g.

action == 'email' &
accountname irlike "badregex"

Filtering the action is the point of this task :-) However, together with the action, we must also compute some variables for that action. We may limit the list of such variables to a really tiny amount of more "neutral" vars, if that helps overcoming the privacy concerns.