When the client used the (inefficient!) multi-stage variant
of AUTH PLAIN, we didn't send the 334 response, so both
parties sat waiting for each other and eventually timed out.
This makes it super easy to template the whole message; it will be
parsed and rebuilt with appropriate transfer encoding and wrapping.
Fixup an issue where some of the header fields in the builder variant
of the API were not templated or added to the message.
Skip adding transfer encoding header when it is not needed.
With the upgraded ed25519-dalek crate, it's now possible to
pass in either DER or PEM encoded PKCS8 signing keys, which
makes it feasible to remove the mail-auth dep from this crate.
That in turns reduces the amount of code in here, which is nice.
Two issues:
* A kumo.reject(421,...) wasn't guaranteed to terminate the session,
so make it do that.
* A non-421 kumo.reject would prevent the current candidate message from
being queued, but could result in a spurious additional 250 ok
response.
Refactor the data phase processing so that we first make a pass
over the messages to allow allow of them to be assessed by the
event before we commit to logging and injecting any of them.
Since the spool system is not (and cannot be made to be)
transactional across multiple messages, there is still a possibility
that a failure to spool at this stage will result in the
previously accepted messages from that batch being accepted,
event though we will then respond to the client with a failure
code.
closes: https://github.com/KumoCorp/kumomta/issues/79
This commit causes the scheduled queue maintainer to refresh
the queue config by calling the get_queue_config event approximately
every minute while the queue is alive.
In addition, we now thread the routing_domain through to get_queue_config
We had a user get tripped up by the incorrect example on this page.
I think they probably should have been using the helper, but the
way this page was constructed, it was easy to keep reading past
the bit about the helper and get bogged down by the lua examples.
Rearrange this page to try to avoid that.
I've seen this trip up at least two people so far.
While we're in there, update the example to show how to memoize and make
it both easier to write and more efficient at runtime.
This allows listing out authorization identities.
If the incoming client is authorized to act as one of the listed
`relay_from_authz` authorization identities, then the incoming
session will be added to the relay_from CIDR for the scope of
that connected session, and the result is that they will be allowed
to relay from the associated domain.
This is useful if you want to give a tenant SMTP auth credentials
but only want to allow them to send from the domain(s) that
they are permitted to send as/from.