On Tue, Feb 01, 2011 at 08:43:41PM +0800, sunhux G wrote:
> Subject: foolproof whitelisting
Hmmm, whitelisting is often foolish, or foolishly implemented, so
this is difficult. :)
> Our current way of blocking a spam address is by editing
> access_sender & access_recipient & then reload postmap.
As Brian pointed out, those filenames have no universal meaning in
Postfixology. I would assume that you're using access_sender as a
check_sender_access lookup, and access_recipient to lookup
check_recipient_access, but I have seen cases posted on this list
where that was not so, and the name had nothing to do with the use of
the file. Or sometimes that the file was not even being used! (That's
why the list guidelines ask for postconf -n and relevant logs with
questions.)
Now, I'd go a step further and look at your wording, "blocking a spam
address." What does this mean? A sender address which "sent spam"?
Did you know that sender addresses are nearly meaningless in spam?
The vast majority of spam is sent with forged addresses. Sometimes
these are real addresses. In general, it's the wrong approach to be
blocking "spam senders" by sender address, because:
1. That address might be legitimately used by a non-spammer; and
2. Blocking that address is usually not going to be effective,
because subsequent spam runs will use different sender
addresses.
Yes, many thousands of freemail accounts have been set up by and for
the use of spammers, and in that case (when the spam originates from
that freemail provider) such check_sender_access blocking can be
effective. But this accounts for a small portion of the spam I see.
The best introductory tutorial to spam abatement I know is the one
offered by Spamhaus:
http://www.spamhaus.org/whitepapers/effective_filtering.html
In Postfix terms, you would want to do reject_rbl_client using
zen.spamhaus.org, and reject_rhsbl_{client,sender,helo} using
dbl.spamhaus.org.
Also, not mentioned by the Spamhaus document, simple HELO checks are
very effective. I find that reject_non_fqdn_helo_hostname takes out
about 25% of all connections. Likewise, I reject any all-non-alpha
HELO with this simple check_helo_access regular expression:
!/[[:alpha:]]/ 550 5.5.2
We find that all-numeric EHLO/HELO greetings are usually
spam. If not, please ask your postmaster to correct the
server's EHLO/HELO greeting.
When sensibly used (after or separate from user submission
restrictions), this catches a lot. (Around 2300 on my very small
site, 20ish users, in the past month or so.)
(Yes, my expression does block the technically valid HELO syntax of
bracketed IP address. This was a deliberate policy decision, and I
have not seen any legitimate MTA sending mail with such a HELO. I
figure, if you run a MTA that wants to send mail to mine, you ought
to have a domain name.)
Consider also upgrading to Postfix 2.8 if you're not already there,
and try the new triage daemon, postscreen(8):
http://www.postfix.org/POSTSCREEN_README.html
It's in testing mode here, and I think it will do nicely to replace
my old reject_rbl_client restrictions.
> From time to time we're given addresses that should never
> be blocked but due to staff turnover & documentation not
> up-to-date, an address that should never be blocked was
> somehow blocked.
>
> Pardon me if this has been discussed before,
> what's the best way to go about preventing such mistakes?
Who is giving you these addresses? If these are user spam reports,
you're looking at the wrong part of the spam. Look at the IP
addresses from which they came.
> Is there a whitelist file that we can enter addresses that should
> never blocked so that even if this address is manually added
> into access_sender & access_recipient, they will still not be
> blocked (& possibly will be automatically removed from the
> two files access_sender/recipient).
>
> If there's such a whitelist file, presumably there should be 2
> of them, one for sending & receiving. Let me know the full
> directory path & filename of the whitelist files
Again I think Brian covered that. These links might help:
http://www.postfix.org/SMTPD_ACCESS_README.html
http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header