Thunderbird suddenly doesn't work for gmail ... any ideas?

Frank Slootweg wrote:

Mayayana wrote:
"Frank Slootweg" wrote

| Thunderbird pops up an error message. Post that full and exact error
| message.
|
Usually not helpful. I was trying to help someone
set up work email in TBird on Friday. First we were
trying the wrong server. (It's a college that uses
both gmail and office365 for their email.) Later there
was a passowrd problem. In all cases TBird's only
message was "Failed to log in."

But this (the OP) is a case where it used to work, not a setup issue.

With the (Gmail/Google) security issue, one gets a clear popup and a
clear e-mail message, but one will have to read that popup and login on
Gmail's *web*-interface, because if the issue is indeed security, the
e-mail message will be stuck in Gmail's inbox. Catch-22.

BUT, in the meantime the OP has indicated that he gets a time-out (and
(implicitly) that he is using IMAP, so should use OAuth2 in
Thunderbird), so a different scenario.

Using IMAP does not mandate using OAUTH2. TB can use either the
standard login process or use OAUTH2. The connection handshaking is
separate of the session process. Even if you have qualified using your
client with OAUTH2 doesn't mean the token(s) you get will survive
forever. They can expire at which point your client has to renogiate to
get another token. I don't know if TB is coded to do a token refresh
after the old one expires.

https://www.oauth.com/oauth2-servers...oken-lifetime/

Refresh tokens can be for any duration, not just the 2 weeks noted in
the above article. I've seen some implementations where the refresh
token is good for a year. While there can be non-expiring OAUTH2
tokens, just doesn't seem something Google would do. OAUTH2 is not
about increasing security as Google likes to pretend. It is about
tracking which host is attempting to use a service. OAUTH[1] was a
protocol. OAUTH2 devolved into a framework and a mess.

Other than deleting the Gmail account and recreating it again in TB, is
there a way in TB to force a refresh on the OAUTH2 token that it has to
get a new one from the server?

If the OP enables the "Allow less secure apps" option in his Google
account, he doesn't need to use OAUTH2. In fact, OAUTH2 is meaningless
with a normal login process. I suspect the OP could disable using
OAUTH2 in TB, check if IMAP works with normal login using TB, and then
revert back to OAUTH2 back in TB. That is, switch to normal login,
test, and then switch to OAUTH2, and test again. I suspect swithing
/to/ OAUTH2 would get TB renogiate to get a new OAUTH2 token. When
switching login modes in TB, you may have to exit and reload TB to get
it to get it to change the login method.

Note that I have seen in my own Gmail account where Google reset the
"Allow less secure apps" option, so it became disabled. I rarely use
their webmail client, so it wasn't an accidental change by me. My
client stopped working, and when I checked this option it had somehow
gotten disabled, and I had to reenable it. This isn't unique to me.
I've seen other users that use the normal login (not OAUTH2) and
eventually they cannot connect because the "Allow less secure apps"
setting got mysteriously disabled in their Google account.

Hopefully 2FA (2 factor authorization) has not gotten mysteriously
enabled in the OP's Google account, too.

VanguardLH wrote:
Frank Slootweg wrote:

Mayayana wrote:
"Frank Slootweg" wrote

| Thunderbird pops up an error message. Post that full and exact error
| message.
|
Usually not helpful. I was trying to help someone
set up work email in TBird on Friday. First we were
trying the wrong server. (It's a college that uses
both gmail and office365 for their email.) Later there
was a passowrd problem. In all cases TBird's only
message was "Failed to log in."

But this (the OP) is a case where it used to work, not a setup issue.

With the (Gmail/Google) security issue, one gets a clear popup and a
clear e-mail message, but one will have to read that popup and login on
Gmail's *web*-interface, because if the issue is indeed security, the
e-mail message will be stuck in Gmail's inbox. Catch-22.

BUT, in the meantime the OP has indicated that he gets a time-out (and
(implicitly) that he is using IMAP, so should use OAuth2 in
Thunderbird), so a different scenario.

Using IMAP does not mandate using OAUTH2. TB can use either the
standard login process or use OAUTH2.

That's why I said "should", not "must". Earlier in the (sub)thread, I
mentioned switching 'Allow less secure apps' back to OFF, which *does*
require OAuth2.

[...]
separate of the session process. Even if you have qualified using your
client with OAUTH2 doesn't mean the token(s) you get will survive
forever. They can expire at which point your client has to renogiate to
get another token. I don't know if TB is coded to do a token refresh
after the old one expires.

