"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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg