Le 05/03/2011 16:32, Stan Hoeppner a écrit :
> 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
>
/^.*foo/
means "it starts with something followed by foo". and this is the same
thing as "it contains foo", which is represented by
/foo/
more generally
/^.*whatever/
is the same as
/whatever/
and looking at the other side:
/foo.*$/
is the same as
/foo/
so whenever you see /^.*xyz/ or /xyz.*$/, you know something is useless...
> 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
well, you know I know these:) we all got spam from these...
>
> 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.
1) first use IP ranges.
2) then domains (hash/cdb)
for example:
.alshamil.net.ae REJECT blah blah
because there is no point to try to match something like
auh-b113917.alshamil.net.ae
3) then use regular expressions, but only when IPs and domains aren't
the way to go.
> I was strictly thinking of a hash
> table full of IP subnets.
no. IPs and domains are different things.
> 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.
depends what we talk about. don't forget that the constant in O(N) may
be too large, that is O(N) applies when N is very very large (for
example 345*N is O(N) but is still less than N^2 for small N).
> And doing this with a CIDR would likely be smaller than hash or
> cdb as well,
cidr is about IPs. hash/cdb/pcre is about names. these are different
things and you know that. use each as appropriate.
> 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.
if the ISP makes it too much, then you should reduce it:
.embarqhsd.net REJECT blah blah
>
>> a "better" example would be
>> /(\W\d+){4}\..*\.embarqhsd\.net$/ REJECT ...
>
> "Better" in what way?
in the sense that this can't be represented using hash or the like.
> 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. :)
>
I believe
.embarqhsd.net REJECT blah blah
is better.
> Thanks in advance for the anticipated forthcoming regex education.
>
