On 9/24/2010 2:37 AM, Michael Orlitzky wrote:
On 09/24/10 01:10, Sahil Tandon wrote:
On Thu, 2010-09-23 at 21:37:40 -0400, Michael Orlitzky wrote:
check_client_access pcre:/<fudged>/generic_rbl_clients.pcre,
The content of generic_rbl_clients.pcre:
# sutton-partners.com
/^64\.191\.79\.245$/ public_rbls
# mabel.ca
/^70\.38\.108\.42$/ public_rbls
# dsnews.com
/^209\.172\.40\.21[157]$/ public_rbls
# Default: check these lists.
#
/./ all_rbls
However, 64.191.79.245 is still being subjected to the private RBL check:
Sep 23 10:05:42 mx1 postfix/smtpd[12164]: connect from
unknown[64.191.79.245]
^^^^^^^
% host 64.191.79.245
245.79.191.64.in-addr.arpa domain name pointer sutton-partners.com.
% host sutton-partners.com
sutton-partners.com has address 64.202.189.170
/./ is greedy! Explore check_reverse_client_hostname_access; and if
it suits your needs, thank Noel Jones. :)
Ok, I see what's going on. 'unknown' gets looked up first, and so /./
matches it before the client IP address gets looked up. Wouldn't
check_reverse_client_hostname_access suffer the same fate? I think
switching to a CIDR map probably avoids matching the 'unknown'; I'll
give that a try.
Yes, that's your problem and the correct solution.
I made this same mistake once upon a time...
With all the *access tests, the map is searched first for the
hostname, then for the IP. This is documented in the
access(5) man page, but maybe could be improved.
Stan Hoeppner wrote:
/\[([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})\]/ all_rbls
It only matches on a dotted quad enclosed in []. It won't match on the
rdns name, or lack thereof (unknown).
No, the table is searched twice; first with the hostname (or
unknown) and then with the bare IP -- no brackets. Carefully
read access(5) several times.
For a pcre IP catchall unlikely to match on a real hostname
you could use
/^[0-9.]+$/ all_rbls
a cidr table -- which can never match a name -- is the cleaner
solution.
Sahil Tandon wrote:
> Wouldn't check_reverse_client_hostname_access suffer the same fate?
No, because then Postfix passes the unverified reverse client hostname
to the access(5) map, rather than 'unknown'.
If the intent is to match on the IP,
check_reverse_client_hostname_access would indeed behave in
the same way; search once for the reverse hostname (or unknown
if no rDNS), then a second time for the IP. So that tool
wouldn't solve this particular problem.
-- Noel Jones
