Last modified: 2012-12-18 11:09:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7997 - Flag to prevent blocked users from sending email via Special:Emailuser
Flag to prevent blocked users from sending email via Special:Emailuser
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 10078 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-20 18:06 UTC by Mark Pellegrini
Modified: 2012-12-18 11:09 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Something to do the job ... (9.17 KB, patch)
2007-06-07 05:21 UTC, Daniel Cannon (AmiDaniel)
Details

Description Mark Pellegrini 2006-11-20 18:06:45 UTC
Blocked users have taken to spamming dozens and possibly hundreds of admins,
requesting to be unblocked. While this has always been true to some extent,
lately it has been happening with increasing frequency. It generates a great
deal of confusion for admins (to get emails from users they have had no contact
with, asking to be unblocked), and the blocking admin receives dozens of
messages from other admins asking why he blocked a particular user. 

At block time, a blocking admin should have the option of disabling the blocked
user's ability to send emails through the email-this-user function. More
importantly, Mediawiki should also have a throttle setting, (so that the feature
cannot be used more than X times per hour, for example). This won't stop the
abuse, but it will make it significantly more difficult.
Comment 1 NSLE/Chacor 2006-11-27 16:08:11 UTC
Hmm... so what about blocked users with talk pages protected trying to initiate
Arb cases? Don't those normally start through email? Plus, currently
[[MediaWiki:Blockedtext]] encourages the use of email directly to the blocking
admin to solve blocks (it also suggest the use of the unblock-en-l list). This
has the potential for abuse by admins, too.
Comment 2 Mark Pellegrini 2006-11-27 16:18:30 UTC
(1) The arbcom doesn't take cases of clearcut problem users (anymore). If a user
is blocked, it's usually for good reason. So the arbcom will rarely intervene if
one of the parties is already blocked. (2) I trust the administrators not to
abuse this a heck of a lot more than I trust the people they are blocking not to
abuse it. 
Comment 3 MacGyverMagic 2006-11-27 16:59:39 UTC
Occasionally a user is blocked by mistake and when the admin in question blocks 
emails from this user, they have no way to appeal. I prefer a throttle.
Comment 4 Connor Lee 2006-11-28 02:41:53 UTC
ditto Mgm, there should be a throttle of some sort
Comment 5 Mark Pellegrini 2007-06-07 02:19:56 UTC
*** Bug 10078 has been marked as a duplicate of this bug. ***
Comment 6 Ryulong 2007-06-07 02:24:36 UTC
Can we impliment it yet? The spam I've gotten from one user has exceeded 1000 total e-mails from his accounts. I wouldn't care if a throttle or if a block feature is implimented entirely. The idiot I have has been doing 100 at one sitting on his 30 or so accounts now.
Comment 7 Daniel Cannon (AmiDaniel) 2007-06-07 05:21:45 UTC
Created attachment 3731 [details]
Something to do the job ...

This should do what is needed--it will enable sysops to block users from sending e-mail if $wgSysopEmailBans is true. By default this value is false. As such, we can very easily enable the blocking of e-mail on Wikipedia, while sparing those smaller wikis where it may be more prone to abuse.

I'm hesitant in committing it right away, however, and will only do so if there is agreement to. It's been tested, but not particularly thoroughly, so if someone would like to test it in more depth, that would be nice :).

I also have this running at https://amidaniel.com/testwiki if anyone wants to play with it.
Comment 8 Daniel Cannon (AmiDaniel) 2007-06-07 17:32:36 UTC
Talked with Tim Starling and, having implemented his recommended changes, have committed this as r22816.
Comment 9 Mark Pellegrini 2007-06-08 00:25:22 UTC
From your description, it looks like the new patch allows a blocking admin to prevent the blocked user from sending emails. (The first half of my original feature request)  

But (and correct me if I'm mistaken) it won't help in Ryulong's case, where the emails are being sent from throw-away accounts. We also need rate email rate limiting (e.g, a user can send no more than X emails per day; or, alternatively, a user cannot receive more than Y emails per day).  
Comment 10 Ryulong 2007-06-09 00:46:12 UTC
They're not really throw away accounts. They're the accounts of one massive sockpuppeteer that I managed to piss off by blocking what he considered his "good hand" account. Although this is off topic.
Comment 11 Daniel Cannon (AmiDaniel) 2007-06-09 00:53:07 UTC
(In reply to comment #9)
> From your description, it looks like the new patch allows a blocking admin to
> prevent the blocked user from sending emails. (The first half of my original
> feature request)  
> 
> But (and correct me if I'm mistaken) it won't help in Ryulong's case, where the
> emails are being sent from throw-away accounts. We also need rate email rate
> limiting (e.g, a user can send no more than X emails per day; or,
> alternatively, a user cannot receive more than Y emails per day).  
> 

Please open a new bug for the throttle if you think it necessary. 

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links