Re: mutt tls conection refused
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
Re: mutt tls conection refused
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). -- Sent from a phone, apologies for poor formatting. On 29 August 2020 18:59:41 Jan Stary wrote: 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: 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. 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
mutt tls conection refused
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: 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. 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
