Last modified: 2014-01-06 06:23:23 UTC
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'.
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.
