I think something got screwed up somewhere, because I'm sure this
used to work, but: the value wasn't being parsed out of the loaded
data.
Add an integration test to assert that we can load things.
This test may need some auto-detection to run successfully on CI.
Let's see what happens.
Make use of our new ability to memoize the compiled domain map
so that we can avoid rebuilding it on each lua hook invocation.
This should improve performance for sites with large numbers of
listener domains.
This allows us to avoid rebuilding the map on each message reception
when using the dkim helpers, which should improve the performance
for sites with large numbers of signing domains.
This is a step towards allowing native rust data types to be
memoized. The cached values can now conceptually store other
data than just json, although we still only store json.
The intent is to allow this to be used from shaping.lua,
but a little more plumbing is needed before we can call it
from there.
Added some tests to sanity check that the data looks right.
This moves things around a bit so that we can parse the shaping.toml
data from rust, and expands it to add automation entries per-domain.
A new tool `validate-shaping` can now be used to validate the
shaping configuration independently of starting the server and
injecting mail.
Using the init_with_tsa.lua policy for kumod, together with
tsa_init.lua as the policy for tsa-daemon, logs from kumod
are now sent to tsa-daemon.
It doesn't do anything with them yet.
Introduce a setup_with_automation entrypoint that will accept
a richer parameter struct to specify the shaping automation
daemon(s) to which to push logs and from which we will pull
configuration.
This is just a refactor: none of that stuff is done yet.
Wez Furlong
Mike Hillyer
Tom Mairs