jdow wrote:
From: "Chr. v. Stuckrad" <[EMAIL PROTECTED]>
On Thu, 27 Jul 2006, jdow wrote:
From: "Loren Wilton" <[EMAIL PROTECTED]>
...
I've never seen the logic of placing SpamAssassin inside the incoming
transaction before the termination of the SMTP connection rather than
down the pipe in the MDA.
If you want to 'reject spam' (wih score over a given
threshold) and because you do not want to generate bounces,
you have to check 'inside the transaction', to tell the sending
MTA, that you do not accept the current mail becaus of spam.
That's fine. But you can't do it and make it work right. It also
makes each email transaction a second or more longer. If your
mail load can tolerate this, I suppose it is barely workable.
But you double your machine load doing so. You are better off
using block lists with a small score for each BL and then grey
list for questionable scores and block for known bad. SpamAssassin
is way too much code to traverse just for that small function.
It works great on my 2 user personal system. It would probably require a little more hardware for
my 2k+ user work system. ;)
This only works with site-wide bayes and global setup, except
if you make sure, that you know the (then exactly one?) recipient
of the message at the end of incoming data (the single '.' in the
SMTP-Protocol, the 'acl_smtp_data' in exim4).
Parsing on the fly for recipient means you need something to do
this before it gets to Bayes. That's even more code to run.
How hard is it to parse an "RCPT TO:"? Besides, most servers will have already parsed this to make
sure it is a valid recipient.
Beware of 'overloading the system' if you check incoming mails
'durig arrival', you will have to restrict the number of concurrent
SMTP-connections by the maximum of spamchecks your system can handle.
Of course, so greylisting is better with far less throughput damage.
I've only started to think about implementing (selective) greylisting on my systems but I hear that
the spammers are starting to wise up to it.
Stucki
PS.: I too prefer 'only to tag' the spams, and let the user decide
do discard them. I tested both ways and to me the only safe way
to never crowd the system ist to spamcheck on the inside in an
exim-queuerunner. The nr. of queuerunners can then simply be
adjusted to the capabilites of the server.
Score only and pass to recipient with a clear XXX.X score in
the subject markup. That allows easy sorting by score and elimination
even in stupid tools like OutlookExpress.
The logic for running SA before the SMTP transaction is complete is
more wishful thinking than practical. This is probably especially
true with smtp tools like PostFix that run in a chroot jail.
I don't really like the idea of sending spam to a black hole (quarantining). Only tagging as you
suggest puts the responsibility on the users but knowing the limited tech-savy-ness of most of my
users and the volume of spam they would receive makes that option less attractive to me. Even
sorting by score or creating filters is asking a bit much of many of my users.
Anyway, that's why I like the idea of SMTP-time rejection - not accepting the responsibility of the
message in the first place. Plus, if a legit mail does get blocked, the recipient will get
notified. (Even though I haven't been able to implement it on a large scale.)
