CIDR Whitelist ?

[Ronald F. Guilmette-2]

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]

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]

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]

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]

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]

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]

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

[Borja Marcos-2]

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.