mouss put forth on 3/5/2011 7:20 AM:
> Le 05/03/2011 00:18, Stan Hoeppner a écrit :
>> /^.*\.(dyn|dhcp)\.embarqhsd\.net$/ REJECT Please use ISP relay
>>
> you can simplify that:
> /\.(dyn|dhcp)\.embarqhsd\.net$/ REJECT Please use ISP relay
>
> more generally /^.* is never needed.
Does this expression correctly match a longer string when used as:
check_reverse_client_hostname_access pcre:/etc/postfix/foo.pcre
The actual FQrDNS strings in my example network will be of the form:
fl-65-40-2-201.dyn.embarqhsd.net
tx-67-232-101-101.dhcp.embarqhsd.net
I was of the impression that a preceding wild card is required if not
using fully qualified expressions, but simply trying to match only a
substring at the back end of the line.
> anyway, this example is too simple and can be replaced with 2 cdb entries:
> .dyn.embarqshd.net REJECT ...
> .dhcp.embarqshd.net REJECT ...
I just realized I erred in my original thought process leading to my
example. I started out thinking of banning blocks of IPs, and how using
a PCRE matching rDNS patterns can shrink an equivalent IP subnet hash
table or CIDR table dramatically. I was strictly thinking of a hash
table full of IP subnets. For some reason using host names in a hash
table slipped my mind (hand to forehead). One could just as easily do
this with hash table. So yes, this wasn't the greatest example. A
better example would have been an ISP that uses goofy multiple rDNS
conventions, possibly due to mergers, etc, such as:
10-1-2-3.dhcp.[state-abbr].isp.net
10-2-3-4.dyn.[city-name].isp.net
10-3-4-5.res.[state-abbr].isp.net
10-4-5-6-dynamic.[city-name].isp.net
etc
A PCRE table would definitely have a smaller memory footprint (the
current thread focus) in this example than an equivalent hash or cdb
table. And doing this with a CIDR would likely be smaller than hash or
cdb as well, given the number of cities and states that such as ISP
would be operating in, which would kick the total number of rDNS
patterns into the hundreds.
> a "better" example would be
> /(\W\d+){4}\..*\.embarqhsd\.net$/ REJECT ...
"Better" in what way? Does this get processed using significantly less
cycles or with significant memory footprint savings? Your example is
incomprehensible to non regex experts (myself included). I had to hit
my regex docs to understand this syntax choice. Non experts at least
have a fighting chance at deciphering my original example mouss. :)
Thanks in advance for the anticipated forthcoming regex education.
--
Stan
