mouss wrote: > Bill Larson a écrit : > >> It's still load on the server or router I am giving plenty of time and >> announcing it where spam consious system admin should see it and have >> plenty of time to take action. > > > I understand, but the "positive response" way is somewhat harsh. > > can't you just make the ns record point to a silly entry?
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. 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? 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... > if you wanna go the "positive reply" way, why not start by publishing a new > dnsbl comprised of those who access your original dnsbl. this way, we can > block them (so they know quickly that they're doing something bad). of > course, this game may become recursive, so It's not a good idea. but I find > it fun:) 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. 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.
