-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
gep2(_at_)terabites(_dot_)com wrote:
Also, and I should have replied to that other message earlier, but on
the same lines, there was a question about when an RBL blacklisting
should expire. I would think a listing should expire some number of
hours after the last such bogus message was seen coming from that
host.... rather than having to be removed manually. (And the reset
delay could, for example, be increaed each time a subsequent infected
message from that address (or, better, machine) is seen.
The CBL expires entries. Fairly quickly at that, but not quick enough
in the case of critical email. But you didn't notice that you could
remove an IP from the CBL on demand, did you?
The CBL is, as far as I can tell, in full compliance with the BCP and
then some. If you had followed the instructions on their web page, you
could have solved the problem completely in an hour or two, not many days.
Now, if it had been other less-BCP-compliant DNSBLs, such as BLARS or
SPEWS, getting out of them would be very difficult, and in fact
impossible in the case of BLARS.
Hence, the value of the BCP.
But again, NAT makes blocking a NAT router a terrible idea (and worse,
depending on how many machines are downstream from that router).
Yes, it's a terrible idea. But once you identify that an IP is sending
malicious content, it's an even more terrible idea to continue to allow
it to do so. And if you _do_ continue to allow it, even if you do
manage to swat the malicious content itself letting the good content
through, there's no incentive to fix the problem.
There are plenty of providers out there who will do _nothing_ to solve
malicious emitters unless you give them some pain.
Yes, DNSBLs like the CBL are reactive. But not all DNSBLs are reactive.
The PBL isn't for example.
Yes, it would be nice to prevent the malicious content being sent in the
first place - that's in your (or your customer's court), because they
didn't. If the proactive measures fail, which they did, then, reactive
is what's left.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
iQCVAwUBRexNu53FmCyJjHfhAQJ+RgQA8gw1r8raSsECBkNvMLvv9sKTf+buz0K0
ZyWSTnunnwJ7uM3jn6RJ48adOCybxEffEr7MyAEXTm961ooc8c/Trta3+2pguIca
LD89uyZZy5b18KjIQnwMT18H1yh80zGWMWX46OpaS+OhCo7Px69W4Yv1xJuY1lX4
8L65NzNC9kE=
=7VqC
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg