Gmail is no longer delivering the emails

KumoMTA Helpers
1

I’ve recently encountered an issue where Gmail is not delivering emails.

#===== GMAIL
[provider."google"]
match=[
    {DomainSuffix="gmail.com"},
    {DomainSuffix="googlemail.com"},
    {DomainSuffix="googlemail.co.uk"},
    {DomainSuffix="google.com"},
    {DomainSuffix="ntlworld.com"},
    {DomainSuffix="ntlworld.co.uk"},
    {DomainSuffix="virgin.net"},
    {DomainSuffix="virginmedia.com"},
    {MXSuffix=".gmail-smtp-in.l.google.com"},
    {MXSuffix=".google.com"},
    {MXSuffix=".googlemail.com"}
]
max_deliveries_per_connection = 100
provider_connection_limit = 25
enable_tls = 'Required'

My shaping configuration is as follows, and there is no maximum rate limit set. Today I suddenly noticed a large amount of data in the channel, so I performed a rebind. What surprised me is that these emails had num_attempts = 0 and had been there for more than 7 days; when I did the rebind, they all showed type=Expiration.

I didn’t see any trace of Gmail in the TSA Blocklist.

For init.lua, source.toml, and queues.toml, I have barely made any changes. I uploaded them before, and I can upload them again later if needed.

What’s going on? It’s very confusing.

2

After switching to a different IP pool, it started working again.

3

Hard to tell without more data. It is likely that the IP you were using was not able to make a connection.

4

Thanks for the reply, Tom.

I understand the information is limited, so I tried to analyze it as much as possible on my side. When I checked the Gmail connections for this source, the connection count was not zero — it stayed at around 20+ — but no messages were being sent at all. After switching the traffic to another IP pool, delivery worked normally.

My suspicion is that the Gmail connections may have been held open or stalled without being properly released, which caused all available connections to remain occupied.

At the same time, Gmail delivery for other tenants was working normally. The issue appeared for about six tenants, all of which are large customers. There were no IP blocks and no TSA triggers.

After restarting KumoMTA, all previously stuck deliveries immediately returned to normal.

Based on this, I suspect there may be certain edge cases where Gmail connections are not properly released and can remain occupied for a very long time (potentially even more than 10 days).

5

All the issues I encountered previously were caused by a single parameter: max_retry_interval.

I found some inspiration in this issue: SuspendCampaign TSA action and retry_interval can produce unwanted results · Issue #322 · KumoCorp/kumomta · GitHub

The biggest problem is that many of my sending limits are set to connections=1. If some unexpected throttling occurs (such as 421 responses), over time it can lead to serious issues.

My current solution is to add a default value of 12 hours and observe the situation for a while.

6

Max_retry_interval has no default limit so it should not really be a problem but that does depend on the setting to max_age as well.

By default ( you might have changed these) the first retry will happen in 20 minutes the next at 40, then 80,160,320, doubling each time. After 10 retries the next one is 14 days. This is why it is important to set a max_age if you want it to be shifted then the default 7 days. Frankly, if a message is not delivered in 3 days, it is i likely to get delivered at all.

It is more likely that you have only allowed for one connection and that connection is blocked. Ery few MBPs will require o le a single connection per IP.