| Main Archive Page > Month Archives > postfix-users archives |
Re: permit_dnswl_client vs. reject_unauth_destination
From: Rich Wales <richw_at_nospam>Date: Sat Jun 25 2011 - 04:47:09 GMT
To: postfix-users@postfix.org
> 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
richw@richw.org