permit_dnswl_client vs. reject_unauth_destination

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

permit_dnswl_client vs. reject_unauth_destination

Rich Wales
I'm using Postfix 2.8.1 on an Ubuntu Maverick server.

As suggested in http://www.postfix.org/SMTPD_ACCESS_README.html, I am
using separate SMTPD client, HELO, sender, and recipient restriction
lists (with various blacklist checks, as well as some client whitelist
checks, placed as appropriate in the various restriction lists).

In http://www.postfix.org/postconf.5.html#smtpd_client_restrictions, I
read that "for safety", permit_dnswl_client and permit_rhswl_client are
silently ignored when they would override reject_unauth_destination.

I understand why this is a good idea when a whitelist "permit" operation
appears in smtpd_recipient_restrictions.  But does this "silent ignoring"
also happen even if the whitelist "permit" operation is located in
smtpd_client_restrictions, while the reject_unauth_destination is in
smtpd_recipient_restrictions?  It seems unnecessary and confusing to
ignore the whitelist operation in this case (unless there is some subtle
cause for concern that I'm overlooking).

Rich Wales
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: permit_dnswl_client vs. reject_unauth_destination

Victor Duchovni
On Fri, Jun 24, 2011 at 08:12:28PM -0700, Rich Wales wrote:

> In http://www.postfix.org/postconf.5.html#smtpd_client_restrictions, I
> read that "for safety", permit_dnswl_client and permit_rhswl_client are
> silently ignored when they would override reject_unauth_destination.

That is ignored in the context of a "RCPT TO" command (thus in all of
the top-level restriction classes when smtpd_delay_reject = yes) for a
recipient that would fail "reject_unatuh_destination". For such a
recipient do you really need DNSWL whitelisting? Normally, clients
allowed to send outbound mail are required to present SASL credentials,
or be in mynetworks, and then DNSWL entries are not really relevant.

> I understand why this is a good idea when a whitelist "permit" operation
> appears in smtpd_recipient_restrictions.  But does this "silent ignoring"
> also happen even if the whitelist "permit" operation is located in
> smtpd_client_restrictions, while the reject_unauth_destination is in
> smtpd_recipient_restrictions?  It seems unnecessary and confusing to
> ignore the whitelist operation in this case (unless there is some subtle
> cause for concern that I'm overlooking).

Provided the recipient is not remote, the DNSWL is not ignored.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: permit_dnswl_client vs. reject_unauth_destination

Rich Wales
> That is ignored in the context of a "RCPT TO" command (thus in all of
> the top-level restriction classes when smtpd_delay_reject = yes) for
> a recipient that would fail "reject_unauth_destination". For such a
> recipient do you really need DNSWL whitelisting? Normally, clients
> allowed to send outbound mail are required to present SASL credentials,
> or be in mynetworks, and then DNSWL entries are not really relevant.
> Provided the recipient is not remote, the DNSWL is not ignored.

Normally, it wouldn't really matter which restriction caused a relaying
attempt to fail (as long as it did, somehow, fail).

This question came up after I tried to use the abuse.net mail relay test
site (http://verify.abuse.net/relay.html) to verify that my server was
not misconfigured as an open relay.  But since their site that tries a
laundry list of possible relay techniques (verify.abuse.net, 64.57.183.77)
is currently listed in zen.spamhaus.org -- a list which I am using in a
reject_rbl_client in my smtpd_client_restrictions, as well as including
it (with a high score) in my postscreen_dnsbl_sites -- the abuse.net
tests are being rejected by my server because of the blacklist, instead
of because I'm configured to refuse open relaying attempts.

I tried to bypass this problem by setting up my own private whitelist
(in a zone available only on my own LAN) and adding verify.abuse.net's
IP address there.  By doing this, I was able to convince postscreen to
let verify.abuse.net through -- but the relay tests were still being
rejected (by smtpd) on the grounds that the client (verify.abuse.net)
was in the zen.spamhaus.org blacklist.  Clearly, the permit_dnswl_client
(referencing my private whitelist) in my smtpd_client_restrictions was
somehow not working.

Now I understand why this is failing.  I guess I'm going to need to do
something different with my SMTPD restrictions -- possibly move all my
existing client restrictions to be at the end of my list of recipient
restrictions (after reject_unauth_destination).

Rich Wales
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: permit_dnswl_client vs. reject_unauth_destination

Noel Jones-2
On 6/24/2011 11:47 PM, Rich Wales wrote:
> Now I understand why this is failing.  I guess I'm going to need to do
> something different with my SMTPD restrictions -- possibly move all my
> existing client restrictions to be at the end of my list of recipient
> restrictions (after reject_unauth_destination).
>
> Rich Wales
> [hidden email]


It's often recommended to put all restrictions under
smtpd_recipient_restrictions to keep life simpler.

Basic format...

smtpd_recipient_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unauth_destination
   ... whitelists here ...
   ... local restrictions here ...
   ... greylist (if you use it) here ...
   ... rbl checks here ...

The general idea is:
- allow authorized clients
- reject relay attempts
- whitelist anything that needs whitelisting.  Since all the
restrictions are here, you don't need to worry about multiple
whitelists in multiple locations.
- local restrictions to reject mail you _know_ you want to
reject, such as local check_*_access blacklists, built-in
restrictions, etc.
- greylist clients you don't have a relationship with.
- RBL checks last since they are the most expensive (in terms
of time spent).

Using this simple framework can yield moderately complex
restrictions, with thousands of (valid) variations, and still
be readable to the average familiar-but-not-expert postfix admin.


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: permit_dnswl_client vs. reject_unauth_destination

/dev/rob0
In reply to this post by Rich Wales
On Fri, Jun 24, 2011 at 09:47:09PM -0700, Rich Wales wrote:

> This question came up after I tried to use the abuse.net mail relay
> test site (http://verify.abuse.net/relay.html) to verify that my
> server was not misconfigured as an open relay.  But since their
> site that tries a laundry list of possible relay techniques
> (verify.abuse.net, 64.57.183.77) is currently listed in
> zen.spamhaus.org -- a list which I am using in a reject_rbl_client
> in my smtpd_client_restrictions, as well as including it (with a
> high score) in my postscreen_dnsbl_sites -- the abuse.net tests are
> being rejected by my server because of the blacklist, instead of
> because I'm configured to refuse open relaying attempts.
>
> I tried to bypass this problem by setting up my own private
> whitelist (in a zone available only on my own LAN) and adding
> verify.abuse.net's IP address there.  By doing this, I was able
> to convince postscreen to let verify.abuse.net through -- but the
> relay tests were still being rejected (by smtpd) on the grounds
> that the client (verify.abuse.net) was in the zen.spamhaus.org
> blacklist.  Clearly, the permit_dnswl_client (referencing my
> private whitelist) in my smtpd_client_restrictions was somehow
> not working.

While I appreciate the geeky goodness of a local DNSWL, there are
simpler ways to get the job done. You can bypass all postscreen tests
using postscreen_access_list. And then check_client_access to bypass
smtpd's reject_rbl_client.

That said, the worry of being an open relay is insignificant. An
incompetent administrator would have a difficult time trying to make
that happen. A competent one, who reads documentation, is not likely
to make the mistakes that would cause a Postfix to be an open relay.
The most common scenario for having an unintentional open relay is
when the MTA is behind a broken NAT router, which has an internal IP
address in $mynetworks, and it shows the MTA all connections from
outside as coming from that internal IP address.

(Clearly you are not in that situation, because DNSBL lookups would
be meaningless.)

> Now I understand why this is failing.  I guess I'm going to need to
> do something different with my SMTPD restrictions -- possibly move
> all my existing client restrictions to be at the end of my list of
> recipient restrictions (after reject_unauth_destination).

Or better yet, just move on. :) You are not an open relay unless you
deliberately set it up that way.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header