On Tuesday, May 4, 2004, 2:48:17 AM, David Hooton wrote:
Jeff Chan wrote:
- Merge into ws: probably no specific code for phishing
- Merge into combined list: could have a separate code
2a. (With no separate list for phishing if it's small.)
I personally think 2 is the preferred option as it provides domain & netblock owners with a possible means of becoming unlisted. Further helping us remove false positives and mopped up incidents as soon as we can.
As soon as the domains come off your list, they will come out of the SURBL. IOW the SURBL is built dynamically from your domain list.
That said, processing things here automatically may be a bit quicker than going through Bill's more manual procedure. Maybe I should assume we will do the merging here.
Also I'm somewhat concerned about "netblocks" going to SURBLs for a couple reasons:
1. SURBLs are largely domain name based. They're meant to block domains (or IP addresses) appearing in URIs. They're not meant to block resolved domains, sender domains or mail sender IP addresses. Remember that there's no name resolution being done on the client side. A domain in a URI will ***not*** be resolved into an IP address. If the URI has an IP address like: http://1.1.1.1/ then 1.1.1.1 is what should be checked against the SURBL. In other words SURBLs are used to check whatever happens to appear in the URI, where that's most often an unresolved domain name.
2. Address blocks imply more than one address, i.e. networks. SURBLs so far have not included any networks, only the occasional web hosting IP address mentioned above. It is possible to list blocks in various limited ways, and that may be useful for SURBLs to do in a few cases, but we have not done so because it doesn't fit the model above as well as it does for purely number-based regular LHS RBLs.
3. Address blocks also imply a range of addresses, where SURBLs generally have listed a few individual addresses that spammers are foolish enough to use in their spam URIs. Those are a very small minority of cases. Our approach is more specific, perhaps a little too specific to deal with a few cases, but that's how it was built.
As far as creating additional SURBL's go, I think the less lists kept overall the better, it's much kinder on bandwidth & end users system performance.
Can you give us an idea of how many records might go onto the list? I realize all the data feeds may not be up and running yet, but a general idea could be useful.
Jeff C.