3221: Better PROXY_PROTOCOL r=mergify[bot] a=nextgens
## What type of PR?
Feature
## What does this PR do?
- Disable IMAP, POP3 and Submission by default; see https://nostarttls.secvuln.info/ on why explicit TLS is going away.
- Change the semantic of PROXY_PROTOCOL to make it configurable per port
- fix TLS_FLAVOR=notls not working with snappymail
- fix TLS_PERMISSIVE
- remove KUBERNETES_INGRESS; shouldn't be needed anymore
- update the documentation and the reverse proxy example
### Related issue(s)
- close#3162
- close#3061
## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [x] In case of feature or enhancement: documentation updated accordingly
- [x] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.
Co-authored-by: Florent Daigniere <nextgens@freenetproject.org>
Co-authored-by: Florent Daigniere <nextgens@users.noreply.github.com>
This is done by setting sieve_vacation_to_header_ignore_envelope to yes
The envelope is rewritten by recipent_canonical_maps to reverse SRS after the plugin checks it
so we need the plugin to ignore it at this point.
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.
