In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED]
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> Ietf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
