On 7/7/2011 10:14 AM, /dev/rob0 wrote: > On Thu, Jul 07, 2011 at 08:24:42AM -0500, Noel Jones wrote: >> On 7/7/2011 7:48 AM, /dev/rob0 wrote: >>> On Thu, Jul 07, 2011 at 06:44:49AM -0500, Stan Hoeppner wrote: >>>> On 7/7/2011 5:58 AM, /dev/rob0 wrote: >>>>> The anchors at both ends mean you are safe. You start with ^ >>>>> and end with $, so nothing else can sneak in between those. >>>>> >>>>> A simpler expression to accomplish the same thing: >>>>> /^[0-9\.]$/ DUNNO >>>>> In English, that says: match a string which contains nothing >>>>> but numerals and dots. It matches nonsense strings such as >>>>> "...", but would be safe as per your intent to only match >>>>> bare IP addresses. >>>> >>>> With that being right anchored, the last character it attempts >>>> to match is a dot, no? See a problem there? >>> >>> The last character before $ is in fact "]" which closes the >>> bracket expression defined by the opening "[". Read up on >>> character classes and bracket expressions. >> >> what rob0 meant was >> /^[0-9.]+$/ DUNNO > > Oh yes, thank you Noel, and I'm sorry for that. Posting too early, > before coffee. :) At least my mistake was harmless, as it matched > only single-character strings: ".", "4", et c. While such strings > might be possible in PTR values, they are not possible in forward- > confirmed reverse DNS hostnames. Unless using some alternate root, or > other crazy DNS kludge. > >> For those following at home, the + means "one or more >> occurrences of the proceeding", and "special character" rules >> are different inside character class brackets, so don't escape >> the period with a backslash. As originally presented, the >> expression will match a single character string consisting of >> any number, a backslash, or a period. >> Rob knows all this as well as anyone, but the syntax is arcane >> and easy to mess up in quick postings. > > Don't give me too much credit! :) I actually thought the backslash > was still a metacharacter in the bracket expression. Um, > http://www.pcre.org/pcre.txt says it is, but I am not sure how it > would be interpreted when a non-metacharacter such as "." follows. > > A quick test with postmap indicates that the lone backslash is > ignored. > >> This (corrected) expression would also match an all-numeric >> string, or a phone number in the fairly common 123.456.1212 >> format. I don't know if such strings ever show up in reverse >> hostnames (certainly never with check_client_access, but maybe >> with check_reverse_client_hostname_access). Probably better > > Right, I'd be inclined to want to block a PTR of "123.456.1212" if > using check_reverse_client_hostname_access. > >> to stick with the well-tested >> /^([0-9]{1,3}\.){3}[0-9]{1,3}$/ DUNNO > > Probably so, and thanks again.
You guys know regex/pcre far better than me, and I'm glad I asked before implementing the IPv4 bypass. I decided to implement the expression that I originally posted, which Noel repeats above, but the discussion of alternatives was both educational and valuable nonetheless. Thanks to everyone who participated. -- Stan
