This still breaks deliverability.
How?
A user writes an email and sends it to another user. The other user does
not receive the email. This means that deliverability is broken. The
DNSBL is an agent in preventing that delivery. To my mind, this deserves
some explicit discussion in the Security Considerations section. On one
hand, a misused DNSBL can wreak havoc, and on the other hand a
compromised DNSBL could block more email than an administrator wishes.
The draft presented by the ASRG was very weak in its discussion of
security considerations given the fact that a DNSBL is explicitly
designed to break email deliverability.
There is a diagram under Rights of a Sender vs Rights of a Receiver
which shows that the DNSBL modifies the behavior of the
Receiving mail
server. This is what I mean by "sitting in the middle of an
end-to-end
(sender to recipient) email transaction.
At the desire of the receiving mail site's administrator.
That is irrelevant. The fact is that it does sit in the middle and the
implications of this should be clearly documented.
And is not unique to DNSBLs. Any sort of spam filtering
modifies the behavior of the receiving mail server.
But that would be a topic for another RFC which should also have
a substantial Security Considerations section.
There are a number of reasons to document something in a standards
document. One is to help people build compatible implementations of
a protocol. Another is to help operators of the protocol interoperate.
But it is also to provide a clear description of the protocol so
that others can improve on it in the future, or replace it entirely
with a superior architecture.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf