On Thu, 2006-02-09 at 09:44 +0100, Thomas Mueller wrote:
> M. J. [Mike] OBrien schrieb am 08.02.2006 12:03:
> > Any methodology which passes mail through SpamAssassin for the purpose
> > of 'Realtime Blackhole List' matching *after the MTA has accepted* the
> > message is a defacto 'GREYlisting' process.
> [..]
> >
> > If you want a BLACKlist process, the immediate rejection of UCE is the
> > most desirable action on a trusted RBL/DNSBL/URIDNSBL (RBL) positive
> > match. The ideal place to do the reject-on-RBL-match is at the initial
> > MTA SMTP connection -- reject the mail with a permanent failure code
> > (5** response) in the first SMTP transaction.
>
> You can have both too: SpamAssassin and blacklisting. Exim4 can pass the
> mail to SA while keeping the SMTP connection open.
> That way I can decide based on several BLs and further tests if I want
> to reject or accept the message.
> My user can even decide on their own if mail is ever rejected, and if
> yes how many SA points are required. Works very well.
Postfix can do that, too (see SMTPD_PROXY_README for how), but there are
of course tradeoffs, eg. from SMTPD_PROXY_README:
Pros and cons of before-queue content filtering
* Pro: Postfix can reject mail before the incoming SMTP mail transfer
completes, so that Postfix does not have to send rejected mail back
to the sender (which is usually forged anyway). Mail that is not
accepted remains the responsibility of the remote SMTP client.
* Con: The remote SMTP client expects an SMTP reply within a deadline.
As the system load increases, fewer and fewer CPU cycles remain
available to answer within the deadline, and eventually you either
have to stop accepting mail or you have to stop filtering mail. It
is for this reason that the before-queue content filter can be used
only on low-traffic sites.
* Con: Content filtering software can use lots of memory resources. In
order to not run out of memory you have to reduce the number of
before-filter SMTP server processes so that a burst of mail will not
drive your system into the ground with too many content filter
processes. This, in turn, means that SMTP clients have to wait for a
long time before they receive service.
I've never tried it though ... anyone else, offhand? I'd wondered if it
would cause issues at times, but I guess it's probably no different than
other times that spamassassin chokes up delivery (eg. something network
related stops responding/working).
--
Jesse Norell - [EMAIL PROTECTED]
Kentec Communications, Inc.
