[ ... ]
Argh, perhaps I should write one, in C++. ;-)
My advice would be to consider writing a filtering new server
instead. I.e. it connects to a news server of your choice, filters
out whatever you don't want, and your newsreader connects to this
local news server to collect its filtered feed of the news.
This should reduce the effort considerably, and be pretty easy to
make (mostly) portable -- not to mention making adoption a lot easier
since its only affect on the user would be the lack of spam.
A Usenet or NNTP caching proxy with filtering, the Leafnode-2,
http://cto.homelinux.net/ports?port=leafnode-devel, a work-in-progess
and Leafnode,
http://leafnode.sourceforge.net/ stable is already there;
why re-invent the wheel?
BTW, I don't intend detracting anyone from writing a new, tiny, clean,
compact, portable and an efficient NNTP proxy in C++ from scratch.
While it certainly looks interesting, Leafnode isn't quite what I had
in mind. In particular, while it does have filtering, the filtering
appears to be limited to regular expressions. While that's
undoubtedly better than nothing, I don't think it's really the best
way.
I think something a bit more extensible would be more useful. At the
bare minimum, it would include a couple of classes like:
class filter_base {
public:
virtual operator()(std::string const &message) const = 0;
};
class register_filter {
public:
bool operator()(filter_base const *filter);
};
A new spam filter would derive from filter_base. To get it used,
you'd register an instance with register_filter. The registered
filters would then be applied to incoming messages.
Probably a better approach would be to invoke each filter once for a
group of incoming messages. You could, for example, pass a filter an
iterator to the first message in the store, the first new message in
the store, and one beyond the last message in the store. This would
help support statistically-oriented filters that might attempt to
determine whether something was spam based on statistics of the
entire store instead of looking only at individual messages. Using
this approach, it would probably be most natural for the filter to
write out results via an iterator as well.
Of course, if you didn't mind adding some non-portable code, you
could also support filters being implemented in shared libraries
(UNIX) or DLLs (Windows).
Personally, I think filtering on regular expressions does more harm
than good. It never really works well, but it's good enough that it
tends to prevent anything better from being developed either.
