This commit refactors the EnvelopeAddress types(!) so that the brains
of them are centralized in the rfc5321 crate, removes the one from
the log-types crate, and replaces the internals of the one in the
message crate with the rfc5321 implementation.
This revised implementation accommodates quoted local parts more
consistently and exposes the local part via a normalizing accessor which
is in turn used when comparing addresses for equality.
This means that `"foo"@` and `foo@` now compare the same, and if you
have setup a maildir that generates per-user maildirs, we'll use the
normalized form of the local part rather than whatever is on the
incoming address.
Another side effect of this commit is that we can now accept exotic
quoted addresses like `"info@"@example.com` without falsely complaining
about having too many `@` signs in the address.
closes: https://github.com/KumoCorp/kumomta/issues/495
We were propagating the parse error as a server error and mapping it
to the 421 technical difficulties response instead of returning
the appropriate syntax error response defined by SMTP.
refs: https://github.com/KumoCorp/kumomta/issues/495
This was just a temporary measure while refactoring for
binary support, so that I could stay on top of legacy
callers.
The remaining callers now all legitimately need to process
str values, so that's fine.
Previously, we'd use a lossy conversion that would replace
funky sequences with the unicode replacement character.
This commit will instead print the bad bytes as hex-escaped characters.
This can be useful when troubleshooting things in tests; this commit
also turns up info logging for the lua test runner so that we can see
that, although nothing else in this commit actually calls that.
I did use it while troubleshooting things just now though, so it is
generally useful.
These are more immediately useful to me for writing tests, but are
generally useful when you have a policy that might need to to deal
with legacy encoding schemes more directly.
Our behavior has changed so it is acceptable to change the test
expectations.
We now return the binary bytes as-is for non-conforming inputs,
rather than attempting an implicit and lossy UTF-8 conversion.
When I updated this crate for binary inputs, I switched from
str::split_ascii_whitespace() to slice::split(u8::is_ascii_whitespace).
This subtly alters the semantics; the former will not yield an empty
word in the trailing whitespace case, while the latter does.
Handle this by explicitly skipping an empty word.
This fixes up one of our lua test cases for wrapping long headers with
trailing whitespace.
There's a bit of fuss around migrating the `char` nom parsing function
to `tag`, which is required for operating on bytes. We need to jump
through some hoops in order to be able to show what tag was expected
if there is a mismatch. That improves the output of our parse error
type to have less redundant information, so overall I'd say that
that is a plus.
A number of 8-bit related tests now fail and some continue to fail
from an earlier commit in this refactoring series. We can now
start to tackle whether those need to be adjusted to the amended
API surface, or whether we need to add some supporting context
for those, on a case by case basis in follow-up commits.
This is ostensibly "just" making the nom parsing functions return
BString instead of String, but the fan-out makes the commit much larger,
as a number of surfaces (eg: as_unstructured) have now changed types.
Removes the deref to str as this is now a fallible operation that
can panic.
Process the fanout of this change, which is dealing with more
possibility that things might be binary in more places.
There are some transitional APIs introduced as deprecated so that I'm
nagged to remove them already: I want to get the bulk of the code aware
of the possibility of binary sorted before I tackle adjusting the
message parser for that, so that that particular commit is more
self-contained.
This is a step towards allowing non-UTF-8 data to be tracked
in the SharedString type.
It is not complete; some tests now panic with UTF-8 input where
they would previously implicitly perform a lossy conversion.
That will be resolved in subsequent commit(s).
It was pointed out that we had this policy and that it wasn't part of
the spec.
That behavior was imported along with the crate when we forked it from
the cloudflare implementation.
Let's remove it; folks that need it can use a couple of lines of lua to
recreate it if they need it.
This is similar the prior two commits; this one summarizes the case
where socks5 is in use and the bind(2) fails on the proxy server,
indicating unplumbed addresses on the server.
We cannot do the equivalent with HA proxy as its protocol has
no provision for this sort of feedback.
Similar to how we summarize and inform when all connection errors
are due to broken TLS, recognize and inform when all connection
errors are due to a source_address that cannot be bound due to
the address not being plumbed on the system. This does not
include other reasons that `bind(2)` can fail, just the case
where the address is not present.
Add an integration test to capture the error message for
that situation, for easier future reference.
These utilities would simplistically assume that the input domain
was always a valid DNS name, which is true for the majority of
things, but our internal webhook, TSA and xfer queue names include
http URLs and would choke these utilities.
We now fall back to using the input "domain" if the MX resolution
attempt throws an error; the error is typically a failure to parse
rather than something like NXDOMAIN which is generally returned as an
empty result.
This is a follow on from the previous commit; apparently some sites
will enclose addresses in <> even though this is not covered in the
RFC.
Let's cut the address parsing over to the SMTP parser rather than
the mail header parser, as they have rather different semantics
and both ARF and OOB are SMTP-centric.
We had a report that the enclosing <> were being passed through
to the JsonLogRecord in some log hook flows, which meant that
we'd try to parse them as EnvelopeAddresses and fail.
dependabot[bot]
Wez Furlong
Mike Hillyer
Mike Hillyer