Yes, who can we ask about this problem?

Who is the mail provider, and what kind of error messages are displayed, e.g. 'peer using unsupported protocol'? What security apps are installed?

Thanks for responding, sfhowes.

The mail provider is my ISP, a local Canadian company that has been receiving similar reports of non-received mail by Tbird users since the day this update was first released.

No error messages at all were shown -- incoming email simply did not arrive. Outgoing email was never adversely affected.

If you mean security apps on my own computer, they are Windows 7 Firewall, Microsoft Security Essentials, and Spybot. None of these apps have ever interfered with Tbird email, and -- now that I have reset Tbird's Security Settings for this ISP email account to "none" -- it still doesn't interfere with it.

Is there anything in the error console? Ctrl-Shift-J

Thanks, christ1.

I didn't even know of the error console's existence, but now that I've checked it, yes -- there are many errors listed. I have made a screen capture of them, but not sure if it should be shared publicly in this forum. Any suggestions?

For trying to track the issue you should add such screenshots - after that any picture added can be deleted from this forum by you (you will have an X on top-left corner of that picture_

Thanks, FfTh202009.

I've attached that screen shot . . . tho' I have no idea how to interpret it.

Please note that this error console image was taken AFTER I had found a workaround that allowed me to again receive email messages (the workaround was to change the security settings / Connection security from its previous STARTTLS to "none").

You have on those logs ns_error_illegal_value, ns_error_file_not_found, ns_error_file_unrecognized_path and server does not support rfc 5746 First 3 should be caused by some extension(s) The last one I suspect is the issue for sending mails - and for that error I have found on this forum this answer:

It is a warning and harmless, if cluttering to the error console. It is not your issue, whatever it is. It is a warning your server does not support real security. But that is nothing important in the world of ISPs who refuse to do security as it complicates things and raises their support costs. As an indicator though, perhaps it indicates your anti virus having a fit. Try disabling email anti virus scanning and see if the error just stops. Can you try first to set back those settings (STARTTLS) and pause the anti-virus? If doesn't work try also to close completely that software and check again. If now it's OK it will be a good idea to mention what antivirus do you have

Thanks again, FfTh202009.

Very strange: I followed your instructions, closed my anti-virus software (MS Security Essentials), re-set my TBird setting to STARTTLS, and sent myself an email . . . and it arrived back within a minute.

So, to be sure, I then turned MS Security Essentials back on, left the TBird setting as STARTTLS, and sent myself another email . . . and it, too, arrived back within a minute!

This would seem to indicate that perhaps my ISP has changed something -- at their end -- since I reported this problem . . . Otherwise, it would mean that simply turning MSSE off and back on solved the problem, which seems highly unlikely.

Your thoughts on this?

and we tested the hypothesis by changing my Security Settings for this ISP email account to "none", which fixed the problem.

I wouldn't call that a fix, since you're sending your messages, including your password, in the clear, instead of protected by TLS encryption.

Presumably your email provider only supports TLS 1.0/1.1, while Thunderbird requires at least TLS 1.2 as of version 78. I'd expect the error console to show this, if this is the case.

FfTh202009, please ignore my last post! I have two email accounts with my ISP, and hadn't realized that I had done this last test (turning MSSE off, and resuming STARTTLS) with the second account's setting still as "none". When I later realized this, I retested properly, and saw that neither email account receives emails when their setting is reset to STARTTLS.

Thanks, christ1.

You have written something pretty important here:

                          ". . . Thunderbird requires at least TLS 1.2 as of version 78."

Since my problem only occurred after installing v.78, this sounds like a likely cause. Question: does this v. 78 requirement (of TLS 1.2) show up anywhere in the update documentation?

I'll contact my ISP to ask them about this!

Thanks!

It's in the release notes. https://www.thunderbird.net/en-US/thunderbird/78.0/releasenotes/

Hi again, christ1;

Just spoke with my ISP about this TLS version requirement; the front-line tech support person said that they are aware of a problem associated with the Tbird update to v.78, and are working on fixing the problem, but that only the administrators (who aren't available on the weekend) would know the cause.

At least a cause is now in view, and - hopefully - a solution will be at hand.

Thanks to you and to everyone else who took the time to answer my post -- I appreciate it very much!

When I later realized this, I retested properly, and saw that neither email account receives emails when their setting is reset to STARTTLS.

can you test again? First clear logs from console (you have a delete button) and after that press get mail (while STARTTLS is set for those accounts). With and w/o antivirus to see how this goes...

Yep, TB on official page mention TLS 1.2 minimum requirements

Thanks for the link, christ1!

You also wrote: "I'd expect the error console to show this, if this is the case."

I've re-uploaded that screen shot of my Tbird error console, in case you have a moment to see if that is mentioned.

Thanks again!

Hi again, FfTh202009. Just retested, as you requested, but no differences noted -- mail not received when account setting set to STARTTLS, but is received when set to "none". (Results not affected by MSSE being on or off.)

I've re-uploaded that screen shot of my Tbird error console, in case you have a moment to see if that is mentioned.

You'd need to reproduce the problem first, and then check the error console.

Thanks, christ1 -- done.

It may not be visible in the error console then.