This will only trigger for messages where we've gotten to MAIL FROM or
later, and where we got a non-250 response.
The event is passed the response + the domain, tenant, campaign and
routing domain. It can return an alternative response code value
or `null` to indicate no change.
This is useful for efficiently matching a string simultaneously against
multiple regular expressions.
The motivating use case is to use it together with the
smtp_client_rewrite_delivery_status event.
Avoid referencing implementation details that we may change
(install.sh).
Document what goes where with a bit of explanation.
Remove examples that show launching `kumod &` as we do not recommend
running the service in the background without some kind of supervision
(such as systemd). Instead, show how how to run the process and leave
it to the reader to decide how they with to deploy it in their
environment.
closes: https://github.com/KumoCorp/kumomta/issues/72
New users trip over the very conservative defaults on log flushing,
so let's make the `init.lua` that we populate for new installs
set the duration to 10 seconds by default, and adjust the language
in the docs to match that.
Clarify the logging documentation about how the logs are
chunked/flushed.
This was a 2-in-1 issue really.
When a message line starts with a `.` we are required to encode it
by prefixing the line with an additional `.`, aka: "dot stuffing".
In our implementation of this we would unintentionally remap CRLF
to CR, and then fail to emit CRLF.CRLF at the end of the data
that we'd planned to send.
The result of this was that we're hang waiting for the remote host
to respond to our DATA, meanwhile, it was waiting for the end of
our data. We'd sit there until either side reached their respective
timeout for the data phase.
This commit fixes up both parts of this bug.
Wez Furlong
Mike Hillyer
Tom Mairs
Tom Mairs