Le 19/10/2022 à 09:10, Martijn van Duren a écrit :
On Wed, 2022-10-19 at 00:23 +0400, Archange wrote:
Le 19/10/2022 à 00:07, Martijn van Duren a écrit :
On Wed, 2022-10-19 at 00:02 +0400, Archange wrote:
Hi there,
Due to an issue with the rspamd filter running against rspamd 3.3
(https://github.com/poolpOrg/filter-rspamd/issues/41), I’m looking at
migrating my main server to dkimsign. I’m already using it on several
servers, but they all handle only one domain, and I’m now in need to
handle several domains (all incoming on the same interface).
Those might have different selectors, different keys… Is there a way to
specify those, or the only option is to have the same key and selector
for all domains?
Regards.
It's as you said, only a single key and selector can be used per
dkimsign instance. If I would allow multiple selectors/keys it would
require making the config a lot more complex without any additional
benefit that I can see at the time.
Not necessarily much more complex. I would just ditch -s/-k and make -d
accept domain:selector:keyfile triplets.
Why not take a step further?
domain:selector:keyfile:algorithm:canonicalization:headers
It opens the door to all kind of weirdness for which no real use case
has been presented yet.
You’re right.
This is probably not a good practice (e.g. I should likely have
different selector and dkim keys per server), but currently some domains
are shared with other servers and owners, and so is the dkim key for
those domains. I don’t want that key to be valid for other domains.
Bottom line, dkim is nothing more than "this entity" has seen this mail
in it's current form as long as the signature passes. The only reason
for adding support for multiple domains was because of dmarc, which
combines it with the question if the domain in the from-header matches
with the domain in the signature.
Bottom line is that it's not the domain that manages the key, but the
server and the domain only says that it trusts the server by handling
the public component.
Yeah, that is basically what I came to realize with this issue.
I guess the solution is indeed to switch to different keys per server
instead of per domain.
I'm not setting this in stone, but I need a little more then personal
preferences for adding more complexity to this piece of code which I
already consider quite the monster.
If you really want this you could probably redirect the mail back into
itself but on different ports and let every port have their own
dkimsign instance, similar to how the old dkimproxy setups would work:
https://myconan.net/blog/posts/4567/
I tried something like that in the first place but I was trying to do
things at the filters level and couldn’t find a way. Thanks for pointing
me towards the right direction, so for now (as it was easier to fix in
place rather than switch the whole setup) I ended up using `mail-from
regex "^.*@domain$"` to redirect on several local ports based on domain,
and then filtering to dkimsign for each.
