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