Re: Spam-Attack on Bugzilla
Am 18.04.20 um 22:58 schrieb B. Ruth Deerfield: Unsure what email address I was using: p...@earthlink.net brdfri...@icloud.com bruthdeerfi...@gmail.com deerborn.r...@gmail.com I've checked all mail addresses but haven't found an user account; even not disabled. When you have double-checked your data and have maybe found more possible user accounts, you can reset you password yourself with the function on: https://bz.apache.org/ooo/ HTH Marcus On Apr 18, 2020, at 3:47 AM, Marcus wrote: Am 18.04.20 um 11:33 schrieb Matthias Seidel: Am 12.04.20 um 19:25 schrieb Marcus: Am 12.04.20 um 15:12 schrieb Carl Marcum: I would +1 to accounts upon request. OK, this was not an option I was thinking about as it would install a hurdle for the users. ;-) However, for the moment this could be an valueable option, so I've disabled the self-registration feature in BZ. When there are reasons not to do so, it's easy and fast to revert this. Are existing users (non LDAP) still able to log in? I have one user that complains he can't, but I am not sure if it really is the case... can you mail me the user name (by private mail)? Then I'll check if it's diabled, or if I can reset the password etc. Thanks Marcus On 4/12/20 6:05 AM, Peter Kovacs wrote: since we use it as developer tool only, I agree. Am 12.04.20 um 12:02 schrieb Matthias Seidel: Am 10.04.20 um 22:38 schrieb Marcus: Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... I've disabled all these user accounts. But IMHO there is nothing else we can do. Even with a capture it's not impossible to create an user account for spaming. Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
Unsure what email address I was using: p...@earthlink.net brdfri...@icloud.com bruthdeerfi...@gmail.com deerborn.r...@gmail.com Sent from my iPhone > On Apr 18, 2020, at 3:47 AM, Marcus wrote: > > Am 18.04.20 um 11:33 schrieb Matthias Seidel: >>> Am 12.04.20 um 19:25 schrieb Marcus: >>> Am 12.04.20 um 15:12 schrieb Carl Marcum: I would +1 to accounts upon request. >>> >>> OK, this was not an option I was thinking about as it would install a >>> hurdle for the users. ;-) >>> >>> However, for the moment this could be an valueable option, so I've >>> disabled the self-registration feature in BZ. >>> >>> When there are reasons not to do so, it's easy and fast to revert this. >> Are existing users (non LDAP) still able to log in? >> I have one user that complains he can't, but I am not sure if it really >> is the case... > > can you mail me the user name (by private mail)? Then I'll check if it's > diabled, or if I can reset the password etc. > > Thanks > > Marcus > > > On 4/12/20 6:05 AM, Peter Kovacs wrote: > since we use it as developer tool only, I agree. > > Am 12.04.20 um 12:02 schrieb Matthias Seidel: >> Am 10.04.20 um 22:38 schrieb Marcus: >>> Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... >>> I've disabled all these user accounts. >>> >>> But IMHO there is nothing else we can do. Even with a capture it's >>> not >>> impossible to create an user account for spaming. >>> >>> Or is there something new I don't know yet? >> Nothing that I know of... >> >> But we should think about creating Bugzilla account only on request >> (like for Pootle). >> Given the amount of SPAM and many end user questions flooding our bug >> tracking system this would help a lot. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
Hi Marcus, Am 18.04.20 um 12:47 schrieb Marcus: > Am 18.04.20 um 11:33 schrieb Matthias Seidel: >> Am 12.04.20 um 19:25 schrieb Marcus: >>> Am 12.04.20 um 15:12 schrieb Carl Marcum: I would +1 to accounts upon request. >>> >>> OK, this was not an option I was thinking about as it would install a >>> hurdle for the users. ;-) >>> >>> However, for the moment this could be an valueable option, so I've >>> disabled the self-registration feature in BZ. >>> >>> When there are reasons not to do so, it's easy and fast to revert this. >> >> Are existing users (non LDAP) still able to log in? >> >> I have one user that complains he can't, but I am not sure if it really >> is the case... > > can you mail me the user name (by private mail)? Then I'll check if > it's diabled, or if I can reset the password etc. Done! Matthias > > Thanks > > Marcus > > > On 4/12/20 6:05 AM, Peter Kovacs wrote: > since we use it as developer tool only, I agree. > > Am 12.04.20 um 12:02 schrieb Matthias Seidel: >> Am 10.04.20 um 22:38 schrieb Marcus: >>> Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... >>> I've disabled all these user accounts. >>> >>> But IMHO there is nothing else we can do. Even with a capture it's >>> not >>> impossible to create an user account for spaming. >>> >>> Or is there something new I don't know yet? >> Nothing that I know of... >> >> But we should think about creating Bugzilla account only on request >> (like for Pootle). >> Given the amount of SPAM and many end user questions flooding our >> bug >> tracking system this would help a lot. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: Spam-Attack on Bugzilla
Am 18.04.20 um 11:33 schrieb Matthias Seidel: Am 12.04.20 um 19:25 schrieb Marcus: Am 12.04.20 um 15:12 schrieb Carl Marcum: I would +1 to accounts upon request. OK, this was not an option I was thinking about as it would install a hurdle for the users. ;-) However, for the moment this could be an valueable option, so I've disabled the self-registration feature in BZ. When there are reasons not to do so, it's easy and fast to revert this. Are existing users (non LDAP) still able to log in? I have one user that complains he can't, but I am not sure if it really is the case... can you mail me the user name (by private mail)? Then I'll check if it's diabled, or if I can reset the password etc. Thanks Marcus On 4/12/20 6:05 AM, Peter Kovacs wrote: since we use it as developer tool only, I agree. Am 12.04.20 um 12:02 schrieb Matthias Seidel: Am 10.04.20 um 22:38 schrieb Marcus: Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... I've disabled all these user accounts. But IMHO there is nothing else we can do. Even with a capture it's not impossible to create an user account for spaming. Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
Hi Pedro, Am 18.04.20 um 11:54 schrieb Pedro Lino: > Hi Mathias > >> Are existing users (non LDAP) still able to log in? > I am able to log in and use Bugzilla as usual (I have no idea what LDAP is, > but I think I don't have it?) Thanks (also to David)! LDAP [1] is when you can log in with your ASF ID. That requires at least ASF committer status. Otherwise you have a manually created account. Regards, Matthias [1] https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol > > Regards, > Pedro > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: Spam-Attack on Bugzilla
Hi Mathias > Are existing users (non LDAP) still able to log in? I am able to log in and use Bugzilla as usual (I have no idea what LDAP is, but I think I don't have it?) Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
On 18/4/20 7:03 pm, Matthias Seidel wrote: Hi Marcus, Am 12.04.20 um 19:25 schrieb Marcus: Am 12.04.20 um 15:12 schrieb Carl Marcum: I would +1 to accounts upon request. OK, this was not an option I was thinking about as it would install a hurdle for the users. ;-) However, for the moment this could be an valueable option, so I've disabled the self-registration feature in BZ. When there are reasons not to do so, it's easy and fast to revert this. Are existing users (non LDAP) still able to log in? I have one user that complains he can't, but I am not sure if it really is the case... Regards, Matthias FYI I can log in - just tested a few moments ago. Cheers -- David Robley I'm an incorrigible punster, so don't corrige me! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
Hi Marcus, Am 12.04.20 um 19:25 schrieb Marcus: > Am 12.04.20 um 15:12 schrieb Carl Marcum: >> I would +1 to accounts upon request. > > OK, this was not an option I was thinking about as it would install a > hurdle for the users. ;-) > > However, for the moment this could be an valueable option, so I've > disabled the self-registration feature in BZ. > > When there are reasons not to do so, it's easy and fast to revert this. Are existing users (non LDAP) still able to log in? I have one user that complains he can't, but I am not sure if it really is the case... Regards, Matthias > > Marcus > > > >> On 4/12/20 6:05 AM, Peter Kovacs wrote: >>> since we use it as developer tool only, I agree. >>> >>> Am 12.04.20 um 12:02 schrieb Matthias Seidel: Am 10.04.20 um 22:38 schrieb Marcus: > Am 10.04.20 um 19:27 schrieb Matthias Seidel: >> https://bz.apache.org/ooo/show_bug.cgi?id=17086 >> >> Is there anything we can do about this? >> >> At least we should block these users... > I've disabled all these user accounts. > > But IMHO there is nothing else we can do. Even with a capture it's > not > impossible to create an user account for spaming. > > Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > smime.p7s Description: S/MIME Cryptographic Signature
Re: Spam-Attack on Bugzilla
Am 12.04.20 um 15:12 schrieb Carl Marcum: I would +1 to accounts upon request. OK, this was not an option I was thinking about as it would install a hurdle for the users. ;-) However, for the moment this could be an valueable option, so I've disabled the self-registration feature in BZ. When there are reasons not to do so, it's easy and fast to revert this. Marcus On 4/12/20 6:05 AM, Peter Kovacs wrote: since we use it as developer tool only, I agree. Am 12.04.20 um 12:02 schrieb Matthias Seidel: Am 10.04.20 um 22:38 schrieb Marcus: Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... I've disabled all these user accounts. But IMHO there is nothing else we can do. Even with a capture it's not impossible to create an user account for spaming. Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
I would +1 to accounts upon request. Best regards, Carl On 4/12/20 6:05 AM, Peter Kovacs wrote: since we use it as developer tool only, I agree. Am 12.04.20 um 12:02 schrieb Matthias Seidel: Hi Marcus, Am 10.04.20 um 22:38 schrieb Marcus: Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... I've disabled all these user accounts. But IMHO there is nothing else we can do. Even with a capture it's not impossible to create an user account for spaming. Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. Matthias Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
On Sun, 12 Apr 2020 12:05:17 +0200 Peter Kovacs wrote: > since we use it as developer tool only, I agree. > > Am 12.04.20 um 12:02 schrieb Matthias Seidel: > > Hi Marcus, > > > > Am 10.04.20 um 22:38 schrieb Marcus: > >> Am 10.04.20 um 19:27 schrieb Matthias Seidel: > >>> https://bz.apache.org/ooo/show_bug.cgi?id=17086 > >>> > >>> Is there anything we can do about this? > >>> > >>> At least we should block these users... > >> I've disabled all these user accounts. > >> > >> But IMHO there is nothing else we can do. Even with a capture it's not > >> impossible to create an user account for spaming. > >> > >> Or is there something new I don't know yet? > > Nothing that I know of... > > > > But we should think about creating Bugzilla account only on request > > (like for Pootle). > > Given the amount of SPAM and many end user questions flooding our bug > > tracking system this would help a lot. > > > > Matthias > > > >> Marcus On en-Forum all first postings have to be approved by a moderator; this gives prompt assessment and removal of obvious spam. Some spammers will make a number of trivial replies or replies with meaningful information, often unattributed text from other sources, so their information looks OK, then subsequently edit their messages to insert spam; we usually catch these fairly promptly. -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
since we use it as developer tool only, I agree. Am 12.04.20 um 12:02 schrieb Matthias Seidel: Hi Marcus, Am 10.04.20 um 22:38 schrieb Marcus: Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... I've disabled all these user accounts. But IMHO there is nothing else we can do. Even with a capture it's not impossible to create an user account for spaming. Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. Matthias Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam-Attack on Bugzilla
Hi Marcus, Am 10.04.20 um 22:38 schrieb Marcus: > Am 10.04.20 um 19:27 schrieb Matthias Seidel: >> https://bz.apache.org/ooo/show_bug.cgi?id=17086 >> >> Is there anything we can do about this? >> >> At least we should block these users... > > I've disabled all these user accounts. > > But IMHO there is nothing else we can do. Even with a capture it's not > impossible to create an user account for spaming. > > Or is there something new I don't know yet? Nothing that I know of... But we should think about creating Bugzilla account only on request (like for Pootle). Given the amount of SPAM and many end user questions flooding our bug tracking system this would help a lot. Matthias > > Marcus > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > smime.p7s Description: S/MIME Cryptographic Signature
Re: Spam-Attack on Bugzilla
Am 10.04.20 um 19:27 schrieb Matthias Seidel: https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... I've disabled all these user accounts. But IMHO there is nothing else we can do. Even with a capture it's not impossible to create an user account for spaming. Or is there something new I don't know yet? Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Spam-Attack on Bugzilla
https://bz.apache.org/ooo/show_bug.cgi?id=17086 Is there anything we can do about this? At least we should block these users... Regards, Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: [Mwiki] a massive spam attack. Again
Am 02/07/2014 12:45 AM, schrieb Rob Weir: On Thu, Feb 6, 2014 at 6:21 PM, jan i wrote: On 6 February 2014 23:42, Andrea Pescetti wrote: jan i wrote: I warned about exactly that, but I was asked (see JIRAs) to remove the cats (captcha). If you read the JIRA (which was watched be several in here) you will see my warning. The idea was to replace the CAPTCHA with something better, otherwise we can (should) keep the current CAPTCHA and discuss a better solution in the meantime. The cats cause incompatibilities and other issues, but if they are much more effective than the replacement let's go back to the cats as soon as possible and in the "see what's best to replace them (but something MORE effective, not LESS effective!). May I politely correct you, the idea was NOT to replace the cats. The jira was implemented by the word ! The exact wording is: "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It doesn't work in several browser configurations, it includes HTTP instead of HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended solution: drop it entirely. " That statement is pretty clear, how it can be read as moving to something more effective slips my mind. later the jira contains: "accessibility suggestion from Tyler (haven't tested MediaWiki compatibility): there is a website which provides text-based CAPTCHA's in the form of logic questions, math problems, etc. It provides an XML API. See http://www.textcaptcha.com/ " Apart from the facts, thats its a suggestion and not a decision (like that above), we do not use extensions that are not supported by mediawiki (meaning downloadable from mediawiki.com and verified for our release). As a sidenote, that captcha is pretty much the same as the standard which are active right now. There are quite a lot of captcha´s out there, just looking at mediawiki.com extensions gives a lot of choises. At this point in time we have several choices: 1) leave the config as it is 2) reinstall cats 3) choose another captcha (in this case we need to decide which one). I am not the one to overrule a community decision (Wiki6), but I will happely implement another community decision. I hope you can simply restore cats if that can be done without too much trouble. Then we can discuss further and come to a community decision on what else to do, if anything. I hope you agree that there is zero benefit to accumulating additional spam while we discuss. Fix the immediate problem, then we can discuss longer term. This one area that Apache Infra knows how to do well. They know when it is important to act rather than discuss. I suggest that this is one of those times. Right, especially when there is already a solution that is working (mostly resp. for the most people). Thanks Jan. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
On 7 February 2014 08:48, Andrea Pescetti wrote: > On 07/02/2014 jan i wrote: > >> May I politely correct you, the idea was NOT to replace the cats. The jira >> was implemented by the word ! >> > > Yes, probably, but it was badly written in my mail that was then copied to > JIRA. You, and a few others, know that the contents of that JIRA issue > https://issues.apache.org/jira/browse/INFRA-7173 > result from an afternoon I spent during the holidays trying to put > together all pending improvement suggestions that had come to us through > many channels. I didn't take care to put many explanations there. > > > "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It >> doesn't work in several browser configurations, it includes HTTP instead >> of >> HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended >> solution: drop it entirely. " >> > > That specific suggestion was worded that way because I had read from > someone (you, maybe?) that with the new improvements there could (just a > possibility) be the possibility to do without the CAPTCHA. We tried, it > didn't work and it's no problem to fix it immediately. > > > That statement is pretty clear, how it can be read as moving to something >> more effective slips my mind. >> > > I wrote it in a wrong way giving somehow for granted that the MWiki > upgrade would feature some native anti-spam measures and that those > measures would suit our purpose. Again, we tried, they didn't, no problem > to revert quickly. > > > At this point in time we have several choices: >> 1) leave the config as it is >> 2) reinstall cats >> 3) choose another captcha (in this case we need to decide which one). >> I am not the one to overrule a community decision (Wiki6), but I will >> happely implement another community decision. >> > > The current remedy you put in place (no self account creation) will > obviously work for the time being, thanks for being fast in reacting. > > So let's move forward and see what we can implement now: where's the list > of CAPTCHA solutions on mediawiki.com? Do you have any recommendations > or, on the contrary, any extensions that Infra is not going to allow? > Anything found in http://www.mediawiki.org/wiki/Extension_Matrix/AllExtensions where "mediawiki version" allows 1.22 should do. Especially for CAPTCHA there is one other limitation. The extension must be self supported, NO calls to third party sites (since this is often used to collect information). rgds jan I. (By the way, the CAPTCHA issue exploded before I could review all items, > but thank you for the work on all other pending issues! And let's get this > one done properly too) > > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [Mwiki] a massive spam attack. Again
On 07/02/2014 jan i wrote: May I politely correct you, the idea was NOT to replace the cats. The jira was implemented by the word ! Yes, probably, but it was badly written in my mail that was then copied to JIRA. You, and a few others, know that the contents of that JIRA issue https://issues.apache.org/jira/browse/INFRA-7173 result from an afternoon I spent during the holidays trying to put together all pending improvement suggestions that had come to us through many channels. I didn't take care to put many explanations there. "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It doesn't work in several browser configurations, it includes HTTP instead of HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended solution: drop it entirely. " That specific suggestion was worded that way because I had read from someone (you, maybe?) that with the new improvements there could (just a possibility) be the possibility to do without the CAPTCHA. We tried, it didn't work and it's no problem to fix it immediately. That statement is pretty clear, how it can be read as moving to something more effective slips my mind. I wrote it in a wrong way giving somehow for granted that the MWiki upgrade would feature some native anti-spam measures and that those measures would suit our purpose. Again, we tried, they didn't, no problem to revert quickly. At this point in time we have several choices: 1) leave the config as it is 2) reinstall cats 3) choose another captcha (in this case we need to decide which one). I am not the one to overrule a community decision (Wiki6), but I will happely implement another community decision. The current remedy you put in place (no self account creation) will obviously work for the time being, thanks for being fast in reacting. So let's move forward and see what we can implement now: where's the list of CAPTCHA solutions on mediawiki.com? Do you have any recommendations or, on the contrary, any extensions that Infra is not going to allow? (By the way, the CAPTCHA issue exploded before I could review all items, but thank you for the work on all other pending issues! And let's get this one done properly too) Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
2014-02-07 6:22 GMT+06:00 jan i : > > > The configuration is changed so that only sysops can create new accounts. > A lot of thank you, Jan! You are our savior. For last 48 hours 3 wiki admins have deleted more than 1300 spam pages and blocked more than 800 spammer accounts. -- WBR, Helen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
Hi - The JIRA is quoted but links or the JIRA ID would be helpful along with a link to the ML thread where the decision was made. It is hard to review this incident without these helpful pointers. Thanks, Dave On Feb 6, 2014, at 4:22 PM, jan i wrote: > On 7 February 2014 00:45, Rob Weir wrote: > >> On Thu, Feb 6, 2014 at 6:21 PM, jan i wrote: >>> On 6 February 2014 23:42, Andrea Pescetti wrote: >>> jan i wrote: > I warned about exactly that, but I was asked (see JIRAs) to remove the > cats (captcha). If you read the JIRA (which was watched be several in > here) > you will see my warning. > The idea was to replace the CAPTCHA with something better, otherwise we can (should) keep the current CAPTCHA and discuss a better solution in >> the meantime. The cats cause incompatibilities and other issues, but if they are much more effective than the replacement let's go back to the cats as soon as possible and in the "see what's best to replace them (but something MORE effective, not LESS effective!). >>> >>> May I politely correct you, the idea was NOT to replace the cats. The >> jira >>> was implemented by the word ! >>> >>> The exact wording is: >>> >>> "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It >>> doesn't work in several browser configurations, it includes HTTP instead >> of >>> HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> >> Recommended >>> solution: drop it entirely. " >>> >>> That statement is pretty clear, how it can be read as moving to something >>> more effective slips my mind. >>> >>> later the jira contains: >>> >>> "accessibility suggestion from Tyler (haven't tested MediaWiki >>> compatibility): there is a website which provides text-based CAPTCHA's in >>> the form of logic questions, math problems, etc. It provides an XML API. >>> See http://www.textcaptcha.com/ " >>> >>> Apart from the facts, thats its a suggestion and not a decision (like >> that >>> above), we do not use extensions that are not supported by mediawiki >>> (meaning downloadable from mediawiki.com and verified for our release). >> As >>> a sidenote, that captcha is pretty much the same as the standard which >> are >>> active right now. There are quite a lot of captcha´s out there, just >>> looking at mediawiki.com extensions gives a lot of choises. >>> >>> At this point in time we have several choices: >>> 1) leave the config as it is >>> 2) reinstall cats >>> 3) choose another captcha (in this case we need to decide which one). >>> >>> I am not the one to overrule a community decision (Wiki6), but I will >>> happely implement another community decision. >>> >> >> I hope you can simply restore cats if that can be done without too >> much trouble. Then we can discuss further and come to a community >> decision on what else to do, if anything. I hope you agree that there >> is zero benefit to accumulating additional spam while we discuss. >> > > Wiki have been upgraded, and respecting the jira I did not move the cat > extension. > > >> Fix the immediate problem, then we can discuss longer term. This one >> area that Apache Infra knows how to do well. They know when it is >> important to act rather than discuss. I suggest that this is one of >> those times. >> > > I happen to agree with you, and it has actually not been possible to create > new accounts for a while now. > > The configuration is changed so that only sysops can create new accounts. > > Now to the other partwe have discussed these issues for quite a long > time, so it was a fair assumption to accept the jira as the community wish. > > >> >> Thanks! >> >> -Rob >> >>> rgds >>> jan I. >>> >>> >>> >>> >>> Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
On 7 February 2014 00:45, Rob Weir wrote: > On Thu, Feb 6, 2014 at 6:21 PM, jan i wrote: > > On 6 February 2014 23:42, Andrea Pescetti wrote: > > > >> jan i wrote: > >> > >>> I warned about exactly that, but I was asked (see JIRAs) to remove the > >>> cats (captcha). If you read the JIRA (which was watched be several in > >>> here) > >>> you will see my warning. > >>> > >> > >> The idea was to replace the CAPTCHA with something better, otherwise we > >> can (should) keep the current CAPTCHA and discuss a better solution in > the > >> meantime. > >> > >> The cats cause incompatibilities and other issues, but if they are much > >> more effective than the replacement let's go back to the cats as soon as > >> possible and in the "see what's best to replace them (but something MORE > >> effective, not LESS effective!). > >> > > > > May I politely correct you, the idea was NOT to replace the cats. The > jira > > was implemented by the word ! > > > > The exact wording is: > > > > "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It > > doesn't work in several browser configurations, it includes HTTP instead > of > > HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> > Recommended > > solution: drop it entirely. " > > > > That statement is pretty clear, how it can be read as moving to something > > more effective slips my mind. > > > > later the jira contains: > > > > "accessibility suggestion from Tyler (haven't tested MediaWiki > > compatibility): there is a website which provides text-based CAPTCHA's in > > the form of logic questions, math problems, etc. It provides an XML API. > > See http://www.textcaptcha.com/ " > > > > Apart from the facts, thats its a suggestion and not a decision (like > that > > above), we do not use extensions that are not supported by mediawiki > > (meaning downloadable from mediawiki.com and verified for our release). > As > > a sidenote, that captcha is pretty much the same as the standard which > are > > active right now. There are quite a lot of captcha´s out there, just > > looking at mediawiki.com extensions gives a lot of choises. > > > > At this point in time we have several choices: > > 1) leave the config as it is > > 2) reinstall cats > > 3) choose another captcha (in this case we need to decide which one). > > > > I am not the one to overrule a community decision (Wiki6), but I will > > happely implement another community decision. > > > > I hope you can simply restore cats if that can be done without too > much trouble. Then we can discuss further and come to a community > decision on what else to do, if anything. I hope you agree that there > is zero benefit to accumulating additional spam while we discuss. > Wiki have been upgraded, and respecting the jira I did not move the cat extension. > Fix the immediate problem, then we can discuss longer term. This one > area that Apache Infra knows how to do well. They know when it is > important to act rather than discuss. I suggest that this is one of > those times. > I happen to agree with you, and it has actually not been possible to create new accounts for a while now. The configuration is changed so that only sysops can create new accounts. Now to the other partwe have discussed these issues for quite a long time, so it was a fair assumption to accept the jira as the community wish. > > Thanks! > > -Rob > > > rgds > > jan I. > > > > > > > > > > > >> Regards, > >> Andrea. > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [Mwiki] a massive spam attack. Again
On Thu, Feb 6, 2014 at 6:21 PM, jan i wrote: > On 6 February 2014 23:42, Andrea Pescetti wrote: > >> jan i wrote: >> >>> I warned about exactly that, but I was asked (see JIRAs) to remove the >>> cats (captcha). If you read the JIRA (which was watched be several in >>> here) >>> you will see my warning. >>> >> >> The idea was to replace the CAPTCHA with something better, otherwise we >> can (should) keep the current CAPTCHA and discuss a better solution in the >> meantime. >> >> The cats cause incompatibilities and other issues, but if they are much >> more effective than the replacement let's go back to the cats as soon as >> possible and in the "see what's best to replace them (but something MORE >> effective, not LESS effective!). >> > > May I politely correct you, the idea was NOT to replace the cats. The jira > was implemented by the word ! > > The exact wording is: > > "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It > doesn't work in several browser configurations, it includes HTTP instead of > HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended > solution: drop it entirely. " > > That statement is pretty clear, how it can be read as moving to something > more effective slips my mind. > > later the jira contains: > > "accessibility suggestion from Tyler (haven't tested MediaWiki > compatibility): there is a website which provides text-based CAPTCHA's in > the form of logic questions, math problems, etc. It provides an XML API. > See http://www.textcaptcha.com/ " > > Apart from the facts, thats its a suggestion and not a decision (like that > above), we do not use extensions that are not supported by mediawiki > (meaning downloadable from mediawiki.com and verified for our release). As > a sidenote, that captcha is pretty much the same as the standard which are > active right now. There are quite a lot of captcha´s out there, just > looking at mediawiki.com extensions gives a lot of choises. > > At this point in time we have several choices: > 1) leave the config as it is > 2) reinstall cats > 3) choose another captcha (in this case we need to decide which one). > > I am not the one to overrule a community decision (Wiki6), but I will > happely implement another community decision. > I hope you can simply restore cats if that can be done without too much trouble. Then we can discuss further and come to a community decision on what else to do, if anything. I hope you agree that there is zero benefit to accumulating additional spam while we discuss. Fix the immediate problem, then we can discuss longer term. This one area that Apache Infra knows how to do well. They know when it is important to act rather than discuss. I suggest that this is one of those times. Thanks! -Rob > rgds > jan I. > > > > > >> Regards, >> Andrea. >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
On 6 February 2014 23:42, Andrea Pescetti wrote: > jan i wrote: > >> I warned about exactly that, but I was asked (see JIRAs) to remove the >> cats (captcha). If you read the JIRA (which was watched be several in >> here) >> you will see my warning. >> > > The idea was to replace the CAPTCHA with something better, otherwise we > can (should) keep the current CAPTCHA and discuss a better solution in the > meantime. > > The cats cause incompatibilities and other issues, but if they are much > more effective than the replacement let's go back to the cats as soon as > possible and in the "see what's best to replace them (but something MORE > effective, not LESS effective!). > May I politely correct you, the idea was NOT to replace the cats. The jira was implemented by the word ! The exact wording is: "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It doesn't work in several browser configurations, it includes HTTP instead of HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended solution: drop it entirely. " That statement is pretty clear, how it can be read as moving to something more effective slips my mind. later the jira contains: "accessibility suggestion from Tyler (haven't tested MediaWiki compatibility): there is a website which provides text-based CAPTCHA's in the form of logic questions, math problems, etc. It provides an XML API. See http://www.textcaptcha.com/ " Apart from the facts, thats its a suggestion and not a decision (like that above), we do not use extensions that are not supported by mediawiki (meaning downloadable from mediawiki.com and verified for our release). As a sidenote, that captcha is pretty much the same as the standard which are active right now. There are quite a lot of captcha´s out there, just looking at mediawiki.com extensions gives a lot of choises. At this point in time we have several choices: 1) leave the config as it is 2) reinstall cats 3) choose another captcha (in this case we need to decide which one). I am not the one to overrule a community decision (Wiki6), but I will happely implement another community decision. rgds jan I. > Regards, > Andrea. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [Mwiki] a massive spam attack. Again
jan i wrote: I warned about exactly that, but I was asked (see JIRAs) to remove the cats (captcha). If you read the JIRA (which was watched be several in here) you will see my warning. The idea was to replace the CAPTCHA with something better, otherwise we can (should) keep the current CAPTCHA and discuss a better solution in the meantime. The cats cause incompatibilities and other issues, but if they are much more effective than the replacement let's go back to the cats as soon as possible and in the meantime see what's best to replace them (but something MORE effective, not LESS effective!). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
On 6 February 2014 21:06, Rob Weir wrote: > On Thu, Feb 6, 2014 at 1:28 PM, jan i wrote: > > On 6 February 2014 19:00, helen wrote: > > > >> Hi there, > >> > >> I'm Helen, a Wi admin. > https://wiki.openoffice.org/wiki/User:Helen_russian > >> > >> Since 5th Feb. MWiki is under a massive spam attack. > >> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete, > >> https://wiki.openoffice.org/wiki/Special:Log/block > >> > > > > I warned about exactly that, but I was asked (see JIRAs) to remove the > > cats (captcha). If you read the JIRA (which was watched be several in > here) > > you will see my warning. > > > > The simple captcha we have in place, is browser safe, but not very > > efficient. I assume the admins as such wanted the change (otherwise I am > > sure the task would not have been added). > > > > Another captcha was suggested, but with the note "not tested on > mediawiki" > > (or something similar). We only install extensions supported by mediawiki > > of course. > > > > A simpler solution: Why not add back the "cat" captcha, but only show > it to the spammers? > > Regards, > > -Rob > > (OK. That is a joke. But I was once asked by a manager, many years > ago, to improve a spell checker so it only reported misspellings of > words that were in the dictionary.) > I am happy, someone can make a joke out of a self imposed spam attack. I am surely too serious in my work, but would much more ike to see a community agreed solution, before we end having all admins fight spam (just remember last time). rgds jan I. > > > If the admins wants a change, then please have a discussion about it on > the > > ML, and once agreed upon, file a JIRA. > > > > rgds > > jan I. > > > > > > Please help. > >> > >> -- > >> Regards, > >> Helen > >> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [Mwiki] a massive spam attack. Again
On Thu, Feb 6, 2014 at 12:06 PM, Rob Weir wrote: > On Thu, Feb 6, 2014 at 1:28 PM, jan i wrote: > > On 6 February 2014 19:00, helen wrote: > > > >> Hi there, > >> > >> I'm Helen, a Wi admin. > https://wiki.openoffice.org/wiki/User:Helen_russian > >> > >> Since 5th Feb. MWiki is under a massive spam attack. > >> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete, > >> https://wiki.openoffice.org/wiki/Special:Log/block > >> > > > > I warned about exactly that, but I was asked (see JIRAs) to remove the > > cats (captcha). If you read the JIRA (which was watched be several in > here) > > you will see my warning. > > > > The simple captcha we have in place, is browser safe, but not very > > efficient. I assume the admins as such wanted the change (otherwise I am > > sure the task would not have been added). > > > > Another captcha was suggested, but with the note "not tested on > mediawiki" > > (or something similar). We only install extensions supported by mediawiki > > of course. > > > > A simpler solution: Why not add back the "cat" captcha, but only show > it to the spammers? > LOL! > > Regards, > > -Rob > > (OK. That is a joke. But I was once asked by a manager, many years > ago, to improve a spell checker so it only reported misspellings of > words that were in the dictionary.) > > > > If the admins wants a change, then please have a discussion about it on > the > > ML, and once agreed upon, file a JIRA. > > > > rgds > > jan I. > > > > > > Please help. > >> > >> -- > >> Regards, > >> Helen > >> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- - MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
Re: [Mwiki] a massive spam attack. Again
On Thu, Feb 6, 2014 at 1:28 PM, jan i wrote: > On 6 February 2014 19:00, helen wrote: > >> Hi there, >> >> I'm Helen, a Wi admin. https://wiki.openoffice.org/wiki/User:Helen_russian >> >> Since 5th Feb. MWiki is under a massive spam attack. >> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete , >> https://wiki.openoffice.org/wiki/Special:Log/block >> > > I warned about exactly that, but I was asked (see JIRAs) to remove the > cats (captcha). If you read the JIRA (which was watched be several in here) > you will see my warning. > > The simple captcha we have in place, is browser safe, but not very > efficient. I assume the admins as such wanted the change (otherwise I am > sure the task would not have been added). > > Another captcha was suggested, but with the note "not tested on mediawiki" > (or something similar). We only install extensions supported by mediawiki > of course. > A simpler solution: Why not add back the "cat" captcha, but only show it to the spammers? Regards, -Rob (OK. That is a joke. But I was once asked by a manager, many years ago, to improve a spell checker so it only reported misspellings of words that were in the dictionary.) > If the admins wants a change, then please have a discussion about it on the > ML, and once agreed upon, file a JIRA. > > rgds > jan I. > > > Please help. >> >> -- >> Regards, >> Helen >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Mwiki] a massive spam attack. Again
On 6 February 2014 19:00, helen wrote: > Hi there, > > I'm Helen, a Wi admin. https://wiki.openoffice.org/wiki/User:Helen_russian > > Since 5th Feb. MWiki is under a massive spam attack. > Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete , > https://wiki.openoffice.org/wiki/Special:Log/block > I warned about exactly that, but I was asked (see JIRAs) to remove the cats (captcha). If you read the JIRA (which was watched be several in here) you will see my warning. The simple captcha we have in place, is browser safe, but not very efficient. I assume the admins as such wanted the change (otherwise I am sure the task would not have been added). Another captcha was suggested, but with the note "not tested on mediawiki" (or something similar). We only install extensions supported by mediawiki of course. If the admins wants a change, then please have a discussion about it on the ML, and once agreed upon, file a JIRA. rgds jan I. Please help. > > -- > Regards, > Helen > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
[Mwiki] a massive spam attack. Again
Hi there, I'm Helen, a Wiki admin. https://wiki.openoffice.org/wiki/User:Helen_russian Since 5th Feb. MWiki is under a massive spam attack. Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete , https://wiki.openoffice.org/wiki/Special:Log/block Please help. -- Regards, Helen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: spam attack
Copy to Gordon Cairns - Non-Subscribed Poster Original Message From: Rory O'Farrell To: dev@openoffice.apache.org Date: Mon, 26 Nov 2012 12:51:40 + > On Mon, 26 Nov 2012 12:01:32 + > Cairns wrote: > >> Having been bedevilled by OpenOffice 3.4.1 System crashes to the extent >> of wanting to ditch the whole programme I now understand the programme >> is under spam attack and you ask users to contact you for a solution. >> That would be most welcome. >> Regards, Gordon Cairns >> > The stability of OpenOffice is a matter of interaction with your operating > system. You need to tell us what your operating system is and what symptoms > you are experiencing. You may also find it of use to search the Forum at > http://forum.openoffice.org/en/forum/ > > > I doubt that any such instability is caused by a spam attack; the current > spam attack is to the mwiki pages. Just to further clarify Rory's reply. It is not the program itself which came under spam attack, it was the Wiki area of the project's web services. The attack has now been thwarted by an excellent team of hardworking volunteers. Please post back to this list or the user support list us...@openoffice.apache.org with the information Rory suggested for assistance in resolving the issues you are experiencing.
Re: spam attack
On Mon, 26 Nov 2012 12:01:32 + Cairns wrote: > Having been bedevilled by OpenOffice 3.4.1 System crashes to the extent > of wanting to ditch the whole programme I now understand the programme > is under spam attack and you ask users to contact you for a solution. > That would be most welcome. > Regards, Gordon Cairns > The stability of OpenOffice is a matter of interaction with your operating system. You need to tell us what your operating system is and what symptoms you are experiencing. You may also find it of use to search the Forum at http://forum.openoffice.org/en/forum/ I doubt that any such instability is caused by a spam attack; the current spam attack is to the mwiki pages. -- Rory O'Farrell
Re: spam attack
On Mon, 26 Nov 2012 12:01:32 + Cairns wrote: > Having been bedevilled by OpenOffice 3.4.1 System crashes to the extent > of wanting to ditch the whole programme I now understand the programme > is under spam attack and you ask users to contact you for a solution. > That would be most welcome. > Regards, Gordon Cairns > The stability of OpenOffice is a matter of interaction with your operating system. You need to tell us what your operating system is and what symptoms you are experiencing. You may also find it of use to search the Forum at http://forum.openoffice.org/en/forum/ I doubt that any such instability is caused by a spam attack; the current spam attack is to the mwiki pages. -- Rory O'Farrell
spam attack
Having been bedevilled by OpenOffice 3.4.1 System crashes to the extent of wanting to ditch the whole programme I now understand the programme is under spam attack and you ask users to contact you for a solution. That would be most welcome. Regards, Gordon Cairns
Re: [Mwiki] Spam Attack in progress!
On 11/17/2012 18:04, TJ Frazier wrote: On 11/17/2012 17:17, Rob Weir wrote: On Nov 17, 2012, at 4:26 PM, TJ Frazier wrote: On 11/17/2012 15:56, Max Merbald wrote: Hi, disabling new registrations is one thing which might, however, stop sensible people from participating. I think it must be very frustrating when you're trying to register somewhere in order to constructively contribute to a project and you can't. Won't it be possible to ban some of the more aggressive spammers instead? Max Hi, Max, Indeed, we sysops are banning every single spammer, but they seem to have a large supply of user names to burn. We need to find out what they have in common, and ban /that/! Motivation? Aren't they doing this for Pagerank love? If we can make all links in the wiki be rel="nofollow" then that might remove the motivation. I've had success disincentivizing link spam on other sites that way. Also, would a CAPTCHA on registration and/or in first posting be possible? Or, has anyone made an MWiki plugin for SpamAssasin? We already use SA for the lists. -Rob Much of the spam explicitly mentions SEO, so I also assume "Pagerank love". Also, there was much mention of Bitcoin, and this looks like a commercial (i.e., paid-for) operation, at least in part. I would have sworn (but I can't find it) that a recent thread complained about the wiki's "nofollow" setting, and it was changed by a site maintainer. I agree we should change it (or change it back). There is (or was) a CAPTCHA on registration, and (for a while) on external link saves. These are done by extensions invoked on the main parameter input, managed by site maintainers. Let me root around on Wp (actually, Mediawiki) re a SpamAssassin plug-in. If SA can validate email addresses, it might be useful. Research results from MediaWiki[1]: 1) No mention of SpamAssassin as a plug-in. 2) Disabling new account creation: $wgGroupPermissions['*']['createaccount'] = false; in LocalSettings.php 3) No follow: $wgNoFollowLinks (binary, defaults to True) /tj/ [1] http://www.mediawiki.org/wiki/Spamming Am 17.11.2012 21:49, schrieb TJ Frazier: On 11/17/2012 08:28, Regina Henschel wrote: Hi, TJ Frazier schrieb: Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina Hi, Regina, Thanks for the idea, but most of the spammers are already registered (not brand-new). A site maintainer (not me) could disable new registrations easily, but that would not be much help. We need to know how these spammers are registering (their email addresses) and how they are accessing the wiki (their IP addresses). The information is in the MySQL database, but it is only accessible from root-level MySQL commands; Wp is paranoid about user secrecy. For instance, are they using those "open reply" email addresses, where the email waits to be picked up by anybody? Clayton had a code snippet to block their use, but it may not have survived. I have promoted one dedicated and careful user to sysop; between us, we are keeping up with the flood. But they are still coming. /tj/
Re: [Mwiki] Spam Attack in progress!
On 11/17/2012 17:17, Rob Weir wrote: On Nov 17, 2012, at 4:26 PM, TJ Frazier wrote: On 11/17/2012 15:56, Max Merbald wrote: Hi, disabling new registrations is one thing which might, however, stop sensible people from participating. I think it must be very frustrating when you're trying to register somewhere in order to constructively contribute to a project and you can't. Won't it be possible to ban some of the more aggressive spammers instead? Max Hi, Max, Indeed, we sysops are banning every single spammer, but they seem to have a large supply of user names to burn. We need to find out what they have in common, and ban /that/! Motivation? Aren't they doing this for Pagerank love? If we can make all links in the wiki be rel="nofollow" then that might remove the motivation. I've had success disincentivizing link spam on other sites that way. Also, would a CAPTCHA on registration and/or in first posting be possible? Or, has anyone made an MWiki plugin for SpamAssasin? We already use SA for the lists. -Rob Much of the spam explicitly mentions SEO, so I also assume "Pagerank love". Also, there was much mention of Bitcoin, and this looks like a commercial (i.e., paid-for) operation, at least in part. I would have sworn (but I can't find it) that a recent thread complained about the wiki's "nofollow" setting, and it was changed by a site maintainer. I agree we should change it (or change it back). There is (or was) a CAPTCHA on registration, and (for a while) on external link saves. These are done by extensions invoked on the main parameter input, managed by site maintainers. Let me root around on Wp (actually, Mediawiki) re a SpamAssassin plug-in. If SA can validate email addresses, it might be useful. /tj/ /tj/ Am 17.11.2012 21:49, schrieb TJ Frazier: On 11/17/2012 08:28, Regina Henschel wrote: Hi, TJ Frazier schrieb: Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina Hi, Regina, Thanks for the idea, but most of the spammers are already registered (not brand-new). A site maintainer (not me) could disable new registrations easily, but that would not be much help. We need to know how these spammers are registering (their email addresses) and how they are accessing the wiki (their IP addresses). The information is in the MySQL database, but it is only accessible from root-level MySQL commands; Wp is paranoid about user secrecy. For instance, are they using those "open reply" email addresses, where the email waits to be picked up by anybody? Clayton had a code snippet to block their use, but it may not have survived. I have promoted one dedicated and careful user to sysop; between us, we are keeping up with the flood. But they are still coming. /tj/
Re: [Mwiki] Spam Attack in progress!
On Nov 17, 2012, at 4:26 PM, TJ Frazier wrote: > On 11/17/2012 15:56, Max Merbald wrote: >> Hi, >> >> disabling new registrations is one thing which might, however, stop >> sensible people from participating. I think it must be very frustrating >> when you're trying to register somewhere in order to constructively >> contribute to a project and you can't. >> >> Won't it be possible to ban some of the more aggressive spammers instead? >> >> Max > > Hi, Max, > > Indeed, we sysops are banning every single spammer, but they seem to have a > large supply of user names to burn. We need to find out what they have in > common, and ban /that/! > Motivation? Aren't they doing this for Pagerank love? If we can make all links in the wiki be rel="nofollow" then that might remove the motivation. I've had success disincentivizing link spam on other sites that way. Also, would a CAPTCHA on registration and/or in first posting be possible? Or, has anyone made an MWiki plugin for SpamAssasin? We already use SA for the lists. -Rob > /tj/ > >> >> >> Am 17.11.2012 21:49, schrieb TJ Frazier: >>> On 11/17/2012 08:28, Regina Henschel wrote: Hi, TJ Frazier schrieb: > Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the > deleted-pages count is higher. Normal would be about half a dozen. And > still they come. > > In the short run, I can probably handle it, though help from any > committer sysops would be useful. > > In the long run, some site-maintainer work is needed. The additional > powers available in later Mwiki versions might be enough to control > this > sort of thing. Clayton has advised that upgrading is a non-trivial > problem, due to a possible encoding foul-up. Whatever we do, we need to > do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina >>> Hi, Regina, >>> >>> Thanks for the idea, but most of the spammers are already registered >>> (not brand-new). A site maintainer (not me) could disable new >>> registrations easily, but that would not be much help. >>> >>> We need to know how these spammers are registering (their email >>> addresses) and how they are accessing the wiki (their IP addresses). >>> The information is in the MySQL database, but it is only accessible >>> from root-level MySQL commands; Wp is paranoid about user secrecy. >>> >>> For instance, are they using those "open reply" email addresses, where >>> the email waits to be picked up by anybody? Clayton had a code snippet >>> to block their use, but it may not have survived. >>> >>> I have promoted one dedicated and careful user to sysop; between us, >>> we are keeping up with the flood. But they are still coming. >>> >>> /tj/ > >
Re: [Mwiki] Spam Attack in progress!
On 11/17/2012 15:56, Max Merbald wrote: Hi, disabling new registrations is one thing which might, however, stop sensible people from participating. I think it must be very frustrating when you're trying to register somewhere in order to constructively contribute to a project and you can't. Won't it be possible to ban some of the more aggressive spammers instead? Max Hi, Max, Indeed, we sysops are banning every single spammer, but they seem to have a large supply of user names to burn. We need to find out what they have in common, and ban /that/! /tj/ Am 17.11.2012 21:49, schrieb TJ Frazier: On 11/17/2012 08:28, Regina Henschel wrote: Hi, TJ Frazier schrieb: Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina Hi, Regina, Thanks for the idea, but most of the spammers are already registered (not brand-new). A site maintainer (not me) could disable new registrations easily, but that would not be much help. We need to know how these spammers are registering (their email addresses) and how they are accessing the wiki (their IP addresses). The information is in the MySQL database, but it is only accessible from root-level MySQL commands; Wp is paranoid about user secrecy. For instance, are they using those "open reply" email addresses, where the email waits to be picked up by anybody? Clayton had a code snippet to block their use, but it may not have survived. I have promoted one dedicated and careful user to sysop; between us, we are keeping up with the flood. But they are still coming. /tj/
Re: [Mwiki] Spam Attack in progress!
Hi, disabling new registrations is one thing which might, however, stop sensible people from participating. I think it must be very frustrating when you're trying to register somewhere in order to constructively contribute to a project and you can't. Won't it be possible to ban some of the more aggressive spammers instead? Max Am 17.11.2012 21:49, schrieb TJ Frazier: On 11/17/2012 08:28, Regina Henschel wrote: Hi, TJ Frazier schrieb: Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina Hi, Regina, Thanks for the idea, but most of the spammers are already registered (not brand-new). A site maintainer (not me) could disable new registrations easily, but that would not be much help. We need to know how these spammers are registering (their email addresses) and how they are accessing the wiki (their IP addresses). The information is in the MySQL database, but it is only accessible from root-level MySQL commands; Wp is paranoid about user secrecy. For instance, are they using those "open reply" email addresses, where the email waits to be picked up by anybody? Clayton had a code snippet to block their use, but it may not have survived. I have promoted one dedicated and careful user to sysop; between us, we are keeping up with the flood. But they are still coming. /tj/
Re: [Mwiki] Spam Attack in progress!
On 11/17/2012 08:28, Regina Henschel wrote: Hi, TJ Frazier schrieb: Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina Hi, Regina, Thanks for the idea, but most of the spammers are already registered (not brand-new). A site maintainer (not me) could disable new registrations easily, but that would not be much help. We need to know how these spammers are registering (their email addresses) and how they are accessing the wiki (their IP addresses). The information is in the MySQL database, but it is only accessible from root-level MySQL commands; Wp is paranoid about user secrecy. For instance, are they using those "open reply" email addresses, where the email waits to be picked up by anybody? Clayton had a code snippet to block their use, but it may not have survived. I have promoted one dedicated and careful user to sysop; between us, we are keeping up with the flood. But they are still coming. /tj/
Re: [Mwiki] Spam Attack in progress!
Hi, TJ Frazier schrieb: Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. Is it possible for you, to disable any new registrations? Then you should do it. We can then discuss long run solutions. Kind regards Regina
[Mwiki] Spam Attack in progress!
Since 05:00 (UTC+5) this morning, I have blocked over 150 spammers; the deleted-pages count is higher. Normal would be about half a dozen. And still they come. In the short run, I can probably handle it, though help from any committer sysops would be useful. In the long run, some site-maintainer work is needed. The additional powers available in later Mwiki versions might be enough to control this sort of thing. Clayton has advised that upgrading is a non-trivial problem, due to a possible encoding foul-up. Whatever we do, we need to do it sometime soon. /tj/
