The name is passed through to should_enqueue_log_record as an additonal
parameter to make it possible to reason about whether a given record
should get queued for a specific log hook instance.
This is a breaking change, but it can be easily resolved by adding
the name parameter to the `configure_log_hook` call.
To support distributed connection limits, adjust the way that
connection limits are handled.
Previously, we'd do a simple in-memory comparison with the limit to
guide whether we had reached the limit.
In a distributed/clustered scenario we need a shared understanding
of the state of the connections, so we're moving to a lease-based
model.
Each connection is associated with a UUID.
Each egress path maintains a set of connections and their UUIDs.
When attempting to make a new connection, we can only proceed if the
number of connections associated with an egress path is below the limit.
When a connection is closed, its UUID is removed from the associated
set.
To handle crashes, kills and netsplits, the path -> uuid association is
also accompanied by an expiration time beyond which it can be assumed
that the lease is no longer valid. We compute that time based on the
worst case timeout value for a single message send on the given pathway.
Each time a connection is ready to obtain a new message, it will try
to extend its lease by that same duration.
This commit introduces these concepts and models them using an in-memory
store for the single node case, and using redis for the cluster case.
When your policy enables `kumo.configure_redis_throttles`, that same
redis configuration is used to back to the connection limiting
functionality.
refs: https://github.com/KumoCorp/kumomta/issues/41
Enable that field and add it to the fallback used by the
smtp_dispatcher. The ehlo_domain configured for the pathway
takes precedence, then we'll take the value from the source,
then fallback to the local hostname.
refs: https://github.com/KumoCorp/kumomta/issues/59
We don't set received_via for http because axum/hyper make it a
bit weird to access that information and it will require some
effort to figure out how to get that without breaking the
existing proxy-aware client IP determination.
This commit also includes a policy helper
`policy_extras.listener_domains` to make it convenient to define
listener domains in toml and/or json files.
To facilitate this, the DomainMap rust structure has been exposed
to lua code via the new `kumo.domain_map.new` function.
Switch the configuration plumbing for pools and sources to be pull-based
rather than push based.
In other words, rather than defining them in the `init` event,
you now need to supply them to the new `get_egress_pool` and
`get_egress_source` events.
Data is cached by default for 1 minute. This allows for new sources
to come into being on-demand, and for data to age out and change
over time, without requiring that the server be restarted.
This commit updates the reference section, but there is some content
in the user guide that refers to the old style of configuration that
will need to be updated.
refs: https://github.com/KumoCorp/kumomta/issues/13
I used a config like this for testing:
```
global
log stdout format raw local0 debug
defaults
timeout connect 10s
timeout client 30s
timeout server 30s
log global
listen outboundsmtp
log global
bind 0:2526 accept-proxy
mode tcp
use-server v4 if { src 0.0.0.0/0 }
use-server v6 if { src ::/0 }
server v4 0.0.0.0 source 0.0.0.0 usesrc clientip
server v6 ::: source ::: usesrc clientip
```
Launched via:
```console
$ sudo haproxy -f assets/haproxy.conf -V
```
with the source:
```lua
kumo.define_egress_source {
name = 'w00t',
ha_proxy_server = '127.0.0.1:2526',
ha_proxy_source_address = '192.168.1.92',
}
```
refs: #19
This makes it easier to compose secret management with a variety
of lua functions without having to build that directly into each
of them.
In particular: one can now use vaults or other secret stores that
we add in the future to manage credentials for HTTP clients.
M.L. Oelering
Wez Furlong
Tom Mairs
Mike Hillyer