We had some feedback that it would be nice to be able to influence
the set of ca-certs allowed by the client, which isn't possible
when using the hard-coded list in webpki-roots.
This commit is a fairly dumb application of the example shown
in the readme for rustls-platform-verifier.
We had a user report that launching kumod
post-7fbec8758720dad465d711458f6bf7923b778773 produced a panic about the
spool not being configured.
My supposition is that they were bringing the system up under load
(incoming traffic) and that a new message was being injected before we
had started the spool.
So what we do here is restore the spool_started check, but have it
be satisfied once the startup has been triggered, rather than
on completion of enumeration.
The result is that there is still a small window where we might turn
away a message during startup, but it should be very very small.
This is a bit of a weird one, but the gist of it is that a sequence
of qp encoded words separated by spaces is, per the spec, re-assembled
and the spaces between the encoded words is ignored.
That means that any pair of adjacent encoded words should really
collapsed into a single encoded word that internally includes the
space in order for it to round trip.
To make things a little more complicated, the underlying quoted
printable crate that we're using implements the base qp space rather
than the modified version used by rfc2047 and it will strip trailing
whitespace from the words that are being encoded.
What we do here in this commit is an improvement, but may still
be subject to nuance in the future:
When rebuilding a header value, instead of splitting by space and
emitting a series of encoded words, we will now produce a single
encoded word for the entire header. That word may be split and
wrapped as needed to ensure that the maximum line length is
respected.
rocksdb has its own internal option that overrides the cpu
target, so we need to be sure to tell it not to do that
using this option, otherwise we can cause illegal instruction
errors in the resulting executable.
I'm seeing some illegal instruction errors on the build cluster
and I suspect that something is being tuned to a cpu on one
node and isn't 100% compatible with another node.
This commit arranges for the image builder to produce a static
build of rocksdb, and then for the populate-cache-vars.sh script
to detect that and update the environment so that the build picks
up that pre-built rocksdb instead of building a vendored version
of rocksdb on every CI run.
These are almost identical to those used by smtp, the main difference
being that we don't include the Received header by default for
http injection, whereas we do for smtp in order to be compliant
with the relevant rfcs. No such rfcs exist for the injection
protocol, so we can pick a default that makes more sense for the
majority of our target audience.
We were collecting the logs, printing them as we found them, and
then returning the sorted result.
That made it awkward for a human to review, so what we do now
is defer printing the logged records until after we have sorted
them.
For records with the same timestamp, we sort based on the message
id and the record type so that there is some additional consistency
and to make it easier to reason about.
Problem scenario: you have defined an automation rule with the
unanchored regex `detected an unusual rate` that triggers a suspension.
What happens: when the remote host initially responds and that
rule matches, a suspension will be created. When subsequent
messages are checked against that rule, the message will not
be attempted (good), but we will generate and log a transient failure
response of the form: `KumoMTA internal: suspended, rule: detected an
unusual rate`. When that response is presented to TSA, since the regex
is unanchored, the original rule will also match it, and that will
cause the duration to be reset, effectively perpetuating the suspension
until the combination of ingress and the retry window exceeds the
duration specified in the rule (bad).
You can explicity mark up your regex with an anchor to prevent
this sort of matching, but it is a PITA to do that for every
suspension rule.
This commit resolves this issue by recognizing that the default
should be to not match internally generated rules. The newly
introduced `match_internal` boolean defaults to false and controls
whether we should consider these internal messages, and allows
the matching to be turned on when needed. We use this in one
of the default shaping rules that is used to disable the use
of tls for broken hosts.
Wez Furlong
Dirkjan Ochtman
Mike Hillyer