Blacklisting pool addresses

I have started a new thread (former subject "Qunatitative evaluation of
16 DNSBLs") because someone seems to have posted a novel in the
original thread.

Bill Cole writes:

>That's a bit problematic. It is likely that '.pool.' almost always
>means a dynamic address, but it is absolutely not the case for
>'.dsl.' because a lot of the small business accounts that used to
>go for fractional T1 or 56k FR or nailed-up analog modem links
>are now connecting via DSL and address allocation has gotten
>stingier. 10 years ago, it was common to get a /24 with mandatory
>rDNS delegation on any dedicated link, but today a small business is
>more likely to be given a /29 and rDNS only if the they demand it on
>their DSL link.

>It is certainly true that 'generic' rDNS is a very strong (99%+)
>indicator that any mail offered from that address is spam (including
>wormmail) but unfortunately a lot of sites cannot follow a rule that
>gives bad results on the order of 0.01% of the time.

OK, that suggests not listing complete blocks. But if an individual
entry in an apparent pool sources spam there are two possibilities (1)
It is a true pool and the address should be kept, or (2) it is not a
pool, and the address is the static address of a spammer or zombie.
Either way it seems the listing should remain for some considerable
length of time.

Let me repeat something I added to my piece at
http://www.nber.org/sys-admin/dnsbl=comparison.html

>There is a statistical principle which says that if your
>detector detects only a small fraction of events changes in the
>observed event rate are more likely changes in the detection rate
>than changes in the underlying event rate. That would suggest that
>removing an address just because it hasn't mailed to a spamtrap
>lately is probably not justified.

Now, I don't know how many spamtraps these 16 DNSBLs have, but if they
are in the tens of thousands, then the ratio of real addresses to
spamtraps is tens of thousands to one. Furthermore, the traps are not
evenly distributed, none are at my domain, for example. That also
reduces the overal efficiency of the detector and suggests keeping
apparent dynamic addresses on the blacklist even after the spam appears
to stop hitting the traps.

Anyway in the absence of an invitation to contribute to any of the
major DNSBLs, we are starting to keep our own blacklist, and we will
see how it turns out. I won't repost these arguments till I have some
evidence of how we do.

Daniel Feenberg
feenberg isat nber dotte org

Re: Blacklisting pool addresses

On Wed, 16 Mar 2005 drfremove@nber.org wrote:
> Bill Cole writes:
>
> >That's a bit problematic. It is likely that '.pool.' almost always
> >means a dynamic address, but it is absolutely not the case for
> >'.dsl.' because a lot of the small business accounts that used to
> >go for fractional T1 or 56k FR or nailed-up analog modem links
> >are now connecting via DSL and address allocation has gotten
> >stingier. 10 years ago, it was common to get a /24 with mandatory
> >rDNS delegation on any dedicated link, but today a small business is
> >more likely to be given a /29 and rDNS only if the they demand it on
> >their DSL link.

Not only is it, my mailserver does a lookup for the DNS PTR-RR and denies
access on the grounds that it is a dynamic assignment if those (".pool.",
".dsl.", etc...; about 15 in total) are present OR if the assignment has the IP
address in it: Forward or backwards, dotted or dashed. If they don't have
control over their own DNS, then it is a reasonable assumption to make that
they are a non-commercial DSL (or other, ISDN, cable-modem) user with a dynamic
assignment. Fixed IP DSL and others will generally have their own domain names
in DNS, even if they don't control it.

> >It is certainly true that 'generic' rDNS is a very strong (99%+)
> >indicator that any mail offered from that address is spam (including
> >wormmail) but unfortunately a lot of sites cannot follow a rule that
> >gives bad results on the order of 0.01% of the time.
>
> OK, that suggests not listing complete blocks. But if an individual
> entry in an apparent pool sources spam there are two possibilities (1)
> It is a true pool and the address should be kept, or (2) it is not a
> pool, and the address is the static address of a spammer or zombie.
> Either way it seems the listing should remain for some considerable
> length of time.

To me, it's either a dynamic assignment (in which they should be using their
ISP's outbound mail host(s) as a relay for only that system (i.e. the ISP) can
authenticate their own users), a spammer, or a poorly configured (and probably
rfc-ignorant) host that shouldn't be dealt with until it's set up properly.
Your position doesn't consider my third case explicitly.

> Let me repeat something I added to my piece at
> http://www.nber.org/sys-admin/dnsbl=comparison.html
>
> >There is a statistical principle which says that if your
> >detector detects only a small fraction of events changes in the
> >observed event rate are more likely changes in the detection rate
> >than changes in the underlying event rate. That would suggest that
> >removing an address just because it hasn't mailed to a spamtrap
> >lately is probably not justified.
>
> Now, I don't know how many spamtraps these 16 DNSBLs have, but if they
> are in the tens of thousands, then the ratio of real addresses to
> spamtraps is tens of thousands to one. Furthermore, the traps are not
> evenly distributed, none are at my domain, for example. That also
> reduces the overal efficiency of the detector and suggests keeping
> apparent dynamic addresses on the blacklist even after the spam appears
> to stop hitting the traps.
>
> Anyway in the absence of an invitation to contribute to any of the
> major DNSBLs, we are starting to keep our own blacklist, and we will
> see how it turns out. I won't repost these arguments till I have some
> evidence of how we do.

Don't forget that some governments are now getting involved - e.g.
for the U.S. (although our current anti-spam laws are a joke).