https://www.oauth.com/oauth2-servers...oken-lifetime/

Refresh tokens can be for any duration, not just the 2 weeks noted in
the above article. I've seen some implementations where the refresh
token is good for a year. While there can be non-expiring OAUTH2
tokens, just doesn't seem something Google would do. OAUTH2 is not
about increasing security as Google likes to pretend. It is about
tracking which host is attempting to use a service. OAUTH[1] was a
protocol. OAUTH2 devolved into a framework and a mess.

Other than deleting the Gmail account and recreating it again in TB, is
there a way in TB to force a refresh on the OAUTH2 token that it has to
get a new one from the server?

If the OP enables the "Allow less secure apps" option in his Google
account, he doesn't need to use OAUTH2. In fact, OAUTH2 is meaningless
with a normal login process. I suspect the OP could disable using
OAUTH2 in TB, check if IMAP works with normal login using TB, and then
revert back to OAUTH2 back in TB. That is, switch to normal login,
test, and then switch to OAUTH2, and test again. I suspect swithing
/to/ OAUTH2 would get TB renogiate to get a new OAUTH2 token. When
switching login modes in TB, you may have to exit and reload TB to get
it to get it to change the login method.

Note that I have seen in my own Gmail account where Google reset the
"Allow less secure apps" option, so it became disabled. I rarely use
their webmail client, so it wasn't an accidental change by me. My
client stopped working, and when I checked this option it had somehow
gotten disabled, and I had to reenable it. This isn't unique to me.
I've seen other users that use the normal login (not OAUTH2) and
eventually they cannot connect because the "Allow less secure apps"
setting got mysteriously disabled in their Google account.

Hopefully 2FA (2 factor authorization) has not gotten mysteriously
enabled in the OP's Google account, too.

Art Todesco wrote:
On 3/17/2020 12:24 PM, Art Todesco wrote:
On 3/17/2020 11:40 AM, Mayayana wrote:
"Frank Slootweg" wrote

| Thunderbird pops up an error message. Post that full and exact error
| message.
|
Usually not helpful. I was trying to help someone
set up work email in TBird on Friday. First we were
trying the wrong server. (It's a college that uses
both gmail and office365 for their email.) Later there
was a passowrd problem. In all cases TBird's only
message was "Failed to log in."

Additional OP info. I tried it on a W10 laptop and everything behaves
the same as my desktop. Immediately when it tries to get emails,
TBird says, in the lower left corner, "mylogin Connecting to
imap.gmail.com" and sits there until a timeout occurs. TBird then
pops a window saying "Connection to server imap.gmail.com timed out".
TBird seems to try a few times and then gives up until I click on
something which makes a request from the server like "get messages"
or I select a different gmail account. I haven't tried OAuth2 yet.
But again, eternal-september is still working so I think the problem
is clearly Google.

Oh, and one more thing. I just sent an email to an account from my ISP
which is also registered in TBird. It when through perfectly, which
further firms up my beliefs that the problen is Google.

I'm locked out of a GMAIL account right now too.

Great company. Excellent service.

Paul

On 3/17/2020 4:05 PM, Frank Slootweg wrote:
VanguardLH wrote:
Frank Slootweg wrote:

Mayayana wrote:
"Frank Slootweg" wrote

| Thunderbird pops up an error message. Post that full and exact error
| message.
|
Usually not helpful. I was trying to help someone
set up work email in TBird on Friday. First we were
trying the wrong server. (It's a college that uses
both gmail and office365 for their email.) Later there
was a passowrd problem. In all cases TBird's only
message was "Failed to log in."

But this (the OP) is a case where it used to work, not a setup issue.

With the (Gmail/Google) security issue, one gets a clear popup and a
clear e-mail message, but one will have to read that popup and login on
Gmail's *web*-interface, because if the issue is indeed security, the
e-mail message will be stuck in Gmail's inbox. Catch-22.

BUT, in the meantime the OP has indicated that he gets a time-out (and
(implicitly) that he is using IMAP, so should use OAuth2 in
Thunderbird), so a different scenario.

Using IMAP does not mandate using OAUTH2. TB can use either the
standard login process or use OAUTH2.

That's why I said "should", not "must". Earlier in the (sub)thread, I
mentioned switching 'Allow less secure apps' back to OFF, which *does*
require OAuth2.

