CIDR Whitelist ?
Locked
 
|
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? |
|
|
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 |
|
|
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 |
|
|
In reply to this post by Ronald F. Guilmette-2
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 |
|
|
In reply to this post by Michael Tokarev
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 |
|
|
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. |
|
|
In reply to this post by Stan Hoeppner
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 |
|
|
In reply to this post by Viktor Dukhovni
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. |
«
Return to Postfix Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |