Last modified: 2012-12-18 11:22:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9518, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7518 - More control over rate of user to user email sending (dynamical emailuser throttle or RateLimits)
More control over rate of user to user email sending (dynamical emailuser thr...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
https://gerrit.wikimedia.org/r/gitweb...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-07 20:24 UTC by Invalid Account
Modified: 2012-12-18 11:22 UTC (History)
8 users (show)

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


Attachments

Description Invalid Account 2006-10-07 20:24:20 UTC
A way to throttle how much email MediaWiki sends (certain site hosts limit how much mail an account can 
send per hour).  Or a way to selectively disable someone's ability to send mail so no one can send a 
mailbomb and mail doesn't have to be disabled for everyone to block one account.
Comment 1 Invalid Account 2006-12-17 12:19:56 UTC
Well it's clear no one was interested in this.

See: http://en.wikipedia.org/wiki/Wikipedia:Long_term_abuse/Universe_Daily

I will quote it. "Misuse of "Email this user" to mailbomb users (EG. User:Redvers getting 687 Emails 
with "POOFTER!!!" in them)."

Basically just a simple throttle will do. Or better yet, allow a CAPTCHA option--that would stop 
spammers and mailbomb programs both.
Comment 2 Rob Church 2006-12-17 14:57:18 UTC
(In reply to comment #1)
> Or better yet, allow a CAPTCHA option--that would stop 
> spammers and mailbomb programs both.

Not to mention the blind and partially-sighted.
Comment 3 Invalid Account 2006-12-17 15:55:31 UTC
They have auditory captchas.

On Wikia there are visual captchas all over.
Comment 4 Rob Church 2006-12-17 17:32:02 UTC
The bug started off requesting a means to disable a user's ability to send
email, and now we're talking about captchas.

Please decide what is actually required.
Comment 5 Invalid Account 2006-12-18 22:13:56 UTC
A mailbomb prevention.
Comment 6 Chad H. 2008-03-07 15:56:04 UTC
Is this still needed in light of being able to block Special:Emailuser?
Comment 7 Mike.lifeguard 2008-09-16 14:49:41 UTC
Unless we are prescient and know ahead of time that email will be abused, yes. Generally, we try not to block email unless needed, since that's a prime method to appeal blocks.
Comment 8 Rd232 2011-07-30 23:00:14 UTC
The issue with throttling is creating a potential DoS opportunity. Rate limiting just per sending account avoids that, but won't help much because it's so easy to create new accounts. A MediaWiki option to require a CAPTCHA may be the answer, but that requires resolution of Bug 4845 (CAPTCHA doesn't work for blind people).
Comment 9 Chad H. 2011-07-31 02:57:02 UTC
(In reply to comment #8)
> The issue with throttling is creating a potential DoS opportunity. Rate
> limiting just per sending account avoids that, but won't help much because it's
> so easy to create new accounts. A MediaWiki option to require a CAPTCHA may be
> the answer, but that requires resolution of Bug 4845 (CAPTCHA doesn't work for
> blind people).

Rate limiting would be fully sufficient here, since we also have rate limits on account creation too.
Comment 10 Rd232 2011-07-31 12:39:58 UTC
(In reply to comment #9)
> Rate limiting would be fully sufficient here, since we also have rate limits on
> account creation too.

What are those account creation limits? 6 in 24 hours? (See also Bug 25000). That might still allow for quite of bit email (6 x whatever-the-email-rate-limit-is). Besides, those limits are per IP, which limits their effectiveness.
Comment 11 Rich Farmbrough 2011-12-12 22:58:35 UTC
Yes, but if the throttle is fairly smart it can still be effective. Typically we are looking at accounts that have never sent an email sending many (>10) identical
emails, often to the same user.  While I suppose a successful bureaucrat candidate might receive several messages just saying "Congratulations", in general they will be from different users over a period of days.  So a day-zero (i.e. the first time an account sends email) throttle of half a dozen emails seems a fairly good starting point.  That is only 36 per IP per day, and the IP would be blocked by day two if it were static, and its socks hoovered up.  

Smartness can be added if someone is a known target, say they can only receive 1 per day per sender.  After mail number 1 genuine people can use standard email.

We can store an anonymous hash of the message to cut down on identical spammage/mailbombs.
Comment 12 Nemo 2012-12-18 11:04:48 UTC
Since this bug was filed, a throttle has been added for WMF wikis:

>                 // 100 emails per hour
>                 'emailuser' => array(
>                         'ip' => array( 100, 3600 ),
>                         'user' => array( 200, 86400 ),
>                 ),

I can't find the bug number though.

(In reply to comment #11)
> Yes, but if the throttle is fairly smart it can still be effective. [...]

I'm transforming this in a bug request for such a dynamical throttle, but I doubt it's ever going to happen, it's instructions creep; the normal RateLimits feature seems enough for all wikis including ours: I'm closing this, reopen if you have a proposal for something that you really thing is needed.
Comment 13 Kunal Mehta (Legoktm) 2012-12-18 11:09:22 UTC
I realize you just closed this, however the AbuseFilter would be able to set up these kinds of throttles if/when bug 43228 is resolved.
Comment 14 Nemo 2012-12-18 11:22:06 UTC
(In reply to comment #13)
> I realize you just closed this, however the AbuseFilter would be able to set
> up
> these kinds of throttles if/when bug 43228 is resolved.

Yes, I saw that bug and I was listing its siblings, but no the AbuseFilter wouldn't be able to do this, what Rich suggested is something like a softlimit below the hardlimit set by RateLimits, which would be something like "if the user in the last 24 h has sent five times the emails he sent in the last year, throttle new emails at X per day" or whatever.

This is IMHO a smarter proposal than bug 43228  but we still lack a concrete good proposal (I only made a random example) and I maintain that the current systems are better/enough. For instance one could greatly lower the current RateLimits, if this is a huge problem, and only allow sysop (or autopatrolled, or whatever) to send more emails than that by 'noratelimit' permission.

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


Navigation
Links