The placing of hyperlinks in wiki like this is often called "Wiki Spam". See, for example, http://www.usemod.com/cgi-bin/mb.pl?WikiSpam, http://c2.com/cgi/wiki?WikiSpam.
So far, the vandalism seems to be confined to wiki pages. I presume that it is only a matter of time until it spreads to tickets.
Possible solutions:
- When an anonymous user enters a URL in wiki, do not make URL into a a hyperlink until it has been approved by an authenticated user. Prior to approval, the URL is shown as plain text. Authenticated users have a link after the URL which will cause the URL to be approved. Other anonymous users will see an explanation of some kind stating that the link is pending approval. This could all be easily implemented by maintaining a table in the database of approved external hyperlinks.
- Require anonymous users to log in before making changes. They can still use the user name "anonymous". The anonymous user must also supply a password which they obtain by reading a CAPTCHA on the login screen. Ticket #401 adds a captcha to the existing throttler.
- A utility that allows the administrator to view all URLs in on any wiki page or ticket, and to selectively disable any that appear to be spam. This facility would allow an administrator to quickly clean up a site that had accumulated a spam load.
- Log changes by IP address and blacklist spammers.
- If it is only possible answer 'unknown username' for spam emails. It's one of many part solutions. Other is to rotate domain name.
- Adding <meta name="robots" content="noindex,nofollow"/> to HTML headers will prevent search engines from following links from a page. This can be done in the CVSTrac setup. This only works when spammers actually care whether or not their spam works. #573 adds rel="nofollow" controls to tell search engines to ignore external links, but suffers from the same limitations. See also: http://c2.com/cgi/wiki?DelayedIndexing
- #577 adds the ability to limit the number of external links added in any particular wiki edit. This, and other solutions which stop spam before it gets into the system, are usually preferrable. If they don't annoy legitimate users excessively.
- #577 should also make it feasible to add link blacklisting, somehow. That's really only effective if you get repeat offenders or common "known bad" words in spam links. [748] adds keyword-based filtering.
- #418 adds HTML attribute filtering which makes it much harder to hide wiki spam using stylesheets. Of course, the Wiki diff facility makes hiding spam from attentive users quite difficult in the first place.