new user frequently created

[matobaa]

new user frequently created, but many user has no tickets or hacks. we should simply enable acct_mgr.register.BotTrapCheck.

#10092 and SiteUpgradeProposal/UserClearance decides username policy.

[Ryan J Ollos]

I'm not familiar with that AccountManagerPlugin check. Steffen, what do you think?

[Steffen Hoffmann]

Replying to matobaa:

new user frequently created, but many user has no tickets or hacks.

Thanks for letting us know.

we should simply enable acct_mgr.register.BotTrapCheck.

In fact BotTrapCheck was already enabled, but it required a string for register_basic_token to go live - done. Could be worth looking at reasons why the sentinel field backed by TracSpamFilter does not stop (more) registration attempts. (Dirk?)

#10092 and SiteUpgradeProposal/UserClearance decides username policy.

Yeah. I felt a bit lonely after going for it. May I have more thoughts on that proposal, please?

[Ryan J Ollos]

Replying to hasienda:

we should simply enable acct_mgr.register.BotTrapCheck.

In fact BotTracCheck was already enabled, but it required a string for register_basic_token to go live - done. Could be worth looking at reasons why the sentinel field backed by TracSpamFilter does not stop (more) registration attempts. (Dirk?)

Thanks for that. I went through the registration process just now and I see the Parole field is active.

I'm not sure where the sentinel field backed by TracSpamFilter should take effect though, or what that is exactly. Is there a specific ​t:SpamFilter module to which you are referring?

[Dirk Stöcker]

I'm not sure where the sentinel field backed by TracSpamFilter should take effect though, or what that is exactly. Is there a specific ​t:SpamFilter module to which you are referring?

Spamfilter adds multiple fields. Invisible fields which lead to downweighting when filled and a visible field which is only for text checks.

Nevertheless the spam filter is not optimal for the registration process, as there is not enough text for checks. So if the spammers aren't dumb enough to fill the invisible field and aren't on many IP blacklists there is not much which the filter can do.

But I don't see any "/register" calls in the spam log. Are you sure spamfilter is activated as a registration check?

P.S. I'd recommend updating the plugin.

[Ryan J Ollos]

Replying to stoecker:

P.S. I'd recommend updating the plugin.

I tried to upgrade this evening:

The upgrade failed. Please fix the issue and try again.

InternalError: cannot drop table spamfilter_log because other objects depend on it
DETAIL:  view "spammer-ip-stats" depends on table spamfilter_log
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

[Ryan J Ollos]

See also #11200.

[Dirk Stöcker]

As the checks still don't pass through to spamfilter, maybe you can give me admin rights to modify the Accountmanger settings myself, so I can correct the settings?

[Steffen Hoffmann]

Replying to rjollos:

I'm not sure where the sentinel field backed by TracSpamFilter should take effect though, or what that is exactly. Is there a specific ​t:SpamFilter module to which you are referring?

Yes. I've just added RegistrationFilterAdapter to 'register_check' option in [account-manager] section of our trac.ini. This shouldn't have taken so long, sorry.

[Dirk Stöcker]

Probably the wiki should be checked and cleaned. There are many "dead-user" user pages which never where used. Some of them are clearly linkspam. The spam attacks for track-hacks don't slow down, so spammers probably still have active content somewhere (e.g. in history of pages). For properly clan pages usually they slow down when inactive. Any such spammy places need to be removed. !Google webmaster tools can help to find such cases when checking the links and search terms.

[Dirk Stöcker]

It would be helpful, when I had the right to deleted users and wiki pages. When parsing the spam log some spammers are very obvious, but I can't delete the related users and user pages ATM.

[Steffen Hoffmann]

Replying to stoecker:

It would be helpful, when I had the right to deleted users and wiki pages. When parsing the spam log some spammers are very obvious, but I can't delete the related users and user pages ATM.

Thanks for your offer. I would be fine with giving Dirk the required permission. Other thoughts?

[osimons]

Thanks for offering to help out, stoecker! I'm OK with adding required permissions.

[Ryan J Ollos]

Sounds good to me as well. I'll send a PM to everyone that includes some configuration details that I don't want to post here.

[Dirk Stöcker]

Can you please update spamfilter-plugin to most recent version. I added a feature, which helps a lot especially here at trac hacks and also there have been some other updates.

P.S. Translations beside German need some attention :-) ​https://www.transifex.com/projects/p/Trac_Plugin-L10N/resource/spamfilter/

P.P.S. For JOSM I have a script which kills unwanted users from the database. Maybe you should setup the same here to get rid of spam users. Conditions could be:

• Last login more than 3 months ago or no login at all
• No edited pages (i.e. only the user page), tickets or checkins

Then delete user and user page. This probably will kill all spammers and also the users never active.

[Dirk Stöcker]

Replying to stoecker:

Can you please update spamfilter-plugin to most recent version. I added a feature, which helps a lot especially here at trac hacks and also there have been some other updates.

If not done yet, also add python-oauth2, so Mollom can work.

[Ryan J Ollos]

Thanks to contributions from everyone, especially Dirk and Steffen, we've cleaned out a lot of unused and spammer accounts and we can easily delete these as they appear. There is ongoing work to improve SpamFilterPlugin and AccountManagerPlugin (e.g. #12067 and #12054), but I don't see any open action items in this ticket. Please let me know if I've missed anything.

[Ryan J Ollos]

See also #12153.

[Dirk Stöcker]

Finally all old SPAM accounts I could detect are deleted. There are still some inconsistencies (i.e. more user pages than registered users), but I wont care for these.

[Ryan J Ollos]

Replying to stoecker:

Finally all old SPAM accounts I could detect are deleted. There are still some inconsistencies (i.e. more user pages than registered users), but I wont care for these.

Thank you for doing all that work. I see in the database 1970 user accounts and 105 not used. I assume those 105 not used are potential spam accounts that haven't "timed-out" yet. I'm just curious, do you have an estimate of the number of accounts that were deleted?

I made a note to eventually go back and delete user pages that aren't linked to accounts. It probably won't be too hard to write a one-time-use script for the operation.

[Dirk Stöcker]

Replying to rjollos:

Replying to stoecker:

Finally all old SPAM accounts I could detect are deleted. There are still some inconsistencies (i.e. more user pages than registered users), but I wont care for these.

Thank you for doing all that work. I see in the database 1970 user accounts and 105 not used. I assume those 105 not used are potential spam accounts that haven't "timed-out" yet. I'm just curious, do you have an estimate of the number of accounts that were deleted?

In the very beginning I posted numbers somewhere. Probably something like 4000 accounts have been deleted if I remember right.

I made a note to eventually go back and delete user pages that aren't linked to accounts. It probably won't be too hard to write a one-time-use script for the operation.

That's not so easy. I left all accounts which at least once changed anything except their own user-page. What I may have overlooked are user-pages which have been edited multiple times, but nothing else.

I don't know if these "default uninformative user-account pages" make much sense, but I believe that nearly all the remaining ones are from real persons (except I overlooked something obvious).

[Ryan J Ollos]

Replying to stoecker:

I don't know if these "default uninformative user-account pages" make much sense, but I believe that nearly all the remaining ones are from real persons (except I overlooked something obvious).

Oh, okay. I had in my mind that they were "danglers" from cases that the account was deleted without deleting the user page, since the addition of implicit user page deletion was just recently added.