Bug 794792 and bug 904647 are examples of trying to block ip addresses of bugzilla spammers after the fact. There was some discussion of blocking the normal 'commercial spammers' using DNS block lists in bug 536110. In bug 536110 there were suggestions that either a firewall or webserver were the more appropriate places to actually block the ip addresses. I have no opinion about that, but believe bugzilla could do more to help identify abusive users and feed their ip addresses into a block list. 1. Introduce a new resolution SPAM. 2. When a bug is marked as spam, the ip address is recorded in a block list. We may wish to count the number of times an ip address has submitted a SPAM bug and gate on a threshold. 3. If a user with an ip address on the block list attempts to access bugzilla, they are directed to a page which explains that their ip address has been blocked for spamming and detailing an appeals process whereby they can get their ip address unblocked. 4. If many ip addresses from a netblock are found to be the source of spam, the entire netblock would be blocked. There is potential for abuse of this so we would need to: * make sure that some netblocks would be protected from blocking. * limit the access to a subset of users. editbugs permissions might not be a sufficient subset but administrative rights might be sufficient. Many spam bugs are filed as security sensitive and users with access to security sensitive bugs could be trusted when setting the SPAM resolution. It might be more reasonable to allow anyone to set the SPAM resolution but only put the ip address of the user on the block list if the bug is verified by a user with sufficient permission. SPAM bugs are a continuing annoyance and serve as a possible DOS especially for security sensitive bugs.

One problem: IP addresses are not stored in the DB. They are only associated with the login cookies and are deleted once the user logs out. We could easily record the IP address, but then you would have to do it when editing bugs too, as it's IMO much more problematic when a spammer comments on hundreds bugs at once, polluting valid bugs. Another problem: with the Bugzilla API (XML-RPC, JSON-RPC or REST), it's very easy to file tens or hundreds of bugs at once, giving you no chance to block the IP address on time. And with tools like Tor, you could easily change your IP address between two attacks. This means that you need a proactive technique rather than being reactive. Maybe Bugzilla should detect when several bug reports come from the same IP address within a given time frame, and maybe start to moderate them (refuse more than X reports in N minutes), but this would give false positives when the same IP address is used by several users, such as the IP address of the MoCo office. Not sure what the best approach is.

(In reply to Frédéric Buclin from comment #1) > Maybe Bugzilla should detect when several bug reports come from the same IP > address within a given time frame, and maybe start to moderate them (refuse > more than X reports in N minutes) FYI, that's bug 704753.

Is bugzilla spam a daily thing? Does it happen often? Making these changes might not be worth it if it is just a small annoyance a few times a week or month?

fairly close to a daily thing. definitely several times a week. over time the annoyance factor grows as it keeps happening over and over. I worry also that we could suffer a DOS through a large number of these bug reports from people who have a animosity towards the project.

this is a hard nut to crack. we can't rate limit based on source ip address, because that is detrimental to users behind NAT or proxy servers (proxy servers are much more common outside of the US). adding a capatcha or similar won't stop the flow, because these aren't automated reports - they appear to be misguided trainers using bugzilla.mozilla.org in their course-ware. adding warnings won't work -- they already click past multiple warnings. what has worked is we were able to contact a professor at a university who taught a course which were using bmo, and we directed him to a more appropriate system. bc, the best thing you can do right now is file bugs with each new wave (drop them into the bmo product). we can then at least trace the IP addresses and block repeat offenders, and it gives us a real idea of the frequency of these events. currently we've not being told when it happens.