[SURBL-Discuss] Proposal to add some anti-phishing data to SURBL
jeffc at surbl.org
Tue May 4 04:17:04 CEST 2004
On Tuesday, May 4, 2004, 2:48:17 AM, David Hooton wrote:
>Jeff Chan wrote:
>> 1. Merge into ws: probably no specific code for phishing
>> 2. 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://18.104.22.168/ then 22.214.171.124 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
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.
More information about the Discuss