I have been using ClawsMail for my Verizon email (now hosted by AOL via imap.aol.com) for years and have had no issues. A few days ago, Clawsmail started failing to connect to the imap.aol.com servers and the only error in the Network Log is: *** SSL/TLS handshake failed This is occurring on all 3 of our computers which are all running ClawsMail on Windows 10. The IMAP configuration has not changed, however, I verified that it was still correct. At first I thought that the Verizon/AOL servers might be having a problem however, connecting via IMAP to the Verizon email on the SAME computer using a different email program works fine as well connecting via IMAP via my phone and tablet. The only place it is failing is when using ClawsMail (which worked flawlessly up until a few days ago.). The claws.log does not have any additional details. So the problem appears to be clawsmail specific. What can I do to debug the problem further? Thanks!
Here's an update on this problem. Using the python sample code found here https://www.tutorialspoint.com/python/python_imap.htm After modifying the code to use my verizon email credentials I am able to connect to imap.aol.com and successfully retrieve email. So this is another example of IMAP working fine except when using ClawsMail.
A few other things I've tried Changing the SSL config from SSL/TLS to StartTLS (which has not been needed in the past) UnChecking the "Use non-blocking SSL/TLS" setting It still fails after trying both of those settings. When StartTLS is selected there is a longer delay before the failure message occurs, whereas when it is set to SSL/TLS the failure is almost immediate.
"What can I do to debug the problem further?" Are you running with logging at debug level? If not, that might be worth a try. https://www.claws-mail.org/faq/index.php/Claws_Mail_on_Windows
(In reply to comment #2) > A few other things I've tried > > Changing the SSL config from SSL/TLS to StartTLS (which has not been needed > in the past) > > UnChecking the "Use non-blocking SSL/TLS" setting > > > It still fails after trying both of those settings. > > When StartTLS is selected there is a longer delay before the failure message > occurs, whereas when it is set to SSL/TLS the failure is almost immediate. Have you tried to search for the certificate in Tools -> SSL/TLS certificates ? Perhaps remove the certificate and the readd it at next logon.
(In reply to comment #3) > "What can I do to debug the problem further?" > > Are you running with logging at debug level? > > If not, that might be worth a try. > > https://www.claws-mail.org/faq/index.php/Claws_Mail_on_Windows Thanks, I just tried that and reviewed the log. Everything seems to be working fine in the initial part that reads the files/etc up to the point where it makes the IMAP connection. Here is that part of the log imap.c:4824:getting session... message: Account 'Joe - Verizon': Connecting to IMAP server: imap.aol.com:993... imap-thread.c:447:found imap 000002915787E450 imap-thread.c:463:generic_cb imap-thread.c:447:found imap 000002915787E450 imap-thread.c:702:connect 43 with imap 000002915787E450 warning: [12:28:01] SSL/TLS handshake failed alertpanel.c:253:Creating alert panel dialog... alertpanel.c:211:called inc_lock (lock count 2) alertpanel.c:221:called inc_unlock (lock count 1) alertpanel.c:105:return value = 0 folder.c:2183:Scanning folder Inbox for cache changes. imap.c:4587:get_num_list imap.c:4597:get_num_list: nothing to update imap.c:4604:don't know the list length... imap.c:4623:getting session... folder.c:2187:Error fetching list of message numbers folderview.c:1260:called inc_unlock (lock count 0) file-utils.c:58:TIMING : 0s010ms I do't really see any addition details in that do you? Other things I've tried since your message were to setup a VM with a clean installation of Win10, install ClawsMail and config for the IMAP account to eliminate everything else config wise. That setup gets the same error. I just installed sylpheed on this machine and configured the verizon IMAP account and sylpheed works fine and does not have the issue so it appears that something with the SSL negotiation for ClawsMail only is having an issue. I also setup the Windows 10 email app for the Verizon IMAP and it works. And lastly I wrote a quick test program in Python using imaplib and it also connects to the verizon IMAP and that works fine. Basically everything except Clawsmail works and does not have the IMAP issues. It's weird that it just started happening as clawsmail has worked fine for years. I suspect that something is wrong in the negotiation phase that has to do with the getting the certificate. Since the clean install still fails with the error and since sylpheed works fine it definitely seems to be a bug in Clawsmail. What else can I do to assist in debugging and getting this addressed? Thanks for your help! Joe
(In reply to comment #4) > (In reply to comment #2) > > A few other things I've tried > > > > Changing the SSL config from SSL/TLS to StartTLS (which has not been needed > > in the past) > > > > UnChecking the "Use non-blocking SSL/TLS" setting > > > > > > It still fails after trying both of those settings. > > > > When StartTLS is selected there is a longer delay before the failure message > > occurs, whereas when it is set to SSL/TLS the failure is almost immediate. > > Have you tried to search for the certificate in Tools -> SSL/TLS > certificates ? > > Perhaps remove the certificate and the readd it at next logon. Hi Michael, Please see my detailed reply to DJH regarding additional debugging. The quick summary is that in a VM which is a clean install of Windows 10 and then installing Clawsmail produces the same error I reported. Also, installing sylpheed on the same machine works fine and does not get the IMAP error. I do think you are on to something though because in the Win10 clean install when I look in the Tools -> SSL/TLS certificates it does not have any, which to me indicates the point in the connection attempt where the failure is occurring. I just tried your suggestion and removed the Verizon certifications (that's all of the certifications so now there are none listed) and then ran clawsmail with --debug. Here is the relevant part of that debug log: imap.c:4824:getting session... message: Account 'Joe - Verizon': Connecting to IMAP server: imap.aol.com:993... imap-thread.c:447:found imap 0000025DA754C7C0 imap-thread.c:463:generic_cb imap-thread.c:447:found imap 0000025DA754C7C0 imap-thread.c:702:connect 43 with imap 0000025DA754C7C0 warning: [12:56:00] SSL/TLS handshake failed alertpanel.c:253:Creating alert panel dialog... alertpanel.c:211:called inc_lock (lock count 2) alertpanel.c:221:called inc_unlock (lock count 1) alertpanel.c:105:return value = 0 folder.c:2183:Scanning folder Inbox for cache changes. imap.c:4587:get_num_list imap.c:4597:get_num_list: nothing to update imap.c:4604:don't know the list length... imap.c:4623:getting session... folder.c:2187:Error fetching list of message numbers folderview.c:1260:called inc_unlock (lock count 0) file-utils.c:58:TIMING : 0s008ms So, it looks like the IMAP connection occurs imap-thread.c:702:connect 43 with imap 0000025DA754C7C0 but then when it attempts to get the certificate that fails which is why after testing out your suggestion there are no certificates installed. I know that clawsmail was forked from sylpheed and that they have gone off in their own directions now but possible the source code between the two could be reviewed for differences to see what is different and why sylpheed works and clawsmail stopped working? Are there any other things I can do on this end to help debug further or provide more details? Thanks for your help! Joe
I don't use Windows 10, but I've seen discussion elsewhere where people who do have mentioned that there's been a huge update to it (the sort that takes an hour or two to apply) in the last few days. Maybe Microsoft have broken something?
(In reply to comment #7) > I don't use Windows 10, but I've seen discussion elsewhere where people who > do have mentioned that there's been a huge update to it (the sort that takes > an hour or two to apply) in the last few days. Maybe Microsoft have broken > something? Hi Jeremy, I am suspicious of that too, however, both sylpheed and Windows Mail both work on the same machine using IMAP. I am running Win 10 v1903 build 18362.239 (latest patch level). I have been running Win 10 v1903 since 05/22/2019 and have pretty much installed the patches shortly after they became available. I would not be surprised if a Microsoft change is causing the issue, however, the fact that the other 2 programs are not getting the same IMAP issues seems to indicate that clawsmail will need to be patched one way or the other. In my opinion, based on the help of the others, it seems to me that the IMAP connection occurs and then when it tries to get the certificate that fails resulting in the handshake error. The big question is why is it failing to get the certificate when the other 2 apps are not? Thanks for chiming in... Joe
Since you are experiencing the problems on Windows and since the claws-mail build uses its own package version of gnutls/openssl it could be a problem with the packaged version of the SSL libraries. Doing: openssl s_client -connect imap.aol.com:993 displays a valid certificate which is verified ok here: SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 5D2B6C9A905659A34F1E039C76B2BA51FDF01D957A82017CB8B8E3700E6DFB55 Session-ID-ctx: Master-Key: 5E58A2710A0AE5E42209E64545514D9F83DD173DBAFD083DD3BD6CB453F7245B9D08C1D60CC5DA2E99D6DB528C613E27 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1563126938 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no I lean towards an incompatibility with the supplied SSL libraries with claws-mail but since I don't have windows here I cannot verify. imap.aol.com offers these signature algorithms: Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1 So if the supplied SSL libraries on Windows does not support those then it will fail to make a connection.
(In reply to comment #9) > Since you are experiencing the problems on Windows and since the claws-mail > build uses its own package version of gnutls/openssl it could be a problem > with the packaged version of the SSL libraries. > > Doing: openssl s_client -connect imap.aol.com:993 > displays a valid certificate which is verified ok here: > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES256-GCM-SHA384 > Session-ID: > 5D2B6C9A905659A34F1E039C76B2BA51FDF01D957A82017CB8B8E3700E6DFB55 > Session-ID-ctx: > Master-Key: > 5E58A2710A0AE5E42209E64545514D9F83DD173DBAFD083DD3BD6CB453F7245B9D08C1D60CC5D > A2E99D6DB528C613E27 > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1563126938 > Timeout : 7200 (sec) > Verify return code: 0 (ok) > Extended master secret: no > > I lean towards an incompatibility with the supplied SSL libraries with > claws-mail but since I don't have windows here I cannot verify. > > imap.aol.com offers these signature algorithms: > Requested Signature Algorithms: > ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA- > PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256: > RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1 > > So if the supplied SSL libraries on Windows does not support those then it > will fail to make a connection. Thanks for providing that debug step. In order to debug further and not muck with my real desktop I will continue debugging in a Win10 VM where the problem also occurs. I installed openssl in the VM and ran tried the openssl connection. Here are the results: openssl s_client -connect imap.aol.com:993 CONNECTED(00000180) depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = Sunnyvale, O = Oath Inc, CN = *.imap.mail.aol.com verify return:1 --- Certificate chain 0 s:C = US, ST = California, L = Sunnyvale, O = Oath Inc, CN = *.imap.mail.aol.com i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIH6jCCBtKgAwIBAgIQDllS2OQaxuxHWusAiIIoiDANBgkqhkiG9w0BAQsFADBw MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz dXJhbmNlIFNlcnZlciBDQTAeFw0xOTA0MjYwMDAwMDBaFw0xOTEwMjMxMjAwMDBa MGcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlT dW5ueXZhbGUxETAPBgNVBAoTCE9hdGggSW5jMRwwGgYDVQQDDBMqLmltYXAubWFp bC5hb2wuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs8Ou/gU8 pb3JJHgD403Rc2UPZQnRcFBO4gfq6IAV8uC11U3fLRld3opnE6mz3GGLiLFDRJ3W veKxBVYqVrg96rjviT0FW6CodH1EeB0pDl+LcDKaJkKVrJ8x00XBGP7Aev92aHlA keMn+RauoIaVTOD0nJ/ERD7dMrFOIIw5YFb4ahx1C3oFGTokIr1wjCaNjt1cOglb UQVO0eC03eBs2tlYoMTJ4GbqmuDYM/nGHztCXtN3OKEBTAL9yESjPSSd61p+f0Jx vDXkNSQGMOjUYXp9//vk5MU5L6Ee/j6sXyTZhPIY6ocgFz6qdWEAaJgrM0IWv/qm nZC1k6OXYFqVawIDAQABo4IEhzCCBIMwHwYDVR0jBBgwFoAUUWj/kK8CB3U8zNll ZGKiErhZcjswHQYDVR0OBBYEFBCUuo84NZebhc4qevAAHUh03TZfMIIBsAYDVR0R BIIBpzCCAaOCEyouaW1hcC5tYWlsLmFvbC5jb22CDGltYXAuYW9sLmNvbYIMaW1h cC5haW0uY29tggtpbWFwLmNzLmNvbYITY2xpZW50LmltYXAuYW9sLmNvbYIPaW1h cC5hdS5hb2wuY29tgg9pbWFwLmFyLmFvbC5jb22CD2ltYXAuYnIuYW9sLmNvbYIP aW1hcC5jYS5hb2wuY29tgg9pbWFwLmNsLmFvbC5jb22CD2ltYXAuZGUuYW9sLmNv bYIPaW1hcC5mci5hb2wuY29tgg9pbWFwLmluLmFvbC5jb22CD2ltYXAuanAuYW9s LmNvbYIPaW1hcC5teC5hb2wuY29tgg9pbWFwLnVrLmFvbC5jb22CDWltYXAubWNv bS5jb22CDmltYXAuZ29vd3kuY29tgg9pbWFwLnR1bm9tZS5jb22CFGVhc3QudXMu aW1hcC5hb2wuY29tghRpbWFwLmFuZ2VsaWFtYWlsLmNvbYIMaW1hcC5jc2kuY29t ghRwYXJ0bmVyLmltYXAuYW9sLmNvbYITZXhwb3J0LmltYXAuYW9sLmNvbTAOBgNV HQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1Ud HwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zaGEyLWhhLXNl cnZlci1nNi5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zaGEy LWhhLXNlcnZlci1nNi5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwBAgIw gYMGCCsGAQUFBwEBBHcwdTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl cnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNlcnZlckNBLmNydDAMBgNVHRMBAf8E AjAAMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDvAHYAu9nfvB+KcbWTlCOXqpJ7RzhX lQqrUugakJZkNo4e0YUAAAFqWoXcPgAABAMARzBFAiAXSSda8tVGfjLYzfB45u+b XSbsZOOpAaJcVuehWT4XDwIhAPF+pDeA8zX0kplGIv8mEKuoLKmApV7/j+MXBE7+ pkbzAHUAh3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFqWoXdZAAA BAMARjBEAiAq5Z5HTTZ72q7+5P9musKwIrC2/PhpbF+tzwwZm7e4IAIgMGJEegWi oTDi0bxUTQwQsugxA0M4czegAueq/6QYLjcwDQYJKoZIhvcNAQELBQADggEBAI/p 3LMJIOuOKMXpI3Gip8279IRBszAa4l83mQwbcSDP6MUy5ApQ4zomCfBp+jRu+tSv jTrUwx0fe8f/NrkK6hg1Ok0bIxVnEJl48sywAkBXdo6L6WRrNKdFWXNyGVAFL1+5 PoNuKKJHBgEWxu8koqHVWvtu78sDcnFAVl1LqgwRCCoanjkp65zSXE+XJvlFavI0 c3ljmVxderUbHHPFY35E7BYqgKQEy1VV59IkuETmEY03j4uak0XphsH77Q+1Yva3 wgRaIvrnwJ3b/oD4+YciftBoDn/zt6exmn8REVVO5yNtnWl1mozmEE4mK7ddErTq ScaLJHR59+36l9m54+0= -----END CERTIFICATE----- subject=C = US, ST = California, L = Sunnyvale, O = Oath Inc, CN = *.imap.mail.aol.com issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA --- No client certificate CA names sent Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4072 bytes and written 876 bytes Verification error: unable to get local issuer certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 20 (unable to get local issuer certificate) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 6ABD95BB3884364E2FDCD83CEAE91CD0B69840DA8DC29996ADACABC56FF8B21F Session-ID-ctx: Resumption PSK: DB2EDF24D8D9721D680AE6A6467E9D0A898A1631DB3B991D8ED7434840E27DE3010BBB3B8A12DA14F0EEE5A73193F39C PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 60 (seconds) TLS session ticket: 0000 - 29 4f f2 44 17 21 a4 11-2b e9 d9 6a 23 95 a3 52 )O.D.!..+..j#..R 0010 - 10 f3 fe 6b 01 b3 3a c6-d5 7c 58 8d 2f ef a5 ee ...k..:..|X./... Start Time: 1563128446 Timeout : 7200 (sec) Verify return code: 20 (unable to get local issuer certificate) Extended master secret: no Max Early Data: 0 --- read R BLOCK * OK [CAPABILITY IMAP4rev1 SASL-IR AUTH=XOAUTH2 AUTH=PLAIN CHILDREN ID LITERAL+ NAMESPACE UIDPLUS MOVE] IMAP4rev1 Hello Looking through those results the error seems to be here: verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, ST = California, L = Sunnyvale, O = Oath Inc, CN = *.imap.mail.aol.com verify return:1 SSL handshake has read 4072 bytes and written 876 bytes Verification error: unable to get local issuer certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 20 (unable to get local issuer certificate) --- Comparing the "Requested Signature Algorithms" in what you posted to what is in the results matches but "ECDSA+SHA1:RSA+SHA1" is missing from the "Shared Requested Signature Algorithms". I see that the SSL handshake is using TLS v 1.3 could that be the issue? I appears that your analysis is correct and that Clawsmail would need to update the supplied SSL libraries on Windows. Is this the proper channel to get that handled or do I need to report this elsewhere? THANKS!
I have changed bug report to reference windows version.
(In reply to comment #11) > I have changed bug report to reference windows version. Thanks, I thought I had set the platform to PC Windows 10. Is there a schedule as to when Clawsmail will update the libraries it is using for SSL which will hopefully address this issue? At this point Clawsmail is unusable since new mail cannot be retrieved. Thanks again for your assistance!
(In reply to comment #11) > I have changed bug report to reference windows version. I see that version 3.17.4 was released. Who prepares the Windows builds? Do we need to contact someone so that the new libraries can be included? Thanks!
(In reply to comment #13) > Who prepares the Windows builds? Do we need to contact someone so that the > new libraries can be included? That would be me. I have done some preparations for the Windows release over the weekend and plan to continue the work.
(In reply to comment #14) > (In reply to comment #13) > > Who prepares the Windows builds? Do we need to contact someone so that the > > new libraries can be included? > > That would be me. I have done some preparations for the Windows release over > the weekend and plan to continue the work. Great! Thanks for getting back to me and for your time and effort in addressing the issue.
Any update on the progress? Based on Michael's comments it sounded like this was just a recompile with the updated libraries. Have you found additional issues? Essentially ClawsMail on Windows with Verizon email is basically unusable until this is fixed. Thanks for time and effort in trying to get this resolved.
Has ClawsMail on Windows been abandon of no longer being developed or maintained?
Incidentally, a release was made just a few seconds ago. :) Sorry for the delay, but things keep getting in the way.
Ok, thanks. Downloaded and installed the new build and the problems are resolved. I assume it was the SSL libraries as previously discussed? Or did you run into some other issues too? Thanks again!
It was probably the fact that although the previous GnuTLS version supported TLSv1.3, it supported some earlier draft version of it, while the version shipped with our latest release supports the final version of TLSv1.3. I'm glad it works for you now.