3350: Feature: dkim for alternative domains r=mergify[bot] a=Jumper78
## What type of PR?
feature
## What does this PR do?
### General Idea
#### use same DKIM key of main domain for signing
Instead of dealing with key creation for each alternative domain, this implementation of the solution uses one key for all domains, the main domain and all alternative domains. Upon Rspamd requesting the DKIM key of a domain, it is not only checked if the domain is in the list of main domains, it also checked if it part of the alternative domains. If it is in this list, it sends the DKIM key of the connected main domain together with the name of the alternative domain.
#### show needed entries in the domain detailed view of the main domain
To make it easier for the admin to create the DKIM and DMARC entries (and the MX and SPF entries) for the alternative domains, we go through all alternative domains and print the entries.
### missing (and currently not planned to be added)
The zonefile at the top of the detail page will still only cover the main domain.
### Related issue(s)
- DKIM signing of the alternative domains is a requested feature; it closes#1519
- it keeps the original file based handling of DKIM keys; it does not implement #2952
## 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.
- [ ] 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: Jumper78 <52802286+Jumper78@users.noreply.github.com>
When rspamd looks up the DKIM key of the domains, also the alternative domains are queried. In case there is a match, the admin container is providing the DKIM key of the domain belonging to the alternative domain.
file modified: core/admin/mailu/internal/views/rspamd.py
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.
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>
