From Viktor:
"There's a more compelling reason than stated why the extension is
not well suited to MTA to MTA SMTP. With MTA to MTA SMTP DANE is
opportunistic, (START)TLS is optional unless a requirement for
authenticated signalled via TLSA records.
Such signalled cannot be postponed to the TLS handshake, because
that handshake may not even take place unless the SMTP client MTA
knows that TLS is required. Even if TLS were to be used, authentication
is generally not required in MTA to MTA traffic, so the extension
would be vulnerable to MITM attacks.
Similar considerations apply to server-to-server XMPP traffic.
Thus the extension in question is only relevant with protocols
where TLS (with authenticaiton) is mandatory, and DANE is a
potentially attractive alternative PKI. With opportunistic DANE
TLS, the extension is inevitably too late."
From Viktor: "There's a more compelling reason than stated why the extension is not well suited to MTA to MTA SMTP. With MTA to MTA SMTP DANE is opportunistic, (START)TLS is optional unless a requirement for authenticated signalled via TLSA records.
Such signalled cannot be postponed to the TLS handshake, because that handshake may not even take place unless the SMTP client MTA knows that TLS is required. Even if TLS were to be used, authentication is generally not required in MTA to MTA traffic, so the extension would be vulnerable to MITM attacks.
Similar considerations apply to server-to-server XMPP traffic. Thus the extension in question is only relevant with protocols where TLS (with authenticaiton) is mandatory, and DANE is a potentially attractive alternative PKI. With opportunistic DANE TLS, the extension is inevitably too late."