it off to jail. The questions of when/whether/and to who bounces should be sent is a debate for spam-l or nanae. I don't know about that. Bounce handling is not a question of spam filtering. Spam or not is orthogonal to the issue of forged return path. There really should be nothing to debate, except in the context of a
On Sat, Feb 20, 2010 at 6:25 PM, Jon Lewis <jlewis@lewis.org> wrote: protocol discussion, as the current internet standards are pretty clear and specifically inflexible on how internet mail hosts must handle error conditions. Just like TCP rfc793 is clear on how internet mail hosts must handle connection establishment.
cache probably won't help. I know at least some of these orgs aggregate queries either per RIR assigned CIDR or per ASN, so spreading the queries out isn't likely to get you around the issue.
When contacted by the DNSBl, perhaps you inform the end-users to make DNSBL queries directly against DNSBL servers, directly from the mail server which is in their SWIP'ed IP range. There is little else you can do, isn't there?
So, do you pay, and setup your own local copy of the zones? Let them block your servers/network and let those of your customers who care make their own arrangements for continued access? That depends on the importance of the DNSBL.
Spamhaus' description of rsync datafeed service on their web site appears to be incompatible with an ISP setting up a local copy and allowing customers to query. When setting up a local copy of the zone, you pay by "Number of e-mail users". See the problem? As an ISP serving a local copy of the zone to customer mail servers, you don't know how many mailboxes they have. Maybe i'm mistaken, but it appears each end user has to buy the service for their own mail servers, and the ISP isn't allowed to bypass that. For the purpose of the agreements with spamhaus, an ISP customer is probably considered a third party, and making a rbldns server available to them is disclosing spamhaus' secret DNSBL zone information.... -- -J