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

On 3/18/2020 2:53 PM, Mike Easter wrote:
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/


Funny thing here is, I'm using SSL/TLS and normal password. That's what
I got to work. Further fuel to the "It was Google's problem" argument.

Art Todesco wrote:
Mike Easter wrote:
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/


Funny thing here is, I'm using SSL/TLS and normal password.Â* That's what
I got to work.Â* Further fuel to the "It was Google's problem" argument.

Your Tb says Thunderbird/68.6.0, so that v. should be able to work w/
gmail's v. of OAuth2 in normal security. Of course some 'lesser'
security settings would also work if so configured.

You can make an IMAP log file w/ Tb which /might/ be helpful.

Here's how to Win10 .bat:
https://www.windowscentral.com/how-c...ile-windows-10
How to create and run a batch file on Windows 10

Here's how to make IMAP logger .bat:

https://wiki.mozilla.org/MailNews:Logging 4 Generating a Protocol Log -
4.1 Windows - Create a batch file by copying the lines below and paste
them into the notepad application, and save the file as
"create_imap_log.bat". Variables must not contain quotation marks.


--
Mike Easter

Art Todesco wrote:

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 ???

It's possible your account was determined to be issuing bulk/spam e-mail
traffic, so it got disabled (suspended) for 24 hours. While you think
you aren't spamming, sending messages to mailing lists is bulk mail.
Sending UCE (Unsolicited E-mail) or UBE (Unsolicited Bulk E-mail) are
considered spam. If if your recipients have opted into a mailing list,
you'll be sending UBEs when using a mailing lists. Also, if a lot of
the e-mail addresses in your mailing list are invalid (not a valid
username at the receiving server, or no such account exists there), the
sending mail server (Google's) will get a lot of "no such account" or
other NDRs (non-delivery reports) from the receiving servers. They
figure if you are sending to lots of dead or non-existing accounts that
you are spamming to somewhat randomly generated e-mail addresses.

No idea how you use your Gmail account to know if you violated their
anti-abuse policies or quotas. Do you have a STRONG password to prevent
hacking into your account, so it gets abused by someone else?
If there is any hint of a hacked account, change your password, and make
sure it is a strong one.

https://support.yet-another-mail-mer...t-should-I-do-
https://support.google.com/a/answer/2789146?hl=en
https://support.google.com/accounts/answer/40695

This is just a guess why the account was unusable for a day, or two, and
then became available again. I believe you said you used a web browser
to log into your Gmail account. If that had failed, the articles say
you should have gotten a web page saying your account was suspended.

Note that you may not get a warning page when using a web browser to log
into your Gmail account if you hit their maximum messages per hour or
per day anti-abuse quotas. You'll just get throttled back to not being
allowed to send until after 24 hours have elapsed. While this is about
sending e-mails, hitting their anti-abuse quotas can suspend your
account. Another anti-abuse quota is the maximum number of recipients
per message. Anti-abuse quotas are exercised over a rolling 24-hour
period, not at a fixed time of day.

Trying to find what Google is currently using for their anti-abuse
quotas is mostly guesswork. Bulk mailers might discover the limits by
hitting them (and why there is bulk mailing software that will slice up
mailing lists to stay under the max recipients count, how many messages
are sent per hour, and how many per day, and some will update the
mailing list for dead recipients to keep the list updated with only
active/valid e-mail addresses). Google has published some limits for
their G Suite service, as mentioned at:

https://support.google.com/a/answer/166852?hl=en

Another article about general anti-abuse quotas is at:

https://support.google.com/mail/answer/22839?hl=en

If you have a G Suite account, see:

https://support.google.com/a/answer/33326?hl=en

Else, I think the only way you'd know your account was suspended (for 24
hours) for a personal-use account would be to log into their webmail
client to see if they show an interstitial security web page alerting
you to the suspension.

I don't know where in your Google account to see a history of any past
suspensions. In your Google account with the Home group selected, go to
the Security section and click on "Secure Account" under "Security
issues found". One category of interest is which devices are accessing
your Gmail account. Look under "Your devices", "Signed-in devices", and
"Recent security events". The same security info is available by going
into your Google account and looking at the Security group.

On 3/18/2020 3:47 AM, Ralph Fox wrote:
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.

Thanks, I'm aware of these things. And checked them and even changed
them if necessary. It seemed to come back about like it quit.