[...]
separate of the session process. Even if you have qualified using your
client with OAUTH2 doesn't mean the token(s) you get will survive
forever. They can expire at which point your client has to renogiate to
get another token. I don't know if TB is coded to do a token refresh
after the old one expires.

https://www.oauth.com/oauth2-servers...oken-lifetime/

Refresh tokens can be for any duration, not just the 2 weeks noted in
the above article. I've seen some implementations where the refresh
token is good for a year. While there can be non-expiring OAUTH2
tokens, just doesn't seem something Google would do. OAUTH2 is not
about increasing security as Google likes to pretend. It is about
tracking which host is attempting to use a service. OAUTH[1] was a
protocol. OAUTH2 devolved into a framework and a mess.

Other than deleting the Gmail account and recreating it again in TB, is
there a way in TB to force a refresh on the OAUTH2 token that it has to
get a new one from the server?

If the OP enables the "Allow less secure apps" option in his Google
account, he doesn't need to use OAUTH2. In fact, OAUTH2 is meaningless
with a normal login process. I suspect the OP could disable using
OAUTH2 in TB, check if IMAP works with normal login using TB, and then
revert back to OAUTH2 back in TB. That is, switch to normal login,
test, and then switch to OAUTH2, and test again. I suspect swithing
/to/ OAUTH2 would get TB renogiate to get a new OAUTH2 token. When
switching login modes in TB, you may have to exit and reload TB to get
it to get it to change the login method.

Note that I have seen in my own Gmail account where Google reset the
"Allow less secure apps" option, so it became disabled. I rarely use
their webmail client, so it wasn't an accidental change by me. My
client stopped working, and when I checked this option it had somehow
gotten disabled, and I had to reenable it. This isn't unique to me.
I've seen other users that use the normal login (not OAUTH2) and
eventually they cannot connect because the "Allow less secure apps"
setting got mysteriously disabled in their Google account.

Hopefully 2FA (2 factor authorization) has not gotten mysteriously
enabled in the OP's Google account, too.

From OP. I tried removing the passwords from TB, changed to OAUTH2,
re-launched TB and it still won't do anything. It doesn't ask for a
password as explaned in some of the websites. How do I know if the 2FA
has been enabled? It's not in the normal list where "normal password"
and "OAUTH2" resides.

On 3/17/2020 4:56 PM, Art Todesco wrote:
On 3/17/2020 4:05 PM, Frank Slootweg wrote:
VanguardLH wrote:
Frank Slootweg wrote:

Mayayana wrote:
"Frank Slootweg" wrote

|Â* Thunderbird pops up an error message. Post that full and exact
error
| message.
|
Â*Â*Â* Usually not helpful. I was trying to help someone
set up work email in TBird on Friday. First we were
trying the wrong server. (It's a college that uses
both gmail and office365 for their email.) Later there
was a passowrd problem. In all cases TBird's only
message was "Failed to log in."

Â*Â* But this (the OP) is a case where it used to work, not a setup
issue.

Â*Â* With the (Gmail/Google) security issue, one gets a clear popup and a
clear e-mail message, but one will have to read that popup and login on
Gmail's *web*-interface, because if the issue is indeed security, the
e-mail message will be stuck in Gmail's inbox. Catch-22.

Â*Â* BUT, in the meantime the OP has indicated that he gets a time-out
(and
(implicitly) that he is using IMAP, so should use OAuth2 in
Thunderbird), so a different scenario.

Using IMAP does not mandate using OAUTH2.Â* TB can use either the
standard login process or use OAUTH2.

Â*Â* That's why I said "should", not "must". Earlier in the (sub)thread, I
mentioned switching 'Allow less secure apps' back to OFF, which *does*
require OAuth2.

[...]
separate of the session process.Â* Even if you have qualified using your
client with OAUTH2 doesn't mean the token(s) you get will survive
forever.Â* They can expire at which point your client has to renogiate to
get another token.Â* I don't know if TB is coded to do a token refresh
after the old one expires.

https://www.oauth.com/oauth2-servers...oken-lifetime/


Refresh tokens can be for any duration, not just the 2 weeks noted in
the above article.Â* I've seen some implementations where the refresh
token is good for a year.Â* While there can be non-expiring OAUTH2
tokens, just doesn't seem something Google would do.Â* OAUTH2 is not
about increasing security as Google likes to pretend.Â* It is about
tracking which host is attempting to use a service.Â* OAUTH[1] was a
protocol.Â* OAUTH2 devolved into a framework and a mess.

