Last modified: 2012-12-18 11:22:06 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.
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.
(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.
They have auditory captchas. On Wikia there are visual captchas all over.
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.
A mailbomb prevention.
Is this still needed in light of being able to block Special:Emailuser?
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.
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).
(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.
(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.
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.
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.
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.
(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.
