Hello, i encounter some problem recenty. All email being sent to @gmail.com is unable to sent, it being delayed with this context: DueTimeWasReached, ReadyQueueWasFull. Next due in XXs. But, another domain that also using google mail for business is delivered. Where is the problem is happend? Thank you.
read and do first please
sorry for late update of it. i’ve trace the smtp client. no connection is made into mail with @gmail.com and go straight to delayed. but another mail using google business suite is delivered
This is what I meant for you to read and do first.
No one can help resolve your problem if you don’t provide all of the information.
My guess is that you have a shaping or source misconfiguration, but it is impossible to tell without seeing your configs.
aight i’ll sent it later. it happend this noon in my timezone. i’ve use kumomta for last 5 month and everything works fine
If your ReadyQueue is full, then the mail is not able to egress. There is either a configuration problem or all mail from that Source is being actively blocked. Again, imposible to tell without the full data set.
This problem occurs during the transfer of messages from Scheduled Queue to Ready Queue.
- Check traffic shaping . I guess it’s most likely that the content sent triggered Gmail’s restrictions that slowed down the sending speed.
- Adjust Ready Queue capacity: Increase the max_ready setting to allow more messages to be queued, which of course will increase memory usage. However, the default 1024 is sufficient.
3.Check provider_connection_limit whether it is appropriate
In my experience, the most likely thing is Gmail’s shaping.
You can exec
kcli queue-summary --by-volume | grep 'your_egress_source'
to see whether gmail is limited.
aight i’ll try it later if happend again. last time i just reset the queue and restart the kumomta container, and everything works again
last time when that occour, at first i think it was our ip transit network again the root cause, so i configure kumomta to use 2 ip addresses. i think single ip isn’t much nowdays due our email volume increased from 30k to 100k per days since i switched all transactional notification from all channel from postfix to kumomta one, so i decided to use 1 ip from our ip transit network, and 1 leased ip from the isp as safetynet. since the balancing works and the error not happend again, i leave it as-is for now 
keeping single ip last time due to requesting ptr record to be change from isp side is… kinda troublesome and slow and the ip transit one is managed via fortinet and i dont have access to it 