--On 5 June 2008 13:34:37 -0400 Chris Lewis <clewis(_at_)nortel(_dot_)com>
wrote:
John Levine wrote:
I'm not sure about this: "DNSBL providers SHOULD NOT be held
accountable in any way for the consequences of use of a DNSBL
applied in an un-intended way."
I believe that the example the authors had in mind is the Spamhaus
PBL, which lists IPs that shouldn't be emitting mail directly to the
net, but which can legitmately send mail by logging into a SUBMIT
server and relaying through there. A common config error on MTAs that
are both MX and SUBMIT is to check the PBL before senders have a
chance to log in, with the effect that roaming users can't send mail.
The more significant problem seems to be the destination MTA doing a
full tranverse of the received headers, and blocks legit email relayed
another ISP's mail server, because the origin is in the PBL (or some DUL).
Oh, well in these cases, the intent referred to is that of the user, not
the provider! That's the opposite of what I assumed was required.
These are both, probably, cases where the user didn't understand that their
configurations wouldn't achieve what they wanted to achieve. The provider's
intent is irrelevant here.
It might be useful to try to think of situations in which you _would_ want
the provider to be held accountable for a problem. I can only think of a
few situations:
(a) deliberate mischief on the part of the provider, for example knowingly
listing a host which doesn't match the listing criteria, or
(b) failing to take reasonable security measures to ensure that another
party doesn't do (a) above,
(c) failing to adequately document the listing criteria,
(d) substantially changing the listing criteria (because there is no
mechanism for alerting users - perhaps there should be) - instead, a new
list should be created.
Both (a) and (c) are present in the RFC, but (b) and (d) aren't. I think
they should be.
Perhaps the wording should read "DNSBL providers SHOULD NOT be held
accountable in any way for the consequences of use of a DNSBL, as long as
the DNSBL meets the standards of this RFC". Or perhaps that's implicit.
--
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg