Re: stopping Spam with postfix

4 msg	nested_header_checks
10 msg	Hotmail Problem
4 msg	feedback request: scheduled delivery of messages
1 msg	pkgsrc 'postfix-stress' option (Re: PATCH versi...
10 msg	How to enforce users send email with the real f...
15 msg	Catchall setup problem with Virtual domains and...
2 msg	question
5 msg	restrictions
5 msg	problems with virtual alias table
2 msg	some mails bounce with 'Name or service not known'
2 msg	External recipients within same domain
2 msg	~RE: stopping Spam with postfix

stopping Spam with postfix
\ James D. Parra (12 Jan 2008)
. \ James A. de Haseth (12 Jan 2008)
. \ (Wietse Venema) (12 Jan 2008)
. \ James D. Parra (12 Jan 2008)
. . \ mouss (12 Jan 2008)
. . . \ thomas polnik (12 Jan 2008)
. . . . \ mouss (12 Jan 2008)
. . . . . \ Guy Story (13 Jan 2008)
. . . . . . \ Jorey Bump (13 Jan 2008)

17 msg	Messages stuck in active queue
4 msg	virtual: Command as adress list
1 msg	variable quota policy ideas
2 msg	How to unistall postfix from compiling source(m...
1 msg	Backup mx with local delivery and forwarding fo...
4 msg	Receiving Mail with from mydomain.com from unkn...
10 msg	Which is the best soft for mailscanning?

Subject:	Re: stopping Spam with postfix
Group:	Postfix-users
From:	Jorey Bump
Date:	13 Jan 2008

Guy Story wrote, at 01/13/2008 01:03 AM:

> On the extreme side and it is one of the things I am not sure is a great
> idea but works, I took advantage of the ability of Postfix to use cidr and
> blacklists. I created a cidr table and add cidr ranges with reject as the
> action. The pitfall with ranges is some places might get trapped.

The real pitfall with this approach is that it comes with a significant
maintenance overhead. Maintaining such lists soon becomes tiresome.

> I have to be
> careful on the cidr ranges, AT&T, Comcast and Verizon pops up on whois
> checks allot.
>
> check_client_access cidr:/etc/postfix/client.cidr
> check_client_access hash:/etc/postfix/blacklistedip
>
> These lists grow depending on my desire to add to the lists. It is one of
> those monsters that continues to add to the workload. I base the entries
> off of what is getting past all my checks which includes spam assassin.
> Usually an employee complaint gets it added. Anything that is flagged by
> ClamAV has a high chance of getting on my black lists as well.

You should investigate more automated methods. Simply implementing
greylisting or nolisting is likely to have a significant impact. If you
want to raise the bar further for certain CIDR blocks, consider
selective unlisting:

http://unlisting.org/selective.html

Mail to my site roughly runs this gauntlet:

Selective Unlisting -> Nolisting -> RBL -> helo checks -> sender checks
-> before queue SpamAssassin -> minimal header/body checks

In December 2007, the account I'm using now to write list mail (thus
making it a spam attractor) got a total of 3 spam messages delivered to
its INBOX. No mail was quarantined (requiring inspection), all
rejections occurred before reaching the MTA or during the SMTP
conversation, and there were no reported false positives.

Besides glancing at my reports each morning, there is hardly any
maintenance (sa-update runs daily and SA's bayes database auto-learns
with excellent accuracy in this arrangement). Typically, months will go
by before I tweak anything, and I'm often unaware of spam surges because
user INBOXes are rarely affected (I might see blips in my MRTG graphs,
instead).

My point is that by focusing on behaviour and obvious spam indicators,
you can avoid the drudgery associated with identifying and maintaining
lists of individual offenders, and put a system in place that will help
protect you against unknown abusers.