From: Noel Jones (njonesmegan.vbhcs.org)
Date: Tue Jul 03 2007 - 12:28:22 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

At 09:40 AM 7/3/2007, Joey wrote:
> I have rules like these:
>Client_access:
> gdynia.mm.pl 550 SPR-CA2-gdynia.mm.pl
> kabelbw.de 550 SPR-CA2-kabelbw.de
> versanet.de 550 SPR-CA2-versanet.de
> inter.net.il 550 SPR-CA2-inter.net.il
> ( spr for me means spam relay )

Local check_*_access tables have very little impact on server
performance/load. hash: btree: and cdb: tables scale well to
millions of records. Consider using cdb: tables for maximum
performance and fast atomic rebuilds. Postfix cidr: tables should
work well up to tens of thousands of entries.

Avoid large regexp: tables. pcre: generally performs better than
regexp:, but tables should still be limited as much as possible in
size. Not much has been posted about scaling pcre: access tables,
but they should probably not exceed hundreds to maybe low thousands of entries.

> Header_checks:
> /^(To|From|Cc|Reply-To):.*uu02\.com/ REJECT Header TFCR 1999
> /^Subject:.*COMPLETE CREDIT CARD/ REJECT SubJect Rejected
> /^X-Mailer: MaxBulk.Mailer/ REJECT Spam
> Mailer Program 117

If you have tons of similar expressions, put them in IF...ENDIF
sections to improve performance. Header_checks have some impact on
system load, but usually not too bad since they don't evaluate too
much data, but tens of thousands of entries will cause noticeable load.

IF /^(from|to|cc): /
/1.example.com/ REJECT address 1
/example.org/ REJECT address 2
...
ENDIF

Note that matching spam headers is a losing battle...

> Body_checks:
>Gets built from a huge list of domains that advertise in email, we
>put multiple domain names on a line in order to make the processing
>time less, and we identify each line with a different number so we
>can figure out what domain name caused the reject like below.
>/\b(?:(?:\=[[:xdigit:]]{2})+|:\/\/||=40|\.)?(?:zzzworldmeds(?:\.|=2e)com)\b/
>REJECT CONTENT REJECTED-LINED1583

This is almost certainly what is causing your high system
load. Body_checks are not intended as a general-purpose content
scanning tool. Abandon this approach and use
amavisd-new/spamassassin instead.

Or check out http://www.policyd-weight.org/ which looks up the sender
in some of the URI blocklists - quite effective.

Consider greylisting if you're not using it already.

At the least, figure out how to use IF..ENDIF statements to limit the
scope of blocks of similar body_checks rules.

> At the firewall level:
>We use CIDR block lists updated daily which then update small db's.
>and we document that like so:
>Jul 3 10:30:54 saturn kernel: SPAM-BLOCK-CIDR-ASIAN IN=eth0 OUT=
>MAC=00:03:47:c9:87:40:00:e0:1e:cd:e1:23:08:00 SRC=124.160.91.223
>DST=108.234.15.17 LEN=52 TOS=0x00 PREC=0x00 TTL=51 ID=22358 DF
>PROTO=TCP SPT=8872 DPT=25 WINDOW=58944 RES=0x00 SYN URGP=0

Good.

Digging through the pflogsumm and postfix-logwatch reports are the
best tools I've found for evaluating what rules are hitting. Abandon
your body_checks.

--
Noel Jones

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]