Wez Furlong
5bb60b06d0
The goal is to treat peer-initiated-unilateral-disconnects as being somewhat equivalent to the way that we would idle out the connection if we had no messages for it, on the supposition that the most likely cause of a disconnect in between command verbs that we send is that the peer decided that we were idle too long. That isn't the only possible reason, but it is the motivating example. For the idled-out case we should close the current session and have our message(s) go out on a separate session. We don't want to try the next host in the connection plan in case we're talking to some kind of honey pit configuration where only the first MX in the plan is valid, and even talking to a secondary can harm your ability to send to the first in the future. Handling this is a little tricky because we need to take care of the distinction between getting a unilateral before or after we've attempted to send a message. In the before-case we don't want to blindly assume that we should start a new session because that would mean that a persistent issue on the first MX would have us spinning our wheels trying new connections only to the first MX over and over. This commit adds a couple of integration tests that contrive situations where we exercise some pertinent cases. refs: https://github.com/KumoCorp/kumomta/pull/482
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. Issues are for features and bugs only, any help requests posted to Issues will be closed. 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.