Támogatás keresése

Kerülje el a támogatási csalásokat. Sosem kérjük arra, hogy hívjon fel egy telefonszámot vagy osszon meg személyes információkat. Jelentse a gyanús tevékenységeket a „Visszaélés bejelentése” lehetőséggel.

További tudnivalók

A témacsoportot lezárták és archiválták. Tegyen fel új kérdést, ha segítségre van szüksége.

Thunderbird is not connecting to SSL servers on new machine

  • 11 válasz
  • 1 embernek van ilyen problémája
  • 13 megtekintés
  • Utolsó üzenet ettől: me163

more options

Hello! After installing Thunderbird on a new machine and copying over data folder, the app is not connecting to SSL servers. Connection is fine via plaintext. I have gathered debug logs from POP3 on both machines (gathered more or less on the same time).

Old one (working fine): [(null) 22384: Main Thread]: D/POP3 [this=1553F580] LoadUrl() [(null) 22384: Main Thread]: D/POP3 [this=1553F580] Initialize() [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Connecting to server SERVERNAME:995 [(null) 22384: Main Thread]: D/POP3 [this=1553F580] Setting server busy in nsPop3Protocol::LoadUrl() [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering NET_ProcessPop3 38 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 1 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 2 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 4 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] RECV: +OK Dovecot SERVERNAME ready. [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 28 [(null) 22384: Main Thread]: D/POP3 [this=1553F580] SendCapa()

New one (in UI connection hangs): 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] LoadUrl() 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Initialize() 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Connecting to server SERVERNAME:995 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Setting server busy in nsPop3Protocol::LoadUrl() 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering NET_ProcessPop3 0 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering state: 24 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering state: 25 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Clearing server busy in POP3_FREE 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Clearing running protocol in POP3_FREE 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] ~nsPop3Protocol() 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 sink: [this=2B896820] Calling ReleaseFolderLock from ~nsPop3Sink 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 sink: [this=2B896820] ReleaseFolderLock haveSemaphore = FALSE

I have also connected manually through openssl s_client library on new machine and it works fine so I am running out of ideas. Please advise!

Hello! After installing Thunderbird on a new machine and copying over data folder, the app is not connecting to SSL servers. Connection is fine via plaintext. I have gathered debug logs from POP3 on both machines (gathered more or less on the same time). Old one (working fine): [(null) 22384: Main Thread]: D/POP3 [this=1553F580] LoadUrl() [(null) 22384: Main Thread]: D/POP3 [this=1553F580] Initialize() [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Connecting to server SERVERNAME:995 [(null) 22384: Main Thread]: D/POP3 [this=1553F580] Setting server busy in nsPop3Protocol::LoadUrl() [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering NET_ProcessPop3 38 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 1 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 2 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 4 [(null) 22384: Main Thread]: I/POP3 [this=1553F580] RECV: +OK Dovecot SERVERNAME ready. [(null) 22384: Main Thread]: I/POP3 [this=1553F580] Entering state: 28 [(null) 22384: Main Thread]: D/POP3 [this=1553F580] SendCapa() New one (in UI connection hangs): 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] LoadUrl() 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Initialize() 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Connecting to server SERVERNAME:995 2020-10-04 17:49:56.504000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Setting server busy in nsPop3Protocol::LoadUrl() 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering NET_ProcessPop3 0 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering state: 24 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: I/POP3 [this=326C5740] Entering state: 25 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Clearing server busy in POP3_FREE 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] Clearing running protocol in POP3_FREE 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 [this=326C5740] ~nsPop3Protocol() 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 sink: [this=2B896820] Calling ReleaseFolderLock from ~nsPop3Sink 2020-10-04 17:49:56.642000 UTC - [(null) 7460: Main Thread]: D/POP3 sink: [this=2B896820] ReleaseFolderLock haveSemaphore = FALSE I have also connected manually through openssl s_client library on new machine and it works fine so I am running out of ideas. Please advise!

Kiválasztott megoldás

It would help if you name the server, so we can check its TLS version. The TLS may be OK, but maybe it's caused by the 'self-signed certificate' bug.

I would also try a new profile, in case copying the old one introduced some unknown factor. Help/Troubleshooting, about:profiles, create a new profile and add an account.

Válasz olvasása eredeti szövegkörnyezetben 👍 0

Összes válasz (11)

more options
more options

Unfortunately it doesn't. After degrading TLS version the problem still occurs.

more options

Run in Windows safe mode to test if a startup app such as security/AV is interfering with secure connections (such as Bitdefender, Kaspersky etc. are known to do).

more options

Hi sfhowes, Unfortunately I can't run this setup in safe mode as then WiFi doesn't work (including "Safe mode with networking" option). However I was doing trials with disabling AV system - doesn't help. I am also using the same AV system (ESET) on the old machine.

I am fairly confident that problem lays in Thunderbird itself, but I have no clues where to look for it.

more options

I think you may be able to run in safe mode with networking through wifi by following these instructions.

Changing security.tls.version.min may not be sufficient, if that's the cause:

https://support.mozilla.org/en-US/questions/1295861#answer-1349690

more options

Hi sfhowes, Thanks for linking this post, but unfortunately still no success :( I've set both options (security.tls.version.min to 1 and security.tls.version.enable-deprecated to true) and still no success.

Is there any way to debug SSL connection to see where it hangs? I was trying to play around with logging levels and modules, but I couldn't isolate something that would be helpful for my case.

more options

Kiválasztott megoldás

It would help if you name the server, so we can check its TLS version. The TLS may be OK, but maybe it's caused by the 'self-signed certificate' bug.

I would also try a new profile, in case copying the old one introduced some unknown factor. Help/Troubleshooting, about:profiles, create a new profile and add an account.

more options

That was peculiar...

I have tried once again - no luck. I have created new profile - it works! So I got back to my profile to compare settings - no difference. And then I tried to fetch mails on my old profile - it worked. Not sure what got changed - I am fairly confident I haven't changed anything between then and now, but it started working after this attempt with new profile... Thanks for everyone involved!

more options

Glad to hear it's working. I suspect ESET did a silent update that corrected its settings.

more options

Are you back to the default TLS version settings in tb?

more options

gd_smith That was also my first suspect after seeing connections passing through, but I double checked - I am on defaults now