Other than deleting the Gmail account and recreating it again in TB, is
there a way in TB to force a refresh on the OAUTH2 token that it has to
get a new one from the server?

If the OP enables the "Allow less secure apps" option in his Google
account, he doesn't need to use OAUTH2.Â* In fact, OAUTH2 is meaningless
with a normal login process.Â* I suspect the OP could disable using
OAUTH2 in TB, check if IMAP works with normal login using TB, and then
revert back to OAUTH2 back in TB.Â* That is, switch to normal login,
test, and then switch to OAUTH2, and test again.Â* I suspect swithing
/to/ OAUTH2 would get TB renogiate to get a new OAUTH2 token.Â* When
switching login modes in TB, you may have to exit and reload TB to get
it to get it to change the login method.

Note that I have seen in my own Gmail account where Google reset the
"Allow less secure apps" option, so it became disabled.Â* I rarely use
their webmail client, so it wasn't an accidental change by me.Â* My
client stopped working, and when I checked this option it had somehow
gotten disabled, and I had to reenable it.Â* This isn't unique to me.
I've seen other users that use the normal login (not OAUTH2) and
eventually they cannot connect because the "Allow less secure apps"
setting got mysteriously disabled in their Google account.

Hopefully 2FA (2 factor authorization) has not gotten mysteriously
enabled in the OP's Google account, too.

From OP.Â* I tried removing the passwords from TB, changed to OAUTH2,
re-launched TB and it still won't do anything.Â* It doesn't ask for a
password as explaned in some of the websites.Â* How do I know if the 2FA
has been enabled?Â* It's not in the normal list where "normal password"
and "OAUTH2" resides.
You would have to go into Options, Security, Passwords.

Find you the account and delete the account entry and password.

The next time you try to access the account, you will be asked for the
new password to obtain access.

Art Todesco wrote:


From OP. I tried removing the passwords from TB, changed to OAUTH2,
re-launched TB and it still won't do anything. It doesn't ask for a
password as explaned in some of the websites. How do I know if the 2FA
has been enabled? It's not in the normal list where "normal password"
and "OAUTH2" resides.

Log into the web mail version and answer the security
question when asked. Then, return to TB and use it, when
the account is (presumably) reset to normal.

The problem is, you can't see the "state machine" status
when using TB. But if you use the web portal, it's going to
tell you there was "suspicious activity" on your account,
when of course, there was no such suspicious activity
and it's all bull****. We know that. In the business,
we call this "customer harassment". And I bet people
here could give you names of companies which are
famous for their ability to harass customers.

Paul

On 3/17/2020 5:09 PM, Paul wrote:
Art Todesco wrote:


Â*From OP.Â* I tried removing the passwords from TB, changed to OAUTH2,
re-launched TB and it still won't do anything.Â* It doesn't ask for a
password as explaned in some of the websites.Â* How do I know if the
2FA has been enabled?Â* It's not in the normal list where "normal
password" and "OAUTH2" resides.

Log into the web mail version and answer the security
question when asked. Then, return to TB and use it, when
the account is (presumably) reset to normal.

The problem is, you can't see the "state machine" status
when using TB. But if you use the web portal, it's going to
tell you there was "suspicious activity" on your account,
when of course, there was no such suspicious activity
and it's all bull****. We know that. In the business,
we call this "customer harassment". And I bet people
here could give you names of companies which are
famous for their ability to harass customers.

Â*Â* Paul
Actually, I'm logged into the web based gmail right now. And, I still
can't access the emails in TB even though the gmail lines in the TB
password config are gone. Yup, harass the customer!

Art Todesco wrote:

How do I know if the 2FA has been enabled? It's not in the normal
list where "normal password" and "OAUTH2" resides.

2FA is not configured at the client. It is configured in your account,
so you have to use a webclient to go to your Google account to enable or
disable Google's 2FA, ahem, "service".

https://support.google.com/accounts/...DDesktop&hl=en

Because clients don't do the 2FA management, they also cannot respond to
any inquiry from the server regarding 2FA, especially since 2FA is
*separate* authentication from the login (OAUTH2 or not) by the client.
To get around that hassle (of having to repeatedly authenticate via some
other methods than the e-mail client), Google will let you create "app
passwords" that are unique to each e-mail client. For multiple e-mail
clients on the same or different hosts accessing the same Gmail account,
each e-mail app would get its own unique app password.

