Loading ...
Sorry, an error occurred while loading the content.

273688Re: foolproof whitelisting

Expand Messages
  • /dev/rob0
    Feb 1, 2011
    • 0 Attachment
      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

      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

      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:

      In Postfix terms, you would want to do reject_rbl_client using
      zen.spamhaus.org, and reject_rhsbl_{client,sender,helo} using

      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):
      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:
      Offlist mail to this address is discarded unless
      "/dev/rob0" or "not-spam" is in Subject: header
    • Show all 3 messages in this topic