Huh? Concrete, real example: I send a message to an IETF
A list subscriber's ISP rejects the forwarded message.
IETF's mailman drops the subscriber, because this has been
happened multiple times.
I can't notify the subscriber, because their ISP also rejects
My ISP is irrelevant to the scenario, and the (now former)
list subscriber doesn't even know this has happened, or why.
Another real, concrete example: some (but not all) messages
sent via my employer were tossed because one of my employer's
mail servers was listed on a blacklist. As an employee, I
had no alternatives for sending mail - company policy
precluded the use of "webmail" alternatives via company
This is the type of thing which should be discussed in a much
longer Security Considerations section, even if it is only
an informational RFC. A DNSBL sits in the middle of an
end-to-end email transaction, and there is a danger of this
type of mysterious man-in-the-middle effect. The issues
surrounding this should be openly disclosed in the RFC.
Many RFCs don't need more than a cursory Security Considerations
section, but this one does, partly because of its impact on
end-to-end email transactions, and partly because of its
overloading different meanings onto the DNS protocol.
If reputation systems are going to be an integral part
of the future Internet email service, then this existing
DNSBL needs to be properly documented, and it would be
fruitful to have a WG take on the task of designing something
that looks less like a temporary band-aid solution.
Ietf mailing list