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

Re: foolproof whitelisting

Expand Messages
  • 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 1 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 2 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.