https://support.google.com/accounts/answer/185833?hl=en

Is the password you specify in TB the /account's/ password, or an /app/
password? One is the password you use to access your account whether it
be via e-mail client, web browser, or some other client. The other is a
password that you create online and then use by a particular client
program or app. Apparently you must enable 2FA to then use app
passwords. The same web page mentioned in the 2nd article shows if 2FA
is on or off.

While you said that you enabled the server-side "Allow less secure apps"
option in your Google account, have you revisited that setting to make
sure it stuck?

In the IMAP settings in TB for the Gmail account, you said the server's
host name specified is imap.gmail.com. Have you checked if you can
reach that host? In a command shell, run:

tracert imap.gmail.com

ping imap.gmail.com

For the traceroute, you might get a bunch of "timed out" which can be
internal hosts in a network where they don't want outsiders to map the
hosts in their network. You should eventually get to the Gmail server
(the same IP address in a node record as mentioned for the IP address of
the target in the 1st line of tracert). I get an IPv6 address for
imap.gmail.com because my host supports IPv6 and so does the gateway
inside the cable modem. To see the IPv4 address, run "nslookup
imap.gmail.com" which should show all the IP addresses for the hostname.

What port are you using for the IMAP account in TB for Gmail? 993?
Google requires an encrypted connection, so is the IMAP account for
Gmail in TB configured to use TLS?

Note: TLS 1.0 and 1.1 are getting deprecated. TLS 1.0 is no different
than SSL 3.0 which got dumped because it isn't secure, except the
handshaking for TLS 1.0 differs from SSL 3.0. I haven't check why TLS
1.1 is considered no longer a secure connection. TB should support both
TLS 1.2 and 1.3. TB should use TLS 1.3, by default, and fallback to TLS
1.2, but it shouldn't be using the older TLS 1.1 or 1.0, or any of the
SSL methods.

You could have extensions installed into TB, and some may still try to
use TLS 1.0, 1.1, or even SSL. When the servers move to TLS 1.2 and
1.3, you can't make connects via older encryption protocols. Disable
all extensions in TB, unload TB (make sure there is no TB process in
Task Manager), reload TB (with no extensions this time), and retest.

https://bugzilla.mozilla.org/show_bug.cgi?id=1310516

While TB is supposed to follow some of the changes to Firefox, Mozilla
dropped TB from support (so support went to volunteers) and only
recently assigned a new "group" to supporting TB. Firefox has dropped
TLS 1.0 and 1.1 as of version 74, so maybe TB followed suit.

https://hacks.mozilla.org/2020/02/it...0-and-tls-1-1/

Is the IMAP account for Gmail defined in TB configured to use TLS (and
not SSL)?

https://www.dido.ca/mozilla-thunderbird-setup/
(See figure 2. Set secure connection mode to TLS.)

Is your e-mail traffic going through a proxy, like a local VPN or an
external anonymizing proxy? If the proxy (local or external) blocks the
connection (intentionally or not) then your client cannot connect to the
server.

Configure your anti-virus program to *NOT* interrogate your e-mail
traffic. It offers no more protection than the AV's real-time
(on-demand) scanner, especially since that's the same scanner used to
interrogate the e-mail content. If the transparent proxy for the AV is
screwing up then your e-mail client may issue timeouts (either waiting
for content for its DATA command it sent to the IMAP server or for an OK
status returned when using SMTP) because the AV proxy is taking too long
to interrogate the e-mail traffic. Either disable the e-mail scanner in
your AV, or uninstall the AV's e-mail module since it is superfluous.
If the AV's proxy goes dead, you can't do e-mail (but still might be
able to do web traffic). Same for any other proxy you use, like some
anti-spam filtering proxy. After disabling or uninstalling the AV's
e-mail module, reboot the computer to make sure that proxy is no longer
used. Also, simply disabling an AV's e-mail scan may not get rid of its
proxy; i.e., e-mail traffic still goes through the AV's proxy but
without interrogation (so no delay in receive or send to cause
timeouts). Uninstalling its e-mail module gets rid of e-mail traffic
going through a supposedly disabled AV proxy.

