Matt Kettler a écrit :
Really, that reduces the problem of network load on compu.net's servers, but it does nothing to make the misconfigured admins aware of the problem.
true...
I tend to strongly dislike the positive response method if done rapidly after shutdown. However, in this case there's 2 years of the RBL being down without the misconfigured admins noticing they aren't hitting anything? I mean, come on, don't you audit your RBLs more often than that?
depends on whom are you talking about. many nets are managed by people who copy/paste and forget. you may say these nets only get what they deserve and you may be right. now, if you take the view point of a sender who is blocked for no reason, or that of a recipient who doesn't know he's missing mail....
And I'm not talking SA rules here. There's never been a compu.net RBL query built into SA, so these are sites that hand-added compu.net to their MTA's. How often do you audit your MTA layer blocks, even if only by checking hitcounts? I do mine weekly with a small shell script, while that might be above average, I'd expect someone to notice that a RBL is not hitting at all in a 2 year span...
there are unfortunately many "howtos" using unsafe dnsbls as examples (or other unsafe tests). These get used. you, I and a lot of people here know this is silly, but we are a minority. one of the "funny" things I heard of was an asian network where anti-asian rule were installed, because the admin just copied howtos (now, this has nothing to do with asian people of course. it's just an example showing that "bad" things really happen).
Not to mention the net effect being really no better than just publishing a positive reply. A Positive reply will cut off all their inbound mail. They'll notice that pretty fast.
Yes, but I still want to get the list of those who use obsolete lists...
A new DNSBL will cut off their ability to send mail to a few domains, which they'll eventually notice. In the meantime it increases load on compu.net even further, and has the recursive problem you mentioned.
I think something is needed in the dnsbl "api". something like "if list is dead, all results are 255.255.255.255". this way, dnsbl lookup tools/libs/... can issue warnings to tell people to stop (or could recompile the kernel and install a new one:).
but as you say, may be a "positive response" is the right way...