On 3/18/2020 5:12 PM, VanguardLH wrote:
Art Todesco wrote:

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 ???

It's possible your account was determined to be issuing bulk/spam e-mail
traffic, so it got disabled (suspended) for 24 hours. While you think
you aren't spamming, sending messages to mailing lists is bulk mail.
Sending UCE (Unsolicited E-mail) or UBE (Unsolicited Bulk E-mail) are
considered spam. If if your recipients have opted into a mailing list,
you'll be sending UBEs when using a mailing lists. Also, if a lot of
the e-mail addresses in your mailing list are invalid (not a valid
username at the receiving server, or no such account exists there), the
sending mail server (Google's) will get a lot of "no such account" or
other NDRs (non-delivery reports) from the receiving servers. They
figure if you are sending to lots of dead or non-existing accounts that
you are spamming to somewhat randomly generated e-mail addresses.

No idea how you use your Gmail account to know if you violated their
anti-abuse policies or quotas. Do you have a STRONG password to prevent
hacking into your account, so it gets abused by someone else?
If there is any hint of a hacked account, change your password, and make
sure it is a strong one.

https://support.yet-another-mail-mer...t-should-I-do-
https://support.google.com/a/answer/2789146?hl=en
https://support.google.com/accounts/answer/40695

This is just a guess why the account was unusable for a day, or two, and
then became available again. I believe you said you used a web browser
to log into your Gmail account. If that had failed, the articles say
you should have gotten a web page saying your account was suspended.

Note that you may not get a warning page when using a web browser to log
into your Gmail account if you hit their maximum messages per hour or
per day anti-abuse quotas. You'll just get throttled back to not being
allowed to send until after 24 hours have elapsed. While this is about
sending e-mails, hitting their anti-abuse quotas can suspend your
account. Another anti-abuse quota is the maximum number of recipients
per message. Anti-abuse quotas are exercised over a rolling 24-hour
period, not at a fixed time of day.

Trying to find what Google is currently using for their anti-abuse
quotas is mostly guesswork. Bulk mailers might discover the limits by
hitting them (and why there is bulk mailing software that will slice up
mailing lists to stay under the max recipients count, how many messages
are sent per hour, and how many per day, and some will update the
mailing list for dead recipients to keep the list updated with only
active/valid e-mail addresses). Google has published some limits for
their G Suite service, as mentioned at:

https://support.google.com/a/answer/166852?hl=en

Another article about general anti-abuse quotas is at:

https://support.google.com/mail/answer/22839?hl=en

If you have a G Suite account, see:

https://support.google.com/a/answer/33326?hl=en

Else, I think the only way you'd know your account was suspended (for 24
hours) for a personal-use account would be to log into their webmail
client to see if they show an interstitial security web page alerting
you to the suspension.

I don't know where in your Google account to see a history of any past
suspensions. In your Google account with the Home group selected, go to
the Security section and click on "Secure Account" under "Security
issues found". One category of interest is which devices are accessing
your Gmail account. Look under "Your devices", "Signed-in devices", and
"Recent security events". The same security info is available by going
into your Google account and looking at the Security group.

Well, as far as abuse, we do a very small "mass mailing" to the church
choir. The list is only about 16 people. Mailings go out several time
a week as needed. But, I wouldn't call that mass mailing .... even
though I did in the previous 2 sentences. And, of course, there were
several mailing because of Covid 19 announcing suspension of all church
gatherings. But this went out over web based emails as we couldn't use
TB at that time. .

Art Todesco wrote:

Well, as far as abuse, we do a very small "mass mailing" to the church
choir. The list is only about 16 people. Mailings go out several
time a week as needed. But, I wouldn't call that mass mailing ....
even though I did in the previous 2 sentences. And, of course, there
were several mailing because of Covid 19 announcing suspension of all
church gatherings. But this went out over web based emails as we
couldn't use TB at that time. .

I think the max number of recipients per message is either 25 or 50 at
Gmail. Some mailing lists are operated to send one message to all
recipients. This economizes on the overhead by establishing one mail
session (one DATA command) followed by a list of recipients (RCPT-TO for
each recipient). Some operate by sending a separate message to each
recipient. That method tries to avoid any anti-abuse quotas regarding
max recipients per message, but it can hit the max mail sessions per
minute or hour.