Have you used their webclient (i.e., use a web browser) to your Gmail
account to look at your Inbox on the server? Look for some excessively
large e-mails. Read them and then delete if you no longer want them,
like someone sent you a video of their newborn baby and figures just
everyone wants their Inbox filled with a super-large e-mail which could
exceed the account's max size quota, max size per message quota, or
both. I've also seen e-mails get corrupted where the server will puke,
like a timeout, when trying to respond to the client's DATA command.
The server cannot deliver the corrupted message, and either it hangs
there and the client times out or the server times out and the client
again gets a timeout. The Inbox folder is not an archive folder. Old
e-mails you want to keep should get moved into another folder, like one
called Archive or Old Messages. Using their webmail client (since rare
few e-mail services provide a shell anymore where you can issue mail
commands), create an archive folder (if one doesn't already exist for
your Gmail account), and move all messages from the Inbox folder to the
archive folder. Then test if your local e-mail client starts working
again.

Art Todesco wrote:

On 3/17/2020 11:40 AM, Mayayana wrote:
"Frank Slootweg" wrote

| Thunderbird pops up an error message. Post that full and exact error
| message.
|
Usually not helpful. I was trying to help someone
set up work email in TBird on Friday. First we were
trying the wrong server. (It's a college that uses
both gmail and office365 for their email.) Later there
was a passowrd problem. In all cases TBird's only
message was "Failed to log in."

Additional OP info. I tried it on a W10 laptop and everything behaves
the same as my desktop. Immediately when it tries to get emails, TBird
says, in the lower left corner, "mylogin Connecting to imap.gmail.com"
and sits there until a timeout occurs. TBird then pops a window saying
"Connection to server imap.gmail.com timed out". TBird seems to try a
few times and then gives up until I click on something which makes a
request from the server like "get messages" or I select a different
gmail account. I haven't tried OAuth2 yet. But again,
eternal-september is still working so I think the problem is clearly
Google.

The error dialog (aka Activity Manager) messages are mostly worthless.
They won't tell you where in the connection handshaking or session
establishing when an error occurs. It's like looking at a tire to see
it's flat, but that doesn't say if due to a puncture, bad tire valve, or
what. Did you check TB's error console (Tools menu - Error console)?
I haven't used TB for a long time, so I don't know what its error
console will show.

TB can create a logfile, but you have to enable it. When done, you'll
want to disable/undo the logging as it causes lots of overhead, slows
the program, and the logfile can get large.

https://wiki.mozilla.org/MailNews:Logging

Debug or verbose levels should show the commands the client sent to the
server, and the statuses or commands sent from the server to the client.
A "timeout" error in the dialog doesn't tell you if there was a problem
connecting to the server, or a problem during the session (e.g., the
server couldn't respond to the DATA command). I've not used TB in a
long time, so I don't know what to expect in its logfile to
differentiate the entries showing the connection handshaking from those
afterward during the mail session. Someone else that uses TB might
understand its log.

https://www.lifewire.com/pop-imap-sm...erbird-1173156

That gives different environment variables to set, so I don't which ones
to use to get TB to generate a logfile.

Ken Springer wrote:

Good Guy wrote:

Why it has always to be TB or Windows or Office or some other
software?** Why not blame the user being an idiot?*...

PEBKAC is the problem everyone realizes you have.

Don't feed the trolls. Filter them out. Don't tell them you're going
to filter them out. Just do it silently and let them keep stroking
their baby carrots unseen.

On Tue, 17 Mar 2020 08:24:38 -0400, Art Todesco wrote:

Hi All,
Yesterday TBird quit being able to receive or send emails; connection to
news.eternal-september.org works for NGs (I'm using it now!). I've
googled many places and it seems that gmail wants a more secure way to
connect. I've disabled that and still no joy. TBird, when launched,
just keeps saying that it can connect to the server. I may be in a
minority, however, I really like TBird as an email client. Any idea how
to proceed here? Thanks.


Thunderbird is connecting OK here to imap.gmail.com. For me,
imap.gmail.com does not have a problem.

A lot depends on the exact error you get when TBird cannot connect.
A couple of actual examples:

A) If it is a "less secure apps" problem, the error would say
that authentication failed (your credentials were rejected).

B) My antivirus updated itself to a new version over the weekend.
After that TBird failed to connect with an SSL Certificate error
until I added the AV's new root certificate to Thunderbird's
certificate store. Instructions from two AV vendors he
https://support.kaspersky.com/14620
https://support.avast.com/en-ww/article/91/


