I'm glad to see that guys involved on the SubText project (a
re-engineering of .Text blog engine) are thinking a lot to fight spam at
360°.
The last
discussion is centered around a problem present at the moment and that we've
discussed a lot also on my blog: the CommentAPI. This API
permits you to activate a service that allows your readers to make comments
to your blog directly from their favorite RSS Aggregator, but this comfort
has a big side-effect: by enabling the CommentAPI you will open a back
door for spammers that can easily bypass your CAPTCHA filter and post
comments.
To have a flexible blog structure, the best choice could be to have the
possibility to enable or disable all the comment services (and trackbacks too)
as you want (maybe via an administrator interface) but I think also that by
closing all these service you'll have a more secure blog but also a "closed to
the world" blog.
If you close the CommentAPI service (just like if you close the possibility
to comment a post), how many readers will be happy? Not too much I think...
Blogs are borned to be commented. 
I think that a built-in antispam filter must be implemented to the core of
the blog engine (so you can turn on all the comment services but inserted
text will be natively filtered) and here the choice are opened: how to
implement a native filter? By modifying the SQL at the bottom level (maybe
inserting the possibility to manage a spam table via the admin interface of your
blog) or implement filtering on the API code?
What will be the best choice?