Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

78.2.2 Update issue: Email account Security Settings rendered invalid

  • 31 antwurd
  • 2 hawwe dit probleem
  • 1 werjefte
  • Lêste antwurd fan maberly

more options

After realizing that I was not receiving emails that had been sent to me (over a period of 24 hours), my ISP tech support and I traced the likely cause to what may be a bug in the Thunderbird 78.2.2 update, that had installed itself on my computer exactly 24 hours earlier: the update had somehow rendered the ISP's email account Security Settings invalid, which prevented reception of incoming emails. The tech support had been receiving similar email malfunction reports from other users since September 10, 2020 -- which was when this update was first released -- and we tested the hypothesis by changing my Security Settings for this ISP email account to "none", which fixed the problem.

A security setting of "none" isn't ideal, so I would like to bring this issue forward to the Tbird tech team, to see if they are aware of it.

Thanks, in advance, for your support.

After realizing that I was not receiving emails that had been sent to me (over a period of 24 hours), my ISP tech support and I traced the likely cause to what may be a bug in the Thunderbird 78.2.2 update, that had installed itself on my computer exactly 24 hours earlier: the update had somehow rendered the ISP's email account Security Settings invalid, which prevented reception of incoming emails. The tech support had been receiving similar email malfunction reports from other users since September 10, 2020 -- which was when this update was first released -- and we tested the hypothesis by changing my Security Settings for this ISP email account to "none", which fixed the problem. A security setting of "none" isn't ideal, so I would like to bring this issue forward to the Tbird tech team, to see if they are aware of it. Thanks, in advance, for your support.

Alle antwurden (11)

more options

I think it support tls 1.2... TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes So my assumption is that TB is set with 3...

@maberly: can you check on about:config (*below instructions) what you have for security.tls.version.min? From the menu at the top right, go to Options. Scroll all the way to the bottom and click on Config Editor. Skip past the warning. Scroll down until you find security.tls.version.min (or paste security.tls.version.min to upper frame)

p.s. I can still see all your screenshots (3 till now). Did you removed them from each post? I see that on "not solved" topic the delete is on top-right corner - attached

Bewurke troch svlad2009 op

more options

Thanks, FfTh202009.

You are right -- it looks like Tbird v.78 is using TLS 1.3 -- here is what the Config Editor shows (please see attachment).

Re. previous screen capture attachments: if they don't contain personal/vulnerable info, I'm okay leaving them there, in case they help anyone else with a similar problem. Are they safe to leave?

Thanks again!

more options

Hmmm - according with kb.mozillazine value 3 means: TLS 1.2 is the minimum required / maximum supported encryption protocol. (This is the current default for the maximum supported version.) And that 3 should not be, IMO, the reason of this issue as long as the server from your screenshot support TLS 1.2... if you had 0 there it was an issue IMO.

If you can though - change that value to 2 and see if it's working. If not change to 1 and check again...

ref those pictures: is nothing about "you" there. It's only about the server to which you connect or scripts/path/etc.. irrelevant IMO (InMyOpinion)

Bewurke troch svlad2009 op

more options

Hi again, FfTh202009;

Very interesting: I did as advised:

  • changed the setting back to STARTTLS, and modified the config editor entry to 2: no change in behaviour;
  • changed the setting back to STARTTLS, and modified the config editor entry to 1: everything worked perfectly!

What does this mean?

Should I leave the config editor with this new entry, and continue using STARTTLS?

Worthwhile to let my ISP know about this change (and possible solution)?

Thanks!

more options

This is a temporary workaround at best, but by no means a solution. By changing the pref, you did allow Thunderbird to fall back to TLS1.0/TLS1.1, which has been disabled in TB78 for a reason.

That basically confirms the theory that TB TLS 1.0/1.1 deprecation is the problem. Have your email provider fix their TLS config. At the end of the day that will help everyone. Then don't forget to restore the pref you changed in TB back to it's default value.

If your email provider is unable or unwilling to fix their config, I'd look for a new email provider. The fact that they still do allow access to their server in the clear is already bad enough.

more options