C) Also check the server settings are correct in Thunderbird.
Server name: imap.gmail.com
Port: 993 (for IMAP) (995 for POP)
Connection Security: SSL/TLS
Authentication method: OAuth2 is the best option for Gmail IMAP

D) Finally, if you use a router which has a firewall, it may be
worth checking that the router isn't blocking access to either
imap.gmail.com or its IP address.


--
Kind regards
Ralph

Art Todesco wrote:
[...]

Actually, I'm logged into the web based gmail right now.

As I mentioned before, is there a message from Google in your Gmail
inbox? If so, read it and act on it.

In any case, login on your *Google* account (NOT Gmail) and check for
any security related issues:

https://myaccount.google.com/security

Specifically - but not limited to - the 'Security issues found' and
'Recent security events' sections.

And - as I mentioned before - on that page add the 'Recovery email' to
point to an e-mail address *other* than your/any gmail address.

And, I still
can't access the emails in TB even though the gmail lines in the TB
password config are gone. Yup, harass the customer!

If you removed the passwords from the Thunderbird Gmail account,
Thunderbird *will* ask for the password. If it doesn't, you must have
done something wrong in the account setup.

On 3/17/2020 11:01 PM, VanguardLH wrote:
Art Todesco wrote:

How do I know if the 2FA has been enabled? It's not in the normal
list where "normal password" and "OAUTH2" resides.

2FA is not configured at the client. It is configured in your account,
so you have to use a webclient to go to your Google account to enable or
disable Google's 2FA, ahem, "service".

https://support.google.com/accounts/...DDesktop&hl=en

Because clients don't do the 2FA management, they also cannot respond to
any inquiry from the server regarding 2FA, especially since 2FA is
*separate* authentication from the login (OAUTH2 or not) by the client.
To get around that hassle (of having to repeatedly authenticate via some
other methods than the e-mail client), Google will let you create "app
passwords" that are unique to each e-mail client. For multiple e-mail
clients on the same or different hosts accessing the same Gmail account,
each e-mail app would get its own unique app password.

https://support.google.com/accounts/answer/185833?hl=en

Is the password you specify in TB the /account's/ password, or an /app/
password? One is the password you use to access your account whether it
be via e-mail client, web browser, or some other client. The other is a
password that you create online and then use by a particular client
program or app. Apparently you must enable 2FA to then use app
passwords. The same web page mentioned in the 2nd article shows if 2FA
is on or off.

While you said that you enabled the server-side "Allow less secure apps"
option in your Google account, have you revisited that setting to make
sure it stuck?

In the IMAP settings in TB for the Gmail account, you said the server's
host name specified is imap.gmail.com. Have you checked if you can
reach that host? In a command shell, run:

tracert imap.gmail.com

ping imap.gmail.com

For the traceroute, you might get a bunch of "timed out" which can be
internal hosts in a network where they don't want outsiders to map the
hosts in their network. You should eventually get to the Gmail server
(the same IP address in a node record as mentioned for the IP address of
the target in the 1st line of tracert). I get an IPv6 address for
imap.gmail.com because my host supports IPv6 and so does the gateway
inside the cable modem. To see the IPv4 address, run "nslookup
imap.gmail.com" which should show all the IP addresses for the hostname.

What port are you using for the IMAP account in TB for Gmail? 993?
Google requires an encrypted connection, so is the IMAP account for
Gmail in TB configured to use TLS?

Note: TLS 1.0 and 1.1 are getting deprecated. TLS 1.0 is no different
than SSL 3.0 which got dumped because it isn't secure, except the
handshaking for TLS 1.0 differs from SSL 3.0. I haven't check why TLS
1.1 is considered no longer a secure connection. TB should support both
TLS 1.2 and 1.3. TB should use TLS 1.3, by default, and fallback to TLS
1.2, but it shouldn't be using the older TLS 1.1 or 1.0, or any of the
SSL methods.

You could have extensions installed into TB, and some may still try to
use TLS 1.0, 1.1, or even SSL. When the servers move to TLS 1.2 and
1.3, you can't make connects via older encryption protocols. Disable
all extensions in TB, unload TB (make sure there is no TB process in
Task Manager), reload TB (with no extensions this time), and retest.

https://bugzilla.mozilla.org/show_bug.cgi?id=1310516

While TB is supposed to follow some of the changes to Firefox, Mozilla
dropped TB from support (so support went to volunteers) and only
recently assigned a new "group" to supporting TB. Firefox has dropped
TLS 1.0 and 1.1 as of version 74, so maybe TB followed suit.

