The next version of LISTSERV will have support for a spam exit inside SMTPL.
Actually, this code was written shortly before the 15.0 release to deal with
a sudden three-fold increase in spam to LSOFT.COM (I guess we are not very
popular among the spam community). It was not quite ready for general
release back then (not enough configuration flexibility and no
documentation, not to mention limited testing), so we did not include it in
15.0. In a nutshell, you create a spam exit that runs incoming messages
through the spam filter of your choice and tells SMTPL what to do with them.
SMTPL can run an arbitrary but limitable number of scans in parallel, and
rejects bad messages on the wire. It has cut incoming mail to LISTSERV by
75-85%.

The main problem has been that I got a lot of heat when I phased in the
system. This was a surprise because we had applied spam filtering to
incoming mail for years, and I did not change the filter at all. The only
thing that had changed, from my perspective, was that it that it was now
highly parallel and we no longer had mail queues during peak hours (and the
legitimate complaints that came with them - and these complaints did stop as
the new SMTPL solved that problem). But there was another change I had not
thought of. By rejecting spam on the wire, SMTPL was causing bounces to be
generated in the rare cases where the message was not spam, but was sent
from a blacklisted mail server. Previously, these senders were unaware that
their messages were being filtered. Surely they must have noticed that there
never was any reply no matter how many times they resent, but they just did
not complain about it. Now, suddenly the world was ending, and it was all my
fault. I can't count the number of times I said that the new system was here
to stay and was exactly the same filtering we had had for years, except
serially. In the end, I treated these complaints like spam and just hit the
delete button. Over the course of several months, the main disgruntled
senders realized that their mail was silently dropped by quite a few other
organizations, and that it was a pointless fight for them to demand that the
entire world change their spam settings to whitelist the public ISP server
they were sharing with thousands of random consumer accounts. And why would
they? These servers do deliver quite a lot of spam. Once these unfortunate
senders set up their own mail servers, the false positives went away and so
did the complaints. But you should plan for these complaints if the
filtering is visible.

Anyway, you can contact me privately if you want to beta-test this SMTPL as
an alternative to buying hardware. We have been running it live for about
six months, so I am confident that it works fine, but you do have to write
you own exit to query the spam filtering system. I have one in REXX for
SpamAssassin.

  Eric