Allow multiple should_enqueue_log_record hooks to be registered,
and take advantage of that inside the shaping helper.
`shaper.should_enqueue_log_record` no longer needs to be explicitly
plumbed from the config, but we allow calling it still for compatibility
reasons.
We will remove that compatibility after the next stable release.
Take advantage of the ability to define multiple get_queue_config
callbacks by internalizing the TSA webhook queue configuration.
`shaper.get_queue_config` no longer needs to be called, and
that fragment of code will continue to "work" by simply not
having an effect so that we don't break folks on upgrade.
We'll remove this compatibility in the release following
the next stable release.
Previously, we'd restrict `kumo.on` to allowing just a single
instance of an event to be registered. The purpose of this was
to help surface logical errors where copypasta would result in
a bogus configuration.
With multiple helper lua modules now wanting to take responsibility
for some portion of the event handling, it is becoming more complex
to stitch things together.
It is desirable to allow multiple handlers for certain events,
so that a module can handle just its area of responsibility
without worry other modules about it.
This commit introduces a CallbackSignature type that allows
defining the function signature for event callbacks.
The signature can be pre-created and registered ahead of setting
up any lua contexts, which allows declaring whether an event
can have multiple callbacks registered.
The `get_queue_config` event handler has been set to allow multiple
callbacks.
This will only trigger for messages where we've gotten to MAIL FROM or
later, and where we got a non-250 response.
The event is passed the response + the domain, tenant, campaign and
routing domain. It can return an alternative response code value
or `null` to indicate no change.
This is useful for efficiently matching a string simultaneously against
multiple regular expressions.
The motivating use case is to use it together with the
smtp_client_rewrite_delivery_status event.
Avoid referencing implementation details that we may change
(install.sh).
Document what goes where with a bit of explanation.
Remove examples that show launching `kumod &` as we do not recommend
running the service in the background without some kind of supervision
(such as systemd). Instead, show how how to run the process and leave
it to the reader to decide how they with to deploy it in their
environment.
closes: https://github.com/KumoCorp/kumomta/issues/72
New users trip over the very conservative defaults on log flushing,
so let's make the `init.lua` that we populate for new installs
set the duration to 10 seconds by default, and adjust the language
in the docs to match that.
Clarify the logging documentation about how the logs are
chunked/flushed.
Mike Hillyer
Wez Furlong
Tom Mairs
Tom Mairs