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

CIDR Whitelist ?

Expand Messages
  • Ronald F. Guilmette
    I really should have figured this out ages ago, but... Quite simply, there exits a small number of organizations that run afoul of my various
    Message 1 of 8 , Jun 9, 2014
      I really should have figured this out ages ago, but...

      Quite simply, there exits a small number of organizations that
      run afoul of my various smtpd_recipient_restrictions and/or my
      smtpd_helo_restrictions, but from which I need to be able to
      receive mail anyway. (A small number of companies get snagged
      on reject_unknown_helo_hostname due to having botched the HELO
      strings on their outbound mail servers, and also, in the case of
      Microsoft, they seem to have managed to get numerous of their
      IPs listed on Spamcop.)

      So anyway, I just now added the following to my pre-existing
      list of smtpd_recipient_restrictions:

      check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist

      where my cidr-whitelist file currently contains just:

      # Microsoft
      65.52.0.0/14 OK

      Of course, I placed this new check_client_access clause above all of
      the other/pre-existing clauses in my smtpd_recipient_restrictions.

      I just want to ask if I have done the proper thing here, because I've
      never done this before.

      My hope is that I haven't inadvertantly opened up a relaying hole or
      anything awful like that.

      One other question...

      Currently, I have the following:

      smtpd_helo_restrictions =
      permit_mynetworks
      reject_non_fqdn_helo_hostname
      reject_invalid_helo_hostname
      reject_unknown_helo_hostname

      In order to make sure that my new CIDR whitelist will allow in even
      mail from goofed-up sites that have botched their HELO strings, should
      I be moving the three reject_*helo_hostname clauses shown above down
      into my smtpd_recipient_restrictions... you know... to a position
      that comes *after* my new check_client_access clause?
    • Stan Hoeppner
      ... Yes. And if you have other separate smtpd_foo_restrictions sections you should move those restriction parameters under smtpd_recipient_restrictions as
      Message 2 of 8 , Jun 9, 2014
        On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote:
        > I really should have figured this out ages ago, but...
        >
        > Quite simply, there exits a small number of organizations that
        > run afoul of my various smtpd_recipient_restrictions and/or my
        > smtpd_helo_restrictions, but from which I need to be able to
        > receive mail anyway. (A small number of companies get snagged
        > on reject_unknown_helo_hostname due to having botched the HELO
        > strings on their outbound mail servers, and also, in the case of
        > Microsoft, they seem to have managed to get numerous of their
        > IPs listed on Spamcop.)
        >
        > So anyway, I just now added the following to my pre-existing
        > list of smtpd_recipient_restrictions:
        >
        > check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist
        >
        > where my cidr-whitelist file currently contains just:
        >
        > # Microsoft
        > 65.52.0.0/14 OK
        >
        > Of course, I placed this new check_client_access clause above all of
        > the other/pre-existing clauses in my smtpd_recipient_restrictions.
        >
        > I just want to ask if I have done the proper thing here, because I've
        > never done this before.
        >
        > My hope is that I haven't inadvertantly opened up a relaying hole or
        > anything awful like that.
        >
        > One other question...
        >
        > Currently, I have the following:
        >
        > smtpd_helo_restrictions =
        > permit_mynetworks
        > reject_non_fqdn_helo_hostname
        > reject_invalid_helo_hostname
        > reject_unknown_helo_hostname
        >
        > In order to make sure that my new CIDR whitelist will allow in even
        > mail from goofed-up sites that have botched their HELO strings, should
        > I be moving the three reject_*helo_hostname clauses shown above down
        > into my smtpd_recipient_restrictions... you know... to a position
        > that comes *after* my new check_client_access clause?


        Yes. And if you have other separate smtpd_foo_restrictions sections you
        should move those restriction parameters under
        smtpd_recipient_restrictions as well. This will give you precise
        control over whitelisting and blacklisting order.

        Cheers,

        Stan
      • Michael Tokarev
        ... It depends on the postfix version. Older postfix, which didn t have smtpd_relay_restrictions, will act as an open relay for these networks, because you
        Message 3 of 8 , Jun 9, 2014
          10.06.2014 05:02, Stan Hoeppner wrote:
          > On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote:
          >> I really should have figured this out ages ago, but...
          >>
          >> Quite simply, there exits a small number of organizations that
          >> run afoul of my various smtpd_recipient_restrictions and/or my
          >> smtpd_helo_restrictions, but from which I need to be able to
          >> receive mail anyway. (A small number of companies get snagged
          >> on reject_unknown_helo_hostname due to having botched the HELO
          >> strings on their outbound mail servers, and also, in the case of
          >> Microsoft, they seem to have managed to get numerous of their
          >> IPs listed on Spamcop.)
          >>
          >> So anyway, I just now added the following to my pre-existing
          >> list of smtpd_recipient_restrictions:
          >>
          >> check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist
          >>
          >> where my cidr-whitelist file currently contains just:
          >>
          >> # Microsoft
          >> 65.52.0.0/14 OK
          >>
          >> Of course, I placed this new check_client_access clause above all of
          >> the other/pre-existing clauses in my smtpd_recipient_restrictions.
          >>
          >> I just want to ask if I have done the proper thing here, because I've
          >> never done this before.
          >>
          >> My hope is that I haven't inadvertantly opened up a relaying hole or
          >> anything awful like that.

          It depends on the postfix version.

          Older postfix, which didn't have smtpd_relay_restrictions, will act as
          an open relay for these networks, because you allow them the same way
          you accept_mynetworks, so it becomes more or less your networks.
          You should put reject_unauth_destination before accepting these.

          More recent postfix, which has separate smtpd_relay_restrictions, will
          be saner (provided you don't prepend this whietelist to relay_restrictions
          too :).

          For other smtpd_*_restrictions, it does not really matter.

          >> One other question...
          >>
          >> Currently, I have the following:
          >>
          >> smtpd_helo_restrictions =
          >> permit_mynetworks
          >> reject_non_fqdn_helo_hostname
          >> reject_invalid_helo_hostname
          >> reject_unknown_helo_hostname
          >>
          >> In order to make sure that my new CIDR whitelist will allow in even
          >> mail from goofed-up sites that have botched their HELO strings, should
          >> I be moving the three reject_*helo_hostname clauses shown above down
          >> into my smtpd_recipient_restrictions... you know... to a position
          >> that comes *after* my new check_client_access clause?
          >
          >
          > Yes. And if you have other separate smtpd_foo_restrictions sections you
          > should move those restriction parameters under
          > smtpd_recipient_restrictions as well. This will give you precise
          > control over whitelisting and blacklisting order.

          I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give
          precise control over all the restrictions and their order, if you move
          it all to one stage it becomes clumsier. Also, moving stuff which should
          be run at connect or hello time to recipient time is kinda wrong.

          Such a suggestion - to move everything to recipient_restriction - can be
          given to a novice postfix user (or by novice postfix user), who does not
          understand smtp protocol stages and this smtpd_*_restrictions mechanics,
          both of which are kinda trivial.

          Thanks,

          /mjt
        • Wietse Venema
          ... Placing this before reject_unauth_destination will give them relay permissions (assuming that your system pre-dates smtpd_relay_restriction support). See:
          Message 4 of 8 , Jun 10, 2014
            Ronald F. Guilmette:
            >
            > I really should have figured this out ages ago, but...
            >
            > Quite simply, there exits a small number of organizations that
            > run afoul of my various smtpd_recipient_restrictions and/or my
            > smtpd_helo_restrictions, but from which I need to be able to
            > receive mail anyway. (A small number of companies get snagged
            > on reject_unknown_helo_hostname due to having botched the HELO
            > strings on their outbound mail servers, and also, in the case of
            > Microsoft, they seem to have managed to get numerous of their
            > IPs listed on Spamcop.)
            >
            > So anyway, I just now added the following to my pre-existing
            > list of smtpd_recipient_restrictions:
            >
            > check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist
            >
            > where my cidr-whitelist file currently contains just:
            >
            > # Microsoft
            > 65.52.0.0/14 OK
            >
            > Of course, I placed this new check_client_access clause above all of
            > the other/pre-existing clauses in my smtpd_recipient_restrictions.

            Placing this before reject_unauth_destination will give them relay
            permissions (assuming that your system pre-dates smtpd_relay_restriction
            support). See: http://www.postfix.org/SMTPD_ACCESS_README.html#danger

            Wietse
          • Stan Hoeppner
            ... will give you precise control . Note you , meaning the user, not Postfix. Having all restrictions in one place makes it easier, as in eyeballs on
            Message 5 of 8 , Jun 10, 2014
              On 6/10/2014 1:24 AM, Michael Tokarev wrote:
              > 10.06.2014 05:02, Stan Hoeppner wrote:
              ...
              >> Yes. And if you have other separate smtpd_foo_restrictions sections you
              >> should move those restriction parameters under
              >> smtpd_recipient_restrictions as well. This will give you precise
              >> control over whitelisting and blacklisting order.
              >
              > I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give
              > precise control over all the restrictions and their order, if you move

              "will give you precise control". Note "you", meaning the user, not
              Postfix. Having all restrictions in one place makes it easier, as in
              eyeballs on screen, to see what's going on.

              > it all to one stage it becomes clumsier. Also, moving stuff which should
              > be run at connect or hello time to recipient time is kinda wrong.

              Postfix performs delayed evaluation of restrictions by default so this
              is irrelevant. Evaluation order for the most part doesn't change, only
              the logical order in main.cf.

              > Such a suggestion - to move everything to recipient_restriction - can be
              > given to a novice postfix user (or by novice postfix user), who does not
              > understand smtp protocol stages and this smtpd_*_restrictions mechanics,
              > both of which are kinda trivial.

              Hammer or nail gun Michael? Everyone understands how the hammer works,
              but given the choice goes for the nail gun. It's faster, more precise,
              and saves your thumbs. :)

              Cheers,

              Stan
            • Viktor Dukhovni
              ... There is no single right answer. For many users a single linear list of conditions is simplest. For some users, where one wants a whitelist for one set
              Message 6 of 8 , Jun 10, 2014
                On Tue, Jun 10, 2014 at 01:43:50PM -0500, Stan Hoeppner wrote:

                > > I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give
                > > precise control over all the restrictions and their order, if you move
                >
                > "will give you precise control". Note "you", meaning the user, not
                > Postfix. Having all restrictions in one place makes it easier, as in
                > eyeballs on screen, to see what's going on.

                There is no single right answer. For many users a single linear
                list of conditions is simplest. For some users, where one wants
                a whitelist for one set of test to not short-circuit other tests,
                multiple lists are better. We should not be dogmatic about either
                approach.

                --
                Viktor.
              • Michael Tokarev
                ... [] ... It is irrelevant as long as you don t change the default. Which is okay to change too, ofcourse. Thanks, /mjt
                Message 7 of 8 , Jun 10, 2014
                  10.06.2014 22:43, Stan Hoeppner wrote:
                  > On 6/10/2014 1:24 AM, Michael Tokarev wrote:
                  []
                  >> it all to one stage it becomes clumsier. Also, moving stuff which should
                  >> be run at connect or hello time to recipient time is kinda wrong.
                  >
                  > Postfix performs delayed evaluation of restrictions by default so this
                  > is irrelevant. Evaluation order for the most part doesn't change, only
                  > the logical order in main.cf.

                  It is irrelevant as long as you don't change the default. Which is okay
                  to change too, ofcourse.

                  Thanks,

                  /mjt
                • borjam@...
                  ... What I used to do some time ago was this: - Define three different pools of smtpd processes listening on 127.0.0.2, 127.0.0.3... etc. One of the pools
                  Message 8 of 8 , Jun 11, 2014
                    El 10.06.2014 20:47, Viktor Dukhovni escribió:
                    > There is no single right answer. For many users a single linear
                    > list of conditions is simplest. For some users, where one wants
                    > a whitelist for one set of test to not short-circuit other tests,
                    > multiple lists are better. We should not be dogmatic about either
                    > approach.

                    What I used to do some time ago was this:

                    - Define three different pools of smtpd processes listening on
                    127.0.0.2, 127.0.0.3... etc. One of the pools would be devoted to
                    residential IP address blocks, another one to "general service" and a
                    third one to a whitelist of known-good servers for which there was
                    reliable contact information.

                    - Using the FreeBSD firewall, I created so called divert rules. For the
                    residential group and the whitelist group I defined a couple of
                    preffix/address tables, so that connections coming from those address
                    spaces would be diverted to the relevant pool of smtpd processes.

                    There were several advantages to this:

                    - Limiting the consumption of resources by likely bots coming from
                    residential addresses.

                    - Fine tuning the different policies for different origins. For the well
                    known servers I could bypass some checks.


                    For example, at some point I had something like 16 smtpd processes for
                    residential, 32 for well known servers, 200 for "general". Before
                    adopting this solution, even using 1000 smtpd processes was hopeless,
                    residential based bots quickly flooded all of them denying the reception
                    of legitimate mail.




                    Borja.
                  Your message has been successfully submitted and would be delivered to recipients shortly.