Stephan Bosch [Mon, 3 Dec 2018 17:45:43 +0000 (18:45 +0100)]
lib-smtp: client: Make sending the XCLIENT command(s) always implicit and do it only once.
For most servers, XCLIENT changes the ip:port identity of the client, causing it
to lose privileges to send more XCLIENT commands. For long XCLIENT commands
split in a series of XCLIENT commands, the ip:port parameters were sent last
already, so that did not cause problems even before this change. However, the
old code assumed it could update XCLIENT fields later on, which is often not
possible.
Stephan Bosch [Mon, 3 Dec 2018 17:45:42 +0000 (18:45 +0100)]
lib-smtp: client: Allow deferring sending the XCLIENT command until authentication or first mail transaction.
This allows updating the proxy data until the XCLIENT command actually needs to
be sent. For submission, this means that later EHLO domain changes can still be
accounted for. This change makes the simplifications in subsequent changes
easier.
Timo Sirainen [Wed, 31 Oct 2018 15:19:42 +0000 (17:19 +0200)]
lib-fs: If fs_get_metadata() isn't implemented, return internal metadata anyway
The metadata is sometimes used for transferring internal metadata within the
files. This metadata isn't stored to disk. So even if the fs driver doesn't
support metadata at all, it should still be possible to get/set the internal
metadata. Setting it was already possible, but getting wasn't.
Stephan Bosch [Thu, 1 Nov 2018 00:14:50 +0000 (01:14 +0100)]
lib-smtp: server: recipient: Hold a reference to the recipient while calling a non-destroy hook.
Prevents memory problems when the hook inadvertently gets the recipient
destroyed. Unlike the server command, this is not strictly necessary for the
recipient object, but we add this anyway to prevent future problems when the
recipient implementation becomes more complex (e.g. with additional hooks).
Unlike the server command, this is not strictly necessary for the recipient
object, but we add this anyway to prevent future problems when the recipient
implementation becomes more complex.
Stephan Bosch [Fri, 26 Oct 2018 19:00:00 +0000 (21:00 +0200)]
submission: Add support for modifying the transaction path and parameters in the trans_start backend vfunc.
To keep the changes limited to a particular backend, the server transaction
cannot be modified. Also, creating a mock server transaction and passing it on
is not a good idea, since it is not a simple container struct.
Stephan Bosch [Thu, 18 Oct 2018 21:35:05 +0000 (23:35 +0200)]
submission: Add backend vfunc called when the backend is ready.
For a relay backend, this means that the connection is fully connected and
handshaked. For any backend it means the capabilities are known (and passed as a
parameter to the ready function).
Stephan Bosch [Fri, 19 Oct 2018 15:12:10 +0000 (17:12 +0200)]
submission: relay backend: VRFY command: Avoid forwarding 500 and 502 replies back to client.
These are in fact non-standard for VRFY and indicate that VRFY support is
disabled, which is not allowed by the specification. Instead, we now substitute
the default 252 response.
Stephan Bosch [Thu, 18 Oct 2018 22:35:53 +0000 (00:35 +0200)]
submission: relay backend: Fix non-transaction commands to work when submission_backend_capabilities is configured.
When submission_backend_capabilities is configured, the backend is not started
until the first transaction is started. But for commands that should work
outside the transaction, the backend should also be started, which was not the
case before this fix.
Stephan Bosch [Fri, 12 Oct 2018 07:23:27 +0000 (09:23 +0200)]
submission: relay backend: Do not close the client connection for failure in a non-default backend.
Adjusts the backend API to remember the failure until the present transaction is
reset. In the mean time, any commands issued to the backend are failed
immediately. In contrast, failure on the default backend will cause the client
connection to be closed, like before.
Stephan Bosch [Wed, 10 Oct 2018 22:49:33 +0000 (00:49 +0200)]
lib-smtp: client: transaction: Add alternative function for adding a recipient on an application-provided pool.
This allows modifying the recipient object beyond approval. Before, it was
always moved to the transaction pool, thereby invalidating the original returned
pointer. This way, the data_calback and context can be set at a later time,
e.g. when the DATA command is being processed. This makes a choice between
LMTP-style and SMTP-style replies to the DATA command a bit easier to handle.
Also, the recipient is entirely allocated on a single pool between the client
and server side, which should improve memory consumption a little. As a bonus,
this removes the need to have dummy DATA callbacks.
Stephan Bosch [Sun, 14 Oct 2018 20:34:50 +0000 (22:34 +0200)]
submission: Fix starting secondary backends created before the server-side transaction is fully created.
Record an array of those backends and start them once the transaction is
created. Before, this was implemented using the array of approved recipients
(which each point to their backend). However, this does not work, since there
can be no approved recipients when there is no server-side transaction yet.
Stephan Bosch [Sun, 14 Oct 2018 21:00:11 +0000 (23:00 +0200)]
submission: relay backend: Properly manage the trans_started flag.
Sometimes it was not set at all. This didn't lead to problems in most cases, but
this was at least confusing while debugging. Also, the flag is set before the
client transaction is actually started, making sure (future) recursive problems
will not occur.