My issue with sending emails
I've been using Thunderbird(TB) for 3-4 years with a couple email addresses and it has served me well so far.
Last year, I've moved my email address over to Google's Gsuite service and when sending emails sometimes I'd get an error that TB could not login to Gmail.
So then I'd login and enable the "unsecure" "Access to less secure apps" to ON.
However, Google turns this off if it thinks you're not using it, eg not sending emails all the time. And there's no option to change this behaviour.
I was getting the same error as the poster on the mozilla forums.
Namely, the following error:
error message from send: Sending of the message failed. Failed due to unexpected error 80004005. No description is available. The message could not be sent using Outgoing server (SMTP) smtp.gmail.com for an unknown reason. Please verify that your Outgoing server (SMTP) settings are correct and try again.
What I've tried
On the linux version of TB, I went to Edit/Account Settings and had a look at my primary email's "Server settings".
The following is how the incoming settings are:
Server Type: Imap Server name: imap.gmail.com Port: 993 Username: whatever@mydomain.tld Security Settings: Connection Security: SSL/TLS Authentication method: OAuth2
All of this seem to have continued working since my email migration from OVH's email service.
On the Outgoing Server (SMTP) part of TB settings, I had my Gsuite labelled gmail settings configured as follows:
Description: Gsuite Server name: smtp.gmail.com Port: 465 Security & Authentication: Connection Security: SSL/TLS Authentication method: Normal Password User name: whatever@mydomain.tld
As per the first poster on the link above, I've changed Auth method to Oauth2.
Then proceeded to turn off "Access to less secure apps".
So now my updated SMTP settings look like this:
Description: Gsuite Server name: smtp.gmail.com Port: 465 Security & Authentication: Connection Security: SSL/TLS Authentication method: Oauth2 User name: whatever@mydomain.tld
So now I can happily send messages without getting the dreaded "unexpected error 80004005".