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. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
