[Asrg] draft-irtf-asrg-bcp-blacklists-01 March 24, 2008

[Frank Ellermann]

"Seth" wrote:
 
> Maybe the theory is "IP addresses owned by entities that don't kick
> off spammers are more likely to accumulate spammers than those owned
> by entities that do kick off spammers.  Therefore, since <company>
> didn't kick off the spammer at aaa.bbb.ccc.ddd, its other addresses
> are more likely to have spammers than most IP addresses (Bayes
> Theorem)."

IMO that's in essence what SM proposed, and from your questions my
impression was that you don't like to talk about this theory in the
BCP.  It's a good theory, and noting some known traps and pitfalls
with this theory for naive readers makes sense.

>> Maybe an explanation why simply progressing from listing the IPv4,
>> then the /31, and so on, is an oversimplification and at some
>> point doomed, is better.  With a note that "some point" can be
>> smaller or bigger than /24 depending on the IPv4.
 
> Maybe we shouldn't get into claiming that some policies are better
> than others, and only specify that the policy should be explicit
> and followed.

The "explicit and followed" is already covered in the draft, but
some limitations of /32, /31, are not obvious.  After all users
would get really no spam if they reach /0.  If that's not what
they'd do in their own BL they need to check how the policy of a
third party is "better" for what they want.  

I just answered a help request from somebody with no idea what an
IP is.  The BCP should have some things clear, if users are then
determined to reinvent say BLARS they should know the fine print.

> I think DNSBLs should be allowed to have whatever policies they
> want.  It's up to the user of the DNSBL to decide whether it
> has policies he wants to apply.

IMO it is the job of the BCP to allow users an informed decision.

E.g. a list mapping IPs to country codes is a cute idea, but can
be also a way to shoot into your foot if you use it to block mail
or firewall IPs.  Some problems aren't obvious.  The BCP could
list the well-known problems, which caused havoc in the past for
naive users.  

 Frank