Re: [Exim] Re: SPAM filtering

> =09Most importantly, the idea is to STOP spam, not just put a tag on it tel=
> ling my customers that the mail they are looking at is possibly spam. They =
> do not want to see that. They do not want to have to download hundreds of e=
> mails 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.
>

Its refreshing to hear this. A lot of people get it wrong by going
simply for the tagging option. Most of our customers who complain
don't want to see it at all, particularly if it involves farmyard
animals and "virgins".

The other problem with tagging it is that the recipient has to opt to
delete it or save it to a mailbox to sift through later. Both of
these can lead to a very unreliable service. It is far better to
issue a rejection message with clear reasons about why it has been
rejected, how to avoid rejection and a support address (unfiltered).
A rejection indicating that the message was rejected because it scored
8.3 with a threshold of 8.2 isn't very friendly. Ones detailing what
scored how many points aren't much better either.

> =09Tools 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". I=
> t stops it and the customer never sees it. It doesn't kill my mail server b=
> y spawning perl processes for each mail arriving. Tools for spam should do =
> exactly that as well. Integrated into exim using local_scan, stop spam inst=
> ead of simply tagging it.
>
> =09I 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.

I may be wrong on this; it looks great technically, but appears to
have been written with little regard for customer service
considerations and on the assumption that mail will be tagged and not
rejected. I suspect that if it had been designed on the assumption
that a clear error message would be generated and the email failed
things would have been done a little differently.

It is also essential to have an opt in mechanism. Unless I've
misunderstood, SA documentation suggests that a high threshold for
opt-outs is the way to do this. This doesn't quite give an
opt-out/opt-in mechanism, and means that you have to process all
email. If you have a simple opt-in mechanism, the overheads are
significantly reduced as most of your email doesn't need to be
scanned.

Chris Bayliss