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

Reply via email to