Wez Furlong
b64219bab4
We've seen evidence in some logs that it is possible to end up with a protocol synchronization issue where we get back a 354 response (which can only occur from the DATA verb) when we think we just sent RCPT TO. It is unclear where the error is coming from as the logic in the smtp client is already fairly defensive and emits speculative RSET calls for each message. What I suspect might be happening is that we somehow encounter a transient issue where we don't assertively close the connection. We do have what I considered to be fairly exhaustive handling of the various error cases in the smtp_dispatcher deliver_message function, so it's not obvious where the issue might be coming from. So, what does this commit do? * Refactor the smtp client logic code that is responsible for sending the request side of things so that we just have two cases, rather than the previous handful * If the write fails either due to a timeout or because of some other transport error, we now expliticly break the client by clearing out its socket field. This will prevent continued use of the client. * in smtp_dispatcher, if we end a send with a broken client and haven't already propagated an error up to the caller, we will raise an error. That will cause the session to try the next host in the connection plan or just tear down the session depending on the overall state of that session.
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.