In message <200811112303.SAA05532@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, der Mouse write s: > >> Furthermore, you appear to think that all DNSBLs are reactive in > >> nature. This is not true; there are at least a few DNSBLs that > >> proactively list "large indistinguishable pool" addresses. In at > >> least one case, the pools are submitted to them by the providers > >> that run the pools. Using such a list puts a substantial crimp in > >> direct-to-MX spamming. > > And the providers lie in those list. [...port-25-block removal which > > doesn't remove from the DNSL data...] > > Time to switch providers, I'd say. But in any case, that's the fault > of the provider in question, not of the DNSBL, or of DNSBLs as a class. It a fault of *both*. The DNSBL operator should be trying to get good data and when it knows the data is bad it should pull the data and/or request the the provider fix the data it is sending. Both parties need to be accountable. > The DNSBL is doing just what it told its users it would do - list > blocks reported to them by providers - and your issue, as reasonable > and serious as it is, is between the provider and you, or the provider > and the DNSBL, depending on and who's made what claims to whom and > which way you prefer to squint your mind. > > Unless that _isn't_ what the DNSBL tells its users it will do.... > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse@xxxxxxxxxxxxxxxxxxxx > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf