This is not perfect...
- dovecot now complains about waitpid/finding a new process
- postfix is still regularly pinging rspamd / his milter and that
generates a few lines worth of logs each time.
With this we avoid running into the limitations of
mail_max_userip_connections (see #894 amd #1364) and the
logfiles as well as ``doveadm who`` give an accurate picture.
Currently we are not able to offer our users a FTS experience after the
demise of lucene due to unfixed coredumps with musl/alpine.
We now add lucene, the only remaining maintained small/lean FTS plugin
for dovecot. It is quite simple to add to our stack: A two-stage docker
build is used to compile the fts plugin in the first stage, and copy
over only the resulting plugin-artifact to the second stage, which is
our usual dovecot container. Configuration is also minimal.
Before, the ham/spam scripts got the rspamd-ip/port from the environment.
However, when checking the environment of these processes now, it seems
cleared. Maybe the new dovecot version now clears environment? — I couldn’t
find a hint.
In any case, using the common mechanism of injecting the ip/port from where
it’s definately known by the already-used jinja2-mechanism seems reasonably
safe.
Postfix, after expanding the alias, is not transmitting the original
envelope recipient email address to dovecot and cannot record it in a
Received: header.
The LMTP DSN extension allows postfix to specify an ORCPT= parameter to
the "RCPT TO:" line (in postfix src/smtp/smtp_proto.c). However, dovecot
does not support the DNS extension on the LMTP endpoint. It has
preliminary support of the ORCPT parameter in latest versions but is is
disabled and not working.
The solution taken was to add a sieve script to parse the Received:
header written by postfix and parse the original RCPT TO address from
it. Then add the header through the "editheader" sieve extension. Later
sieve scripts can take this header to perform further filtering.
Florent Daigniere
lub