> > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf