>Can we also conclude that SSL/TLS has failed as a tool for general >communication? If we were holding it to the same requirements that some appear to be asking for DKIM, I think we'd have to. There is a certain amount of SMTP over TLS, an entirely automated application, and the net hasn't collapsed. I experimented with it for a while before concluding that I didn't care about the threats against which it defends, and was surprised how many SMTP hosts do TLS when given the chance. People have figured out reasonable ways to deal with TLS errors, ranging from dropping the connection if it's suppposed to be part of a private mail network to logging and ignoring the errors if it's regular mail. If they set up their regular mail servers to drop connections on TLS failures, they'd lose a lot of mail. So they don't. I don't see any reason to assume that mail admins will be any worse at dealing with DKIM errors than they are with TLS errors. So as I said several messages ago: >I really need clarification of why DKIM RFCs need to tell people about the >dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't. >Since we will certainly be seeing more anti-spam and anti-phishing >proposals, what would be really useful would be a metric to decide when a >future proposal is more dangerous like DKIM and requires warning language, >or is less dangerous like the other three and doesn't. R's, John _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf