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

foolproof whitelisting

Expand Messages
  • sunhux G
    Our current way of blocking a spam address is by editing access_sender & access_recipient & then reload postmap. From time to time we re given addresses that
    Message 1 of 3 , Feb 1 4:43 AM
    • 0 Attachment

      Our current way of blocking a spam address is by editing
      access_sender & access_recipient & then reload postmap.

      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?

      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


      Thanks
      Sun

    • Brian Evans - Postfix List
      ... Postfix does not allocate certain file names for access maps. You may have as many as you like, the only thing that matters is the order of the maps in the
      Message 2 of 3 , Feb 1 6:22 AM
      • 0 Attachment
        On 2/1/2011 7:43 AM, sunhux G wrote:
        >
        > Our current way of blocking a spam address is by editing
        > access_sender & access_recipient & then reload postmap.
        >
        > 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?
        >
        > 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
        >
        Postfix does not allocate certain file names for access maps.
        You may have as many as you like, the only thing that matters is the
        order of the maps in the restriction class.
        The first match always wins, so put your whitelists before any blacklists.

        I recommend using "permit_auth_destination" as the result for a
        whitelist due to your mentioned turnover rate.
        This will prevent any open relays if the whitelist is incorrectly placed
        in the chain of restrictions (in recipient restrictions before
        reject_unauth_destination)
      • /dev/rob0
        ... Hmmm, whitelisting is often foolish, or foolishly implemented, so this is difficult. :) ... As Brian pointed out, those filenames have no universal meaning
        Message 3 of 3 , Feb 1 11:13 AM
        • 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
          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
        Your message has been successfully submitted and would be delivered to recipients shortly.