Hi, I use similar order on the ACL's and just 2 weeks ago I moved the
RBL checks to the "connect" ACL instead of the "RCPT" ACL. This little
change, speed up my servers and reduce the load from 3 to 0.5
After thinking about it, is obvius that if we filter by IP, i.e. using
RBL, why not filter at the connection time if we just need the IP info
and nothing more? That way we don't do checks that are expensive and not
necesary.
Hope this help you a little.
Peter Bowyer wrote:
>Hi all
>
>I'm reviewing how we process incoming mail.
>
>Currently we apply the following checks in the RCPT ACL:
>
>- Sending IP in local blacklist
>- Missing HELO
>- Blacklisted HELO (eg oemcomputer.com)
>- HELO syntax (needs a '.', shouldn't be a bare IP)
>- HELO forgery (must not be one of our domains or IPs)
>- sbl-xbl.spamhaus.org DNSBL check
>- Sender verify (no callout)
>- Recipient verify with callout to non-local domains
>
>This deals with a huge percentage of our unwanted mail.
>
>Then in the DATA ACL, we call ClamAV and SpamAssassin via Exiscan,
>which deals with another chunk. Several SA thresholds are implemented
>for different classes of user, with the 'one class only per
>connection' trick.
>
>However.... in this architecture, which is pretty common, SA doesn't
>get to see all the spam, so the Bayesian learning is skewed towards
>learning ham.
>
>I suspect there would be benefit in letting SA 'see' the spam as well,
>perhaps not in real-time (ie in-line with the SMTP transaction), so it
>can learn spam as well as ham.
>
>Is anyone else doing this? How are you implementing it? I guess we
>could set an ACL variable in the RCPT acl instead of rejecting, and
>then do a 'control=fakereject' in the DATA acl if the variable is set
>and bypass the SA scan. And deliver the spam to a pipe to the spamc
>client, perhaps via a queue-only to control the load.
>
>Or simply let SA see everything inline, and make sure we reject after
>DATA if we would have rejected after RCPT?
>
>Clearly our SA load will increase dramatically if we let everything
>through to it.
>
>Any suggestions? Or am I worrying about a non-problem?
>
>Thanks
>
>Peter
>
>
>
--
Saludos....
Daniel Bendersky.
------------------------------------------------------------------
Daniel Bendersky Director de Operaciones y Tecnologia
dbenders@??? http://www.netline.cl
NETLINE Los Conquistadores # 2426
Oficina : +56 2 410 2600 Providencia, Santiago - CHILE
Celular : +56 9 998 9122 Fax2mail : +56 2 410 2651
Voice2mail: +56 2 410 2618
"Success is a journey, not a destination"
------------------------------------------------------------------
