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. > > 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. > > 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/ > > Regards. >
