Returning to this old thread, as my organization has moved its mailing to yet another monster (namely https://outlook.office.com).
The problem was actually the "smtps://" as opposed to "smtp://" https://unix.stackexchange.com/questions/66560/mutt-smtp-tls-error-sending-mail doscribes it as follows: When using smtp submission on port 587, the value for smtp_url should start with "smtp://", i.e. not with "smtps://". [...] A config option starting with smtps tells mutt to open a ssl encrypted connection to the server. However the server is expecting a clear text smtp session which transfers to become encrypted as soon as the client & server have done some negotiation. Indeed, this is what solved it: -smtp_url="smtps://$u...@outlook.office365.com:587" +smtp_url="smtp://$u...@outlook.office365.com:587" Perhaps this saves somebody some pain. Being able to use https://outlook.office.com in mutt certainly takes a lot of the pain away for me. It's actually mutt-sasl (they use SASL). Jan On Aug 29 22:02:45, s...@spacehopper.org wrote: > Strange as "openssl s_client -starttls smtp -connect mail.cvut.cz:587" works > for me, can you try that yourself in case there's any different config for > local clients and that fails for you? (It's also possible they have fixed > the server by now :-) > > LibreSSL doesn't support SSL, only TLS, so attempts to set SSLv2/3 won't do > what you want for sure. > > Compiling against OpenSSL is tricky, you have to make sure it uses the > correct headers (and sometimes relevant you have to avoid linking against > any library that uses LibreSSL). > > > This is mutt-1.14.6v3-sasl in 6.7-current/amd64. > > Recently, my institution's mail has been moved to > > 220 mail.cvut.cz Microsoft ESMTP MAIL Service > > > > Trying to send mail through it fails with > > > > SSL failed: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol > > version > > > > I enabled all the following to also enable the older ssl/tls protocols > > in case the server needs one that is not enabled by mutt by default > > as "tlsv1 alert protocol version" would suggest: I have removed all of these settings: > > set ssl_starttls = yes > > #set ssl_force_tls = yes > > set ssl_use_sslv2 = yes > > set ssl_use_sslv3 = yes > > set ssl_use_tlsv1 = yes > > set ssl_use_tlsv1_1 = yes > > set ssl_use_tlsv1_2 = yes > > set ssl_use_tlsv1_3 = yes > > > > It made no difference, the error message is the same. Clearly, this was not the problem. The "tlsv1 alert protocol version" error misled me. > > What's strange is that when connecting to the same server via IMAP > > (to read mail as opposed to send mail), mutt reports > > > > TLSv1.2 connection using TLSv1/SSLv3 (ECDHE-RSA-AES256-GCM-SHA384) > > > > and I can read my INBOX; that makes me think > > that ssl/tls connections to the server generally work. > > > > After rebuilding mutt from source --with-gnutls instead of --with-ssl, > > (and checking with ldd that it is indeed linked against gnutls and > > not linked against libssl and libtls), the error becomes > > > > gnutls_handshake: An unexpected TLS packet was received. > > > > Suspecting that the server might be discriminating on the > > exact version string (if there is such a thing), I also tried > > to compile against the openssl port, i.e. the ssl/tls in /usr/local, > > but I couldn't do it: the mutt build system alwasy picks the lib > > in /usr/lib, whoch is LibreSSL, not OpenSSL. > > > > Can I debug the details of the attempted tls connection? > > (Recompiling --with-debug and running with -d 10 doesn't reveal anything.) > > > > Is anyone seeing the same? > > > > Jan > > > > > > FWIW, with NetBSD's Mutt 1.11.4 (2019-03-13), the error is > > SSL failed: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > > protocol