KB say 1 -> TLS 1.0 is the minimum required / maximum supported encryption protocol. That's strange as on some test that I've made for that server for ssl - that server should support 1.2 If this it's on "your" server side then that sever settings should be corrected as tls 1.0 is not "safe" anymore so it's not recommended anymore (probably that's why TB has increased minimum required as TLS 1.2 by default)

Anyway, leave it like this (STARTTLS and 1 on those settings) as it is much better and secured as "none" and maybe other user here will try other recommendations. And yes, as christ1 mention, if the email provider confirm you that they have updated their server then you should change that value back to 3

Bewurke troch svlad2009 op

more options

Thank you both! With the config editor setting set to "1", I'll use my email account setting as STARTTLS for the time being, but will reset the config editor to its default "3" once my ISP has update their own TLS appropriately.

Both my ISP -- and I ! -- thank you for this workaround!

more options

I use Thunderbird at work and home. No issues at my office but noticed this morning that I was not receiving emails on several accounts (all pop3) similar to issue above. I changed the security to NONE and all my email are now coming thru. This seems to be a temp fix until my provider fixes on their side. A variation of Squirrel mail. Also no issues sending, just receiving.

more options

Nancy, the "none" setting is a workaround - one that was also originally suggested by my ISP. However, as you can read (above), a slightly better workaround involves changing Thunderbird 78's config editor so that it will accept TLS v.1.0 rather than its default of TLS v.1.2 (I hope I'm conveying this properly!). This better workaround was kindly suggested by FfTh202009, at 10:45 am today (see above, please).

This has allowed me to reset my Tbird's security setting to STARTTLS again. However, even this workaround should be a temporary fix -- the solution is to have one's email server update their TLS to the most current version, and to then return one's config editor's setting to "3" again.

If I have correctly understood the advice I received from this forum, the way to change Tbird's config editor so that it allows one to use the security setting of STARTTLS (rather than "none") is as follows: * in Tbird, go to Tools/Options * scroll to bottom * click on Config Editor * Skip warning * scroll down to “security.tls.version.min” * the default value for this (for Tbird v.78) is “3”. * change the “3” value to “1”

Good luck, should you try this "better workaround"!

more options

maberly said

Nancy, the "none" setting is a workaround - one that was also originally suggested by my ISP. However, as you can read (above), a slightly better workaround involves changing Thunderbird 78's config editor so that it will accept TLS v.1.0 rather than its default of TLS v.1.2 (I hope I'm conveying this properly!). This better workaround was kindly suggested by FfTh202009, at 10:45 am today (see above, please). This has allowed me to reset my Tbird's security setting to STARTTLS again. However, even this workaround should be a temporary fix -- the solution is to have one's email server update their TLS to the most current version, and to then return one's config editor's setting to "3" again.

Just to clarify this, Microsoft, Google, Mozilla and Apple released a joint intention to cease supporting TLS versions less than 1.2 in 2018. So your provider is actually about 2 years behind the times if fixing this particular issue. Ads to this that TLS V1.2 was released as the "Newest" version in 2008 and was superseded by V1.3 in 2017.

So the real issue is that your provider has not implemented any of these newer versions. Versions that have been out for more than a decade. Despite 2 years of notice that they were going to be disallowed they did nothing.

What I am observing is many providers fixed their web servers, but failed to understand that mail servers were included inn the deprecation of the protocol versions.

I would actually suggest using NONE until your provider can get around to fixing the issue as it is easy to forget you compromised security with a hidden preference. Using none also leaves you aware of the problem so you follow it up. The speed at which the fix the issue might be relevant in deciding if their actually meet your needs as a provider.

It is also true that Thunderbird does a pretty awful job of providing feedback as to what the problem is. The developers are, as I understand it, working to fix that amazing deficiency.

more options

Thanks for this important background, Matt!

I live in a sparsely populated, rural area, where we are lucky to have anything even resembling high-speed internet service (all delivered via line-of-sight wifi towers), so we aren't in a position to shop around. Nevertheless, I'll pass your background information on to my ISP, in case they haven't been aware that mail servers also had to be updated accordingly. (They've told me that they hope to have the issue fixed within two weeks.)

  1. 1
  2. 2