Previously, if we encountered a DNS resolution error we'd reinsert
the associated message into the scheduled queue for retry in about
a minute.
That doesn't respect the retry interval or, as it turns out, the
queue expiration policy.
This commit adjusts the logic so that we do bump the number of
attempts and check the expiration.
This change will also apply to errors triggered by lua/webhook
code that fails to create a connection object, and for maildir
writes that fail.
closes: https://github.com/KumoCorp/kumomta/issues/65
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
It turns out that ehlo_domain isn't valid for make_egress_source,
even though that is what we'd documented.
This commit surfaces this class of error visibly.
refs: https://github.com/KumoCorp/kumomta/issues/59
If you set `rfc5321=trace` in the diagnostic log filter, we will
now trace the commands we send and their responses, making it
easier to diagnose the outbound SMTP state especially when TLS
is enabled.
refs: #59
This is not on by default, and is not currently enabled
for KumoMTA.
Using openssl is currently about 3x faster than the pure rust
RSA crate, and inline with the perf of the ring crate, which
we could use here instead, but which doesn't support keys of
size 1024 which are currently widely deployed by the industry,
and for which larger sizes do not fit in DNS records.
We can exploit eg: knowing that the list of headers is a unique
list (no repeated headers) and save some overhead when using the
same signer multiple times.
This help transitions to a cheaper email parser, that doesn't need to
parse the entire MIME structure
Note that as part of this, I found that several tests were running
against email messages using unix line endings instead of canonical
CRLF.
This was silently being masked and an empty or otherwise incorrect byte
slice was being hashed; I've updated the affected tests and their test
expectations accordingly, as well as made this error bubble up at the
time of parsing the email, rather than silently squashing it in the
depths of the hasher.
This doesn't totally eliminate them, but for the body at least,
we can stream and hash the data and avoid making potentially
very many very large allocations in a busy signing application.
This is a much more efficient implementation with ~20% improved
throughput and latency with the simple signing benchmark.
signing/sign time: [1.3024 ms 1.3050 ms 1.3076 ms]
thrpt: [2.2886 MiB/s 2.2933 MiB/s 2.2978 MiB/s]
change:
time: [-19.016% -18.855% -18.691%] (p = 0.00 < 0.05)
thrpt: [+22.987% +23.237% +23.482%]
Performance has improved.
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.
Wez Furlong
Ben Dyer