https://hacks.mozilla.org/2020/02/it...0-and-tls-1-1/

Is the IMAP account for Gmail defined in TB configured to use TLS (and
not SSL)?

https://www.dido.ca/mozilla-thunderbird-setup/
(See figure 2. Set secure connection mode to TLS.)

Is your e-mail traffic going through a proxy, like a local VPN or an
external anonymizing proxy? If the proxy (local or external) blocks the
connection (intentionally or not) then your client cannot connect to the
server.

Configure your anti-virus program to *NOT* interrogate your e-mail
traffic. It offers no more protection than the AV's real-time
(on-demand) scanner, especially since that's the same scanner used to
interrogate the e-mail content. If the transparent proxy for the AV is
screwing up then your e-mail client may issue timeouts (either waiting
for content for its DATA command it sent to the IMAP server or for an OK
status returned when using SMTP) because the AV proxy is taking too long
to interrogate the e-mail traffic. Either disable the e-mail scanner in
your AV, or uninstall the AV's e-mail module since it is superfluous.
If the AV's proxy goes dead, you can't do e-mail (but still might be
able to do web traffic). Same for any other proxy you use, like some
anti-spam filtering proxy. After disabling or uninstalling the AV's
e-mail module, reboot the computer to make sure that proxy is no longer
used. Also, simply disabling an AV's e-mail scan may not get rid of its
proxy; i.e., e-mail traffic still goes through the AV's proxy but
without interrogation (so no delay in receive or send to cause
timeouts). Uninstalling its e-mail module gets rid of e-mail traffic
going through a supposedly disabled AV proxy.

Have you used their webclient (i.e., use a web browser) to your Gmail
account to look at your Inbox on the server? Look for some excessively
large e-mails. Read them and then delete if you no longer want them,
like someone sent you a video of their newborn baby and figures just
everyone wants their Inbox filled with a super-large e-mail which could
exceed the account's max size quota, max size per message quota, or
both. I've also seen e-mails get corrupted where the server will puke,
like a timeout, when trying to respond to the client's DATA command.
The server cannot deliver the corrupted message, and either it hangs
there and the client times out or the server times out and the client
again gets a timeout. The Inbox folder is not an archive folder. Old
e-mails you want to keep should get moved into another folder, like one
called Archive or Old Messages. Using their webmail client (since rare
few e-mail services provide a shell anymore where you can issue mail
commands), create an archive folder (if one doesn't already exist for
your Gmail account), and move all messages from the Inbox folder to the
archive folder. Then test if your local e-mail client starts working
again.

And then there was joy, this morning! I don't know what I did to solve
this because I did what you are not supposed to do. That is, change
many things. I did open up the firewall in my DSL router and of course,
allowed access from "less secure apps". But, I know I did these things
before, so there must be other things. Or Google changed something ???

Art Todesco wrote:
And then there was joy, this morning!Â*Â* I don't know what I did to solve
this because I did what you are not supposed to do.Â* That is, change
many things.Â* I did open up the firewall in my DSL router and of course,
allowed access from "less secure apps".Â* But, I know I did these things
before, so there must be other things.Â* Or Google changed something ???

I created a new gmail acct in Tb. I was having persistent
authentication errors with the default settings for Tb and gmail. I had
to change the gmail settings to allow less secure apps to succeed w/
authentication.

My current settings that work in Tb are imap.gmail.com port 993 SSL/TLS,
normal password (changed from OAuth2)

The 'proper' settings would be OAuth2 and gmail allow less secure OFF.

--
Mike Easter

Mike Easter wrote:
I created a new gmail acct in Tb.Â* I was having persistent
authentication errors with the default settings for Tb and gmail.Â* I had
to change the gmail settings to allow less secure apps to succeed w/
authentication.

My current settings that work in Tb are imap.gmail.com port 993 SSL/TLS,
normal password (changed from OAuth2)

The 'proper' settings would be OAuth2 and gmail allow less secure OFF.

This problem has been solved.

My earlier v. of Tb was 60.9.0. My linux distro repo/s had a newer v.
68.4.1. After the upgrade, gmail settings are now less secure OFF and
Tb setting is OAuth2 and authentication succeeds.

Another v. of Tb which solves that is 60.9.1

https://support.mozilla.org/en-US/questions/1273204

Tb releases: https://www.thunderbird.net/en-US/thunderbird/releases/


--
Mike Easter