Hmm. I don't say much on this list, but this one piqued me. Indulge me.
Disclaimer: I don't use SpamAssassin.
On Thu, 18 Jul 2002, Jeffrey Wheat wrote:
> Most importantly, the idea is to STOP spam, not just put a tag
> on it telling my customers that the mail they are looking at is
> possibly spam.
*Your* idea, maybe. Other people want to do other things with stuff
identified as spam. Some of those other people might be your customers
(the quiet ones you don't hear from much, likely). They might quite like
the facility to have their spam tagged, and then _they_ decide whether
they are going to delete it, file it, or do so under certain other of
their own conditions. Some might always want to receive spam, for
amusement value, for research, because they are paranoid any "spam
stopper" will drop legitimate mail (which sooner or later you should
accept it will) ... many reasons.
SpamAssassin gives you the freedom to make these decisions. Depending on
how you implement with your MTA etc, it gives YOU as the operator of the
mail server the freedom to delete stuff SpamAssassin has identified as
spam, if that's the policy you want to operate. Others have commented on
the wisdom of that.
> They do not want to see that. They do not want to have
> to download hundreds of emails over a modem line (yes, we still have
> many thousands of modem users) so their email client can delete it
> based on one rule alone. This is where the problem in fact lies. Not
> simply making an already obvious observation that an email is spam and
> tagging as such.
So provide them with tools that let *them* choose what they want to
receive. Give them a web interface that lets them set their own SA
preferences. For the easy approach, let them toggle something that says
"don't deliver me mail with an SA score above XX".
> Tools like exiscan do exactly what a virus tool should do. It
> stops it. It doesn't put a tag on it telling a customer that "hey you
> got a virus". It stops it and the customer never sees it. It doesn't
> kill my mail server by spawning perl processes for each mail arriving.
> Tools for spam should do exactly that as well. Integrated into exim
> using local_scan, stop spam instead of simply tagging it.
> I am sure that spam assassin is a great solution for a number of
> sites, but for a busy ISP, it is simply too resource hungry and
> results in far too many complaints from customers.
Well that would rather depend on your implementation, and the resources
you give it. If you don't resource it enough, you will hit performance
problems. Your system is doing more work: sooner or later you're going to
ask it to do more work than it has capacity to do.
The point I'm making, is that just bunging SA on there and expecting it to
somehow know what you want it to do isn't enough. Systems don't work like
that I'm afraid, they aren't all just plug-and-play. You have to put some
effort in to get the results you require. SA and Exim and procmail and
RBL and MailScanner and exiscan and so on are (or provide) tools you can
use to help achieve your goal. It's YOUR job to make them work together
to provide something you (and your customers) want. If they don't work
the way you want: configure them, add new bits, or even re-write them the
way you want, if you desire.
Exim provides wonderful facilities to let you deal with mail under certain
conditions, presence and/or content of headers, running external programs,
local_scan, etc etc. Use them.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks Computing Officer, IT Services
Mailmaster, Listmaster, Webmaster, University Of Strathclyde, Glasgow, UK
Cachemaster jethro.binks@???
