Wez Furlong
cd6b01dfe9
The queue logic assumes that if we get Some(duration) back from a throttle check that it must be a non-zero duration. We found a configuration that used a custom lua delivery handler together with a max_message_rate throttle. When running with local (non-redis) throttles it is possible that the in-memory throttle implementation can return a 0ns delay. This results in the queue subsystem choosing to requeue the message using the throttle duration as the delay, which results in the message being due immediately, which causes recursion into the insert-ready flow, which performs the same throttle check with the same 0ns result, and repeat until a stack overflow occurs on the spool in thread. The circumstances to trigger this are a bit niche and racy: if you turn up debug logging you can perturb the timing so that the stack overflow is not 100% repeatable. It is unlikely to cause a stack overflow on the inbound processing side because the threads doing that processing are multiplexing many other events that can also perturb the timing. This commit addresses this edge case in a very simple way: if the duration is 0, then we return `None` for the duration. This is actually how we handle this for one of the redis throttle implementations already. This commit makes the other two cases consistent with that.
KumoMTA
KumoMTA is an open-source Message Transfer Agent (MTA) designed for high-performance outbound email functionality, similar to commercial enterprise MTAs such as Momentum, PowerMTA, and Halon.
The KumoMTA project was founded by a group of email industry veterans with decades of experience building and managing high-performance On-Prem MTAs and is supported by a community of some of the largest senders in the world.
Because it is designed for high-performance sending environments, KumoMTA is for experienced email operations professionals who are accustomed to high-performance sending environments and familiar with DevOps practices.
Learn more in our FAQ and at https://kumomta.com/.
Documentation
You can learn more about KumoMTA from the Documentation.
Community
Real-time discussion is available on Our Discord.
Developers
If you are interested in contributing/extending KumoMTA, take a look at DEVELOPERS.md. The #devel channel on Our Discord is for contributors to discuss KumoMTA development.
Reporting Bugs
See How to Report Bugs.
Getting Help
See How to Get Help. For paid support see https://kumomta.com/support.
Getting Updates
You can subscribe to updates at https://kumomta.com/subscribe, we send updates periodically and will never sell nor share your information.
Talk to Us
We're available to talk about the project, book us at https://cal.com/team/kumomta/talk-with-kumomta.