Have you updated your mailing list, so each recipient's e-mail address
has been validated? That is, is the e-mail address accurate and targets
a valid e-mail address for every recipient you specify in your mailing
list? Remember that one of the anti-abuse quotas is the number of NDRs
(Non-Delivery Reports) that you generate. If a lot of the e-mail
addresses are invalid (wrong e-mail address), the accounts were closed
(so the address is no longer valid), or other delivery problems then you
could hit Google's NDR anti-abuse quota.

Do you customize each message, so each is a little bit different than
another for each recipient in your mailing list? For example, do you
add their name, e-mail address, and other personal info as a block in
the body of each message, so the message to one recipient is different
than the message sent to another recipient? If you send out the exact
same message to multiple recipients, you ARE spamming. It's called UBE
(Unsolicted Bulk Email). Servers have no information regarding which of
the recipients opted into your mailing list. What they see is the same
exact message sent to multiple recipients. I don't know what is
Google's threshold for UBE. You don't mention what you are using to
generate the messages for your mailing list. Some programs let you use
a template message that has tags within them that will get replaced with
text from another file, like variables in a template message that get
replaced with personal info from the mailing list. That would make each
message different from the others, but not by a lot. The more personal
attributes you can add into the template, the more different one message
will be from another. Servers don't care that the mailing list is for a
church group, charity, or whatever.

In addition to the sending mail server seeing the same exact message is
being sent from the same account, receiving mail servers can detect if
the same message is getting delivered to their domain. That is, the
sending mail server can see if an account is sending out lots of
duplicate messages to multiple recipients, but receiving mail servers
can also see duplicate messages are hitting multiple recipients at that
domain. One anti-spam scheme is to track e-mails by a hash generated on
the content of e-mails to see how many messages are duplicates of
others.

https://en.wikipedia.org/wiki/Distri..._Clearinghouse
https://www.rhyolite.com/dcc/

Those that participate in watching incoming e-mails to check for
duplicates will generate hashes of each e-mail and send that hash to a
DCC server. The higher the count for detected duplicate messages, the
more spammy is the message. The receiving end can determine the
threshold when a duplicated message has been sent to too many
recipients. For users employing DCC on their own hosts, they can block
duplicated messages that have been reported as bulk mail beyond some
threshold. Receiving mail servers can do the same thing; however, they
can also send spam abuse reports to the sending mail server to report
the excessive UBE, and getting reported as a spam source can get your
account suspended.

However, if your account got suspended (for 24 hours) due to anti-abuse
quotas, then you should not have been able to use Gmail's webmail client
to send any e-mails. Suspending your account would suspend any means of
using your account whether by a local e-mail client or using a web
browser to use their webmail client. Since you could still use their
webmail client when TB wasn't working, doesn't seem your account got
suspended. Yet, Google and other e-mail providers have different
anti-abuse quotas depending on how their service is accessed. That is,
they can have lower anti-abuse quotas when an e-mail client accesses an
account than when using a web browser to use their webmail account.
That's because local e-mail clients can be automated, like to spam or
use mailing lists, whereas there is no scripting or automation when
using their webmail client (a human has to be using their webmail
client, not some process running on a host).

I've seen where church users think that because they are sending church
stuff via e-mail that they should somehow get exempted from anti-abuse
quotas. Not true. E-mail providers don't know and don't care that the
messages are church-related. They also have no information about which
recipients opted in or out of mailing lists. If you intend to use
mailing lists, you need to consider how to avoid hitting any
anti-abuse/spam quotas, like how many recipients per message, how many
messages you send per minute or hour, the size of the messages (not just
per message but the aggregate of all sent via mailing list) due to a max
volume quota per hour, and to keep your mailing list updated to
eliminate generating any NDRs.

A one-per-week mailing of a duplicated message sent to 16 recipients is
not likely to get you flagged as a spam source. But resending
duplicated messages to those recipients multiple times per day may slam
you into their anti-abuse quota policies. If you are sending large
messages, you might consider placing one copy online and provide a URL
to it rather than duplicate that content in duplicated messages, as that
could run you afoul of a volume-per-hour or day threshold.

You've been using your mailing list for awhile, and didn't have
problems. Then your volume went up along with shorter and repeated send
intervals, and maybe that nailed you, especially when using a
personal-use e-mail account. Take a look at how many total e-mails you
sent, their size, if all were duplicated, and if all the e-mail
addresses in your mailing list are valid. Bulk mailing has consequences
that are easily triggered.