2924: Remove the usage of capabilities, use port 8080 for admin r=nextgens a=nextgens
## What type of PR?
bug-fix
## What does this PR do?
In the real world users can't get them to work... I wonder if they use patched-up kernels or if xattrs are lost somehow... in any case, we can do without capabilities so let's do that.
Ensure that dovecot doesn't attempt to bind a v6 socket if SUBNET6 is not configured
Also, document that systemd-resolve may cause trouble with DNSSEC.
### Related issue(s)
- closes#2906
- closes#2913
## 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>
All override files are used as if they were placed in the rspamd
local.d folder.
From the newsfragment:
New override system for Rspamd. In the old system, all files were placed in the Rspamd overrides folder.
These overrides would override everything, including the Mailu Rspamd config.
Now overrides are placed in /overrides.
If you use your own map files, change the location to /override/myMapFile.map in the corresponding conf file.
It works as following.
* If the override file overrides a Mailu defined config file,
it will be included in the Mailu config file with lowest priority.
It will merge with existing sections.
* If the override file does not override a Mailu defined config file,
then the file will be placed in the rspamd local.d folder.
It will merge with existing sections.
For more information, see the description of the local.d folder on the rspamd website:
https://www.rspamd.com/doc/faq.html#what-are-the-locald-and-overrided-directories
2479: Rework the anti-spoofing rule r=mergify[bot] a=nextgens
## What type of PR?
Feature
## What does this PR do?
We shouldn't assume that Mailu is the only MTA allowed to send emails on behalf of the domains it hosts.
We should also ensure that it's non-trivial for email-spoofing of hosted domains to happen
Previously we were preventing any spoofing of the envelope from; Now we are preventing spoofing of both the envelope from and the header from unless some form of authentication passes (is a RELAYHOST, SPF, DKIM, ARC)
### Related issue(s)
- close#2475
## 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>
