> Huh? Concrete, real example: I send a message to an IETF > mailing list. > 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 email. > 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 > infrastructure. 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. --Michael Dillon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf