A number of our lua event handlers allow registering multiple implementations to facilitate modular use. For that to work, we must know ahead of the user lua call running that any given handle is allowed to register multiple times. This is so that we can report a meaningful error when incorrectly using a singleton handler multiple times, and so that we can record a list of handlers for the multiple case. Prior to this commit, if we forgot to arrange to register the signature as part of the context setup the consequence was that the event handler would get registered as a singleton and when we went to call it, because the signature is marked as allowing multiple but was not registered as multiple, we would skate through and do nothing without reporting an error because we assumed that the signature was registered consistently. In hindsight, that's a terrible idea because it results in silently ignoring the registration issue, and not calling the event handler at all. This commit consolidates the multiple/single value resolution into the same flow, then adds a check to confirm that we have a list of handlers registered for the allow_multiple case, raising an error otherwise that will hopefully encourage users to report this problem to us if it manifests again in the future. This commit includes fixing two event handlers that we missing their signature registration. One of them was broken anyway by being registered with a name that didn't match the docs. refs: https://github.com/KumoCorp/kumomta/issues/236
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.