Wez Furlong
64fac57d09
The recent changes to enable shaping based on a pattern-matched provider are nice, but it is important to be able to observe their effects. So far this has been awkward because the provider concept was purely a function of the logic in the shaping.lua file and nothing else. This commit introduces the concept of a `provider_name` field in both the EgressPathConfig and QueueConfig structs. The idea is that the `get_egress_path_config` and `get_queue_config` events are free to populate this field as makes sense to them, so that the core is then aware of which provider is associated with those queues. Once we have that data, we're then able to log it as a field in the JsonLogRecord. That is what this commit does. There are some interesting points to note about the implementation here: 1. shaping.lua will implicitly assign provider_name if it matches any providers. 2. It is technically possible for a shaping.toml to define multiple providers that match a given domain. In that circumstance, the last matching provider is the winner when it comes to assigning the provider_name field. 3. In order to populate the provider_name in the queue.lua helper, we need to be able to call out to the get_egress_path_config event handlers, so a new kumo.invoke_get_egress_path_config has been added to support that. 4. kumo.invoke_get_egress_path_config isn't 100% done: there are a couple of fields (openssl related) that don't have a defined serializer, so we're simply omitting them. The function is "done enough" for the purposes of retrieving the provider_name refs: https://github.com/KumoCorp/kumomta/issues/276
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.