On Monday, April 19, 2004, 5:01:01 PM, Mark Mark wrote: > What about Matt's comment, though?
>> AFAIK it's invalid to >> have a query to anything but '*.*.*.*.sc.surbl.org' or >> '*.*.*.*.ws.surbl.org', where *.*.*.* is an IP address in reverse >> order as per in-addr.arpa queries. > Was not the whole point to do lookups on things like > "domainundertest.com.sc.surbl.org"? If I have to find an IP address for > "domainundertest.com" first, then do a regular RBL lookup, it is no longer a > domain name lookup, really. Yes, that points out a couple important differences between SURBLs and other RBLs. You're correct that URI domain names found in message bodies should not get name resolution done on them before getting checked against a SURBL. That's already somewhat different from other RBLs, most of which tend to have numeric data which must be converted from names before use. For example mailserver.openrelay.com would need to be resolved into its IP address before it could be checked in most number-based open relay RBLs. Another difference (oddity?) of SURBLs is that they have both name and number entries in the same list. The idea is that if a numeric URI like http://1.2.3.4/ is found in an incoming message body, it's checked against the *same* SURBL list but with the octets reversed per RBL convention. So that URI would get checked against SURBL as 4.3.2.1.sc.surbl.org. Note that in both cases, whatever URI is found in a message is checked against the SURBL without any name resolution. In that sense the SURBL (and use of it) captures the data directly and without much processing (other than removing host names, randomized subdomains and other non-core stuff). I like to think it's being faithful to the data to do things this way, but other people have argued for splitting the names and numbers into separate lists. My arguments against that are that there are very few numbers in the data, so a numbers-only list would be small, and that this keeps a single query and single database of all the spam URIs. I'm sure good arguments can be made on both sides for splitting the list, but I think I'll probably keep it together. Jeff C.
