On Fri, Sep 28, 2012 at 5:41 PM, /dev/rob0 <r...@gmx.co.uk> wrote: > On Fri, Sep 28, 2012 at 08:58:33AM -0300, francis picabia wrote: >> When the remote site attempts to deliver it is caught in blocklist: >> >> Sep 28 05:29:50 mx10 postfix/postscreen[15338]: NOQUEUE: reject: RCPT >> from [210.44.128.104]:33372: 550 5.7.1 Service unavailable; client >> [210.44.128.104] blocked using b.barracudacentral.org; >> from=<sheryl.s...@sdufe.edu.cn>, to=<john...@example.com>, >> proto=ESMTP, helo=<sdfi.edu.cn> >> >> I already have this: >> >> # grep postscreen /etc/postfix/main.cf >> postscreen_dnsbl_action = enforce >> postscreen_greet_action = enforce >> postscreen_dnsbl_threshold = 2 >> postscreen_dnsbl_sites = licensekey.zen.dq.spamhaus.net*2, >> b.barracudacentral.org*2, bl.spamcop.net*1 > > Note, with these settings you won't ever use the Spamcop result. > There should be other 1-point postscreen_dnsbl_sites. This is > equivalent to: > > # postscreen_dnsbl_threshold not set > postscreen_dnsbl_sites = licensekey.zen.dq.spamhaus.net, > b.barracudacentral.org >
Yes, I understand how it works. I have used a low rank when cautiously adding a new block list service. It allows me to evaluate a list rather than implement and then find it has false positive issues. Or combine it with another low ranking list, but I don't happen to have one at the moment. >> postscreen_access_list = cidr:/etc/postfix/postscreen_access, >> permit_mynetworks >> postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply >> >> # cat postscreen_access >> 210.44.128.104 PERMIT >> >> Is 'postscreen_blacklist_action = enforce' the missing link to >> whitelist it? > > This is a good question. My copy of postconf.5.html says: > > postscreen_blacklist_action (default: ignore) > > The action that postscreen(8) takes when a remote SMTP client is > permanently blacklisted with the postscreen_access_list > parameter. ... > > It does not mention what happens when the postscreen_access_list > returns PERMIT, but the name and description implies that it only > refers to blacklisted clients. Digging a bit further: > > postscreen_access_list (default: permit_mynetworks) > > Permanent white/blacklist for remote SMTP client IP addresses. > postscreen(8) searches this list immediately after a remote SMTP > client connects. Specify a comma- or whitespace-separated list > of commands (in upper or lower case) or lookup tables. The search > stops upon the first command that fires for the client IP address. > > ... > > permit > Whitelist the client and terminate the search. Do not subject > the client to any before/after 220 greeting tests. Pass the > connection immediately to a Postfix SMTP server process. > reject > Blacklist the client and terminate the search. Subject the > client to the action configured with the > postscreen_blacklist_action configuration parameter. > ... > > This says that postscreen_blacklist_action only applies to reject > entries in the postscreen_access_list. > >> I'd like to have some confidence it is going to work before asking >> to "try again". > > I'd have confidence in what the documentation says. :) Furthermore, > I'd go ahead and set "postscreen_blacklist_action = enforce" anyway. > You control that list, and presumably you would not want mail from > sites listed therein with REJECT. I did the postfix reload as suggested, and asked the remote user to retest. Postscreen rejected the email again. If I restart postfix I don't see any reference to the file postscreen_access so I'd think it finds it and the syntax is OK. We are running postfix 2.9.2 built from source, in use since April 2012. Just now I've added the config postscreen_blacklist_action = enforce and restarted Postfix. If it has no impact on PERMIT cases I'm not sure if it is worthwhile to ask the remote site to test again.
