Queue Slow Draining Issues

KumoMTA Troubleshooting
1

Hi teams

Recently, I’ve been puzzled by an issue in my daily work. I’m conducting an in-depth investigation, but before that, I’m posting it to the community to seek ideas and suggestions.

I have been using Kumomta for several months, and its outstanding performance has made me very confident in it.

However, during my routine checks (monitoring the remaining capacity of queues) recently, I noticed that the queue data for several items has not been decreasing.

The command I used is:

kcli provider-summary --by-pool --limit 500 | grep 'qq'

The results are usually like this:

qq       vip01     151,063      0   0  0 40,877

And after a while, the result becomes:

qq       vip01     0      0   0  0 40,877

I have done some troubleshooting:

  1. In shaping.toml, I configured vip01 (and the corresponding source.name) without any suspend entries.
  2. I integrated webhook with ELK for log analysis and found no spam-related entries for qq.com. Before sending stopped, the status was always 250.
    3.To resume sending, I just need to call rebind.
  3. Using the following commands:
kcli queue-summary --by-volume --limit 200 | grep 'qq'

The result is:

(mx3|mx2|mx1).qq.com          source1 smtp_client      151,063      0  0 1,024

kcli queue-summary --by-volume --limit 200 | grep 'source1'

The result is empty.

  1. Using /api/admin/suspend/v1 and /api/admin/suspend-ready-q/v1 to check for suspends also returned no results.

Do you have any other better troubleshooting methods? Much appreciated.

I am using the latest version of Kumomta. config： allinone.toml · GitHub

3

What is your rate to sending to qq.com? Personally it’s just really hard to deliver to Chinese inboxes. Especially if they determine they don’t like you very much. We deliver mail incredibly slow to qq.com and try to limit as connections to as few as possible. That tends to work but is still very slow.

4

Yes, it is indeed difficult. The speed for each IP is 50 to 60 per minute, and after some time it can be adjusted to 120 per minute, but there is also a daily sending volume limit. That’s why we have many IPs delivering to China’s qq.com.
I haven’t encountered any issues with other ISPs, but for qq.com, I’m not sure why the queue often stops sending, and there is no spam involved.

5

Sorry if this is obvious, but you didn’t mention it so thought it would be worth mentioning. Have you tried ‘kcli trace-smtp-client’? That should give you clues in what is happening when the connection is being made. Your limits sound reasonable to me, but maybe it needs to be lower. For example if qq is doing this based on the domain rather than the IP, per IP may be too much.

6

Thank you. The queue data has been there for over 10 hours. It’s not being triggered; it’s the queue backlog because the sending speed is too slow.

7

Troubleshooting KumoMTA - KumoMTA Docs I have tried every item in the documentation, but still got nothing.

After restarting kumomta, there have been no issues for several hours. Yesterday, before the restart, the problem occurred several times every few hours.

8

Could also be related to throttles

9

Thanks for the reply. Although I have multiple kumomta instances, I haven’t set up a cluster with Redis, nor have I used throttle. Of course, if throttle were the cause, rebind would also be restricted.

10

Are you getting delayed messages in the logs? Not tempfail but delay?

11

I did not log delayed logs (including local logs) because qq.com’s rate limiting would likely generate a large number of delayed logs. qq.com has a daily sending volume of 10 million, and each IP can send only 80 messages per minute.