Nuclear Elephant: DSPAM is a Bayesian spam filter. However, it's one that doesn't just run for a single user, but typically for an entire group of users. I have it running on simon.bofh.ms to scan all the mailboxes there - it integrates well and has a whole range of interesting features. On one hand, there's the web interface for managing the spam filter, and on the other hand, there's the quite pragmatic method for reporting false detections to the filter. Also nice is the quite broad support for databases (MySQL, PostgreSQL, SQLite, and several db* types). Overall, it makes a really well-rounded impression - the only downside is the lack of translation for the interface.
Whether it actually filters well, I of course can't say yet due to lack of volume - the emails first need to accumulate and be trained. User reports are, however - typical for Bayesian spam filters - quite positive.
Solaris 10 is now available for free download - even though I certainly won't be using it in production, it would definitely be worth taking a look at.
Isotopp is pondering trackback spam on the occasion of spam day and presents several approaches. One of them uses a counter-check of the trackback URL against the IP of the submitting computer - if the computer has a different IP than the server advertised in the trackback, it would probably be spam. I've written down my own comments on this - and explained why I'd rather be rid of trackback today than tomorrow. Completely. And yes, that's a complete 180-degree turn on my part regarding trackback.
The IP test approach once again comes from the perspective of pure server-based blogs. But there's unfortunately a large heap of trackback-capable software installations that don't need to run (and often don't run) on the server where the blog pages are located - all tools that produce static output, for example. Large installations are Radio Userland blogs. Smaller PyDS blogs. Or also Blosxom variants in offline mode (provided there are now trackback-capable versions - but since they're typical hacker tools, they definitely exist).
Then there are the various tools that aren't trackback-capable, where users then use an external trackback agent to submit trackbacks.
And last but not least, there are also the various Blogger/MetaWeblogAPI clients that submit the trackback themselves because, for example, only MoveableType in the MetaWeblogAPI allows triggering trackbacks, but other APIs don't.
Because of this, the IP approach is either only to be seen as a filter that lets through some of the trackbacks, or it's a prevention of trackbacks from the users mentioned above. And the latter would be extremely unpleasant.
Actually, the problem is quite simple: Trackback is a sick protocol that was stitched together with a hot needle, without the developer giving even a moment's thought to the whole thing. And therefore belongs, in my opinion, on the garbage heap of API history. The fact that I support it here is simply because WordPress implemented it by default. Once the manual moderation effort becomes too high, trackback will be completely removed here.
Sorry, but on the trackback point the MoveableType makers really showed a closeness to Microsoft behavior: pushed through a completely inadequate pseudo-standard via market dominance - without giving even a thought to the security implications. Why do you think RFCs always have a corresponding section on security problems as mandatory? Unfortunately, all the blog developers faithfully followed along (yes, me too - at Python Desktop Server) and now we're stuck with this silly protocol. And its - completely predictable - problems.
Better to develop and push a better alternative now - for example PingBack. With PingBack, it's defined that the page that wants to execute a PingBack to another page must really contain this link there exactly as it is - in the API, two URLs are always transmitted, its own and the foreign URL. The own URL must point to the foreign URL in the source, only then will the foreign server accept the PingBack.
For spammers this is pretty absurd to handle - they would have to rebuild the page before every spam or ensure through appropriate server mechanisms that the spammed weblogs then present a page during testing that contains this link. Of course that's quite doable - but the effort is significantly higher and due to the necessary server technology, this is no longer feasible with foreign open proxies and/or dial-up access.
Because of this, the right approach would simply be to switch the link protocol. Away with Trackback. You can't plug the trackback hole. PS: anyone who looks at my trackback in Isotopp's post will immediately see the second problem with trackback: apart from the huge security problem, the character set support of trackbacks is simply a complete disaster. The original author of the pseudo-standard didn't think for a minute about possible problems here either. And then some people still wonder why TypeKey from the MoveableType people isn't so well accepted - sorry, but people who make such lousy standards won't be getting my login management either ...
