The current state of zwiki spam is this: publicly-editable zwikis should set a true edits_need_username property, and in most cases this stops the spam; however there is at least one persistent zwiki spammer who works around this. I fairly regularly see a small burst of spam edits from and the wikis (and I know at least one other zwiki operator that gets hit.) The spam currently tries to be discreet, embedding a single link in existing content, and even trying to cover tracks with some regular-looking edits.

Next, I or some other all-edits subscriber will click to the affected pages, look at history (access key "y") and revert to the last good version. Aside: this leaves the spammed revisions in the history; I would rather expunge them completely, but that needs fixing.

Finally I will harvest the new spam domains and add them to the banned_links lines property which I keep on the root folder of the zwiki servers I manage ('s, and If I were to neglect this, the small bursts would probably become large ones. Sometimes I'll mention the new patterns on #zwiki as something other zwiki operators should add.

This is now too tedious, and I need a new plan. I had some fruitful discussion with betabug on #zwiki this morning, looking at his HoneyPotBL product and various other blacklist-type solutions out there. I have a new, two-pronged strategy targetting general and zwiki-specific spam respectively:

  1. I found Repel, a nice apache add-on for rejecting known-spammer ip addresses that just worked. This is now running on It's a little hard to test, but presumably providing some protection; the log shows occasional comment spammer and other suspicious/malicious ips being blocked. If you're getting zwiki spam and running behind apache, it's probably a good idea to set this up. You'll need to sign up with Project Honeypot to get a key, but that turns out to be easy.

  2. I made Zwiki check a global blacklist at edit time, out of the box. This is crude but requires no configuration, seems to be working and hopefully won't cause trouble. Here's the release note:

    The banned_links, max_anonymous_links and max_identified_links
    properties are no longer supported. Instead, at edit time Zwiki
    attempts to read a global blacklist of zwiki-specific spam patterns
    from This feature aims to stop the most common zwiki spam
    for all Zwiki users with minimum maintenance effort. For added
    protection, you can block known spammer ip addresses with (see also
    This is a prototype. For now, a http get attempt to with 1-second timeout is made at
    each edit. The feature is on by default. Todo: follow suggested
    caching interval.
    To disable use of the global blacklist, add a local "spampatterns"
    lines property on or above your wiki folder. You can leave it empty
    or paste in the contents of your old banned_links property.

Right away, this means less work for me, since updating one spampatterns.txt file is quicker than updating multiple banned_links properties. It protects all zwikis running the new code, mine and yours, and hopefully soon the zope wikis. And as a side benefit, it might for the first time give me way to estimate the number of active zwiki sites (by counting spampatterns.txt requests). Some folks may turn this off, but I'm hoping most will not. Comments welcome!