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.
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.
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.
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.
{^_^}
