On 1/12/16 6:20 AM, Claus Assmann wrote:
! 1. Introduction
! ...
! messages. In this application, TLS is used only upon mutual
! agreement (successful negotiation) between the client and server; if
! this is not possible, the message is sent unencrypted. Furthermore,
That's not the case for all MTAs. sendmail only recently introduced
an option to allow this:
To automatically handle TLS interoperability problems for outgoing
mail, sendmail can now immediately try a connection again
without STARTTLS after a TLS handshake failure.
This was triggered due to the decision of OpenSSL to enforce some
policy in the library without a simple option to override that and
the resulting delivery problems...
Before that, mails would get stuck in the queue and hopefully get
the attention of a postmaster to fix the interoperability problem.
That's good to know, but isn't quite the situation the draft was trying
to describe. The "negotiation" intended here was support for STARTTLS
itself. If the server MTA doesn't advertise STARTTLS in its EHLO
response, clients will generally just send mail without negotiating TLS.
Likewise, if the client MTA doesn't want to do STARTTLS, the server will
accept mail anyway. Similarly, the client will usually ignore failure of
the server's certificate to verify (other than to perhaps log this fact).
-Jim
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp