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
