Hi [2025-01-26 04:24] "Antonios Chariton (daknob)" <dak...@daknob.net> > I’m migrating postfix servers to opensmtpd and one use case I found was a > single instance being responsible for e.g. 10 domains, where each domain has > its own DKIM key, selector, etc. Using opendkim this is easy to do. However, > with OpenBSD: > > filter-dkimsign works with "filter filter-name proc-exec command”, which > means that it’s a “filter” (duh). > > However, filters can only be applied in listeners with “listen on”, and not > “action”s or other configuration options. > > This means that I can’t create a “filter dkim-sign-example-org”, a “filter > dkim-sign-example-net”, and then choose which one to apply using a “match”.
Yes and this is perfect fine for most[0] usecases. For the included filters there is some sort of conditional, but this only works because they are more or less stateless and have some limited actions. > I’ll either have to create a filter chain and sign every e-mail with every > key, or rely on filter-dkimsign’s support for multiple “-d”s, which has its > own issues[1]. Both of these options aren’t great. > [1]: This requires all domains to have the same private key, and does not > work well with SRS as it fails to identify the correct domain and uses the > first one always. Why is the same private key for every domain a problem? I know Mailprovider which simply cname the domainkey selector to one master. Then sign with the host specific key and set the domain in the dkim field according to the sender-domain. Keep in mind that DKIM is designed to identify the sender's mailserver. Also your server already needs to have access to all private keys. So it's not a problem to share a private key for every domain. I don't get what you mean with does not work well with SRS. The SRS implementation is completly independent from filters. > Another alternative would be to outsource DKIM signing to rspamd, which is > slightly smarter, but this requires using rspamd even when the server is an > outgoing-only relay. Ingress filtering might also be a good idea, but this depends an how many users you have. > Of course, there’s always the option of writing my own smtpd-filters(7) > solution but this seems like a problem others have had in the past and > somehow solved, and I’m just missing it. > > I’ve read that the listeners can use a domain name instead of an interface or > IP address, but after looking at create_if_listener and host_dns in parse.y, > this simply resolves the domain and listens on the returned IPs, which makes > sense. The listen on domain name is just to have a better to read the config. It just resolves the name and binds to the address. > It’s not a recipient-domain-aware system, which is probably a good thing :) Did you mean sender? > Any ideas on whether this is possible and I just can’t figure it out, or if > it would require patches to be achieved? I would say you don't need this. Just use the -d option of filter-dkimsign with one key per mailserver. When you realy want to have this I see two options: Simples workaround would be to listen on multible ip addresses[1] with a filter for each listener. You could also ask the author of filter-dkimsign to add a feauter which allows key selection based on the sender domain. Philipp > > Thanks, > Antonis > > [1]: This requires all domains to have the same private key, and does not > work well with SRS as it fails to identify the correct domain and uses the > first one always. [0] There are some exeptions when you want to split up mail recipients, but this needs some other filter/pipe concept [1] Biggest problem with this is probably that you need legacy-ip and don't have enough ipv4 addresses.
