Lots of spam up on Trac

Ruby Apps Typo
1

Hey does anyone police Trac for spam? Can we make it take registered
users only or perhaps install some sort of spam filtration plugin?

I keep getting notifications that this ticket (
http://www.typosphere.org/trac/ticket/953#comment:43 ) gets more spam.
The bots are even munging up the status, milestone, etc.

Blegh.

2

Hey does anyone police Trac for spam? Can we make it take
registered users only or perhaps install some sort of spam
filtration plugin?

There are spam-prevention plugins
http://trac.edgewall.org/wiki/SpamFilter

Maybe Trac should put rel=“nofollow” on its external wiki links,
reducing the incentive.

Is anyone working on a ruby svn front-end?

3

Well, rel=nofollow doesn’t really work, because spammers don’t care.

We used to be able to delete spam, but the latest trac upgrade broke
the tool that we used to delete spam. I’ve asked our hosting provider
to fix it, but it’s not clear when they’ll have time, and there’s not
a whole lot I can do without them–I don’t have write access to either
Trac or our Apache config.

Scott

4

Bots and spammers aren’t very thoughtful; efficient for pagerank or
not, they’ll attack whatever site meets the profile they know how to
deface. They’re not going to come back and feel frustrated that the
links they posted as rel=“nofollow”…

– Paul

5

Please, please switch Trac to registered users only, as I’m getting
SPAM, too. Many many Jira installations successfully operate in this
more without inhibiting participation.

– Paul

6

What we did was to add the account user/user so that the general public
could still enter items and advertise it on the main trac page.

Just a thought …
-Linda

7

“Scott L.” [email protected] writes:

Well, rel=nofollow doesn’t really work, because spammers don’t care.

We used to be able to delete spam, but the latest trac upgrade broke
the tool that we used to delete spam. I’ve asked our hosting provider
to fix it, but it’s not clear when they’ll have time, and there’s not
a whole lot I can do without them–I don’t have write access to either
Trac or our Apache config.

I become more and more tempted to shift onto hosting with
code.google.com or whatever it’s called…

8

Yeah, the thought has occurred to me. Two problems:

  1. No RSS feeds of new issues. Email notification is there now,
    though.
  2. No easy way to import past bugs.

How important are these to people?

Scott

9

That’s true; once the capability to deface Trac is in the toolset,
spammers will continue to use it. However, if a spammer wants to add a
new wiki to his toolset, they’d prefer one that doesn’t put nofollow on
the links. Better yet, if the history pages don’t have a nofollow
associated with them, then they still get benefits even after the
content is rolled back. Having the nofollow is certainly a disincentive,
I mean, what good is obvious linkspam if it isn’t picked up by search
engines?

But yes, it alone doesn’t prevent linkspam. Neither does blacklists. The
only thing that seems to work is CAPTCHA. On a comment form I’m
currently working on, I’m thinking about implementing selective captcha,
where CAPTCHA is required only when some minimum number of links exist
in the post.

10

Yeah, but Typo itself has always used nofollow for comments, yet
comment spammers have developed tools to spam Typo.

I honestly don’t think that the spam-tools people care a bit about
nofollow.

Scott

11

You know, Typo would probably be welcome at the Codehaus (or the
soon-to-be-publicly visible Rubyhaus), and then you’d have whatever
services you wanted from the suite that are available (svn, Jira,
Confluence, mailing lists, etc.).

– Paul