Just so folks see it can be done: dual-DKIM signing, and verification, with Exim. Jeremy did all the Exim code to manage this, I'm acting purely as a sysadmin in deploying this.
Exim 4.91, using OpenSSL 1.1.1-pre4, is the MTA for spodhuis.org; and is the next-exim for exim.org, so is the version listening on port 26; @spodhuis.org is sending mail to @exim.org on port 26. exim.org's normal port-25 Exim is also 4.91, but is using OpenSSL 1.1.0h. Note that RFC 6376 ยง 3.6.2.2 is very explicit that there can be only one key for a given selector, so you MUST use multiple selectors when signing, rather than two different algorithms under the same selector. My Exim configuration is rather grotesque and could do with a spring cleaning, but here's the relevant part of the SMTP Transport: dkim_domain = ${domain:$acl_m_dkim_sender_address} # CDB has: domain.tld: dYYYYMM=rsa dYYYYMMe2=ed25519 dkim_selector = ${sg{${sg{${lookup {$dkim_domain}cdb{CDBMAILTABLES/dkim.selectors.hermes.cdb} {$value}{OOPS}}}{\N=\w+\N}{}}}{\N\s+\N}{:}} dkim_private_key = ${if eq{$dkim_selector}{OOPS}{false}{DKKEYDIR/${extract{$dkim_selector}{${lookup {$dkim_domain}cdb{CDBMAILTABLES/dkim.selectors.hermes.cdb}}}}.private.$dkim_selector.$dkim_domain}} dkim_strict = ${if eq{$dkim_selector}{OOPS}{0}{1}} The $acl_m_dkim_sender_address boils down to $sender_address overridden by ${reduce{${addresses:$h_from:}}{}{$item}} if From: exists, in both the ACL connected to acl_smtp_data and the one connected to acl_not_smtp. With 4.91, when dkim_selector is a list, we expand dkim_private_key repeatedly, with $dkim_selector set to each element in turn of that list. (Commit 9e70917d0aa). At the current time, I'm sticking to RSA for ARC and haven't even looked at the options there. This mess is probably about at the point where I should be moving from CDB to SQL with materialized views expanding the canonical form out to easy forms to reason about from Exim's side. The attached message is from one of my email addresses to my exim.org address, where you can see Exim then verifying the signatures, before sending it back to me. Note that Ed25519 is "not something to rush to production", given that important parts of the specification have not yet been nailed down. With OpenSSL, it also requires a beta release, although things are a little more stable over in GnuTLS land. Note also that Gmail constructs an ARC-Authentication-Results: header with two dkim entries too, but the second is "neutral", not "pass". An example header of a message sent to Gmail: ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@spodhuis.org header.s=d201804 header.b=XvwARr12; dkim=neutral (no key) header.i=@spodhuis.org header.s=d201804e2 header.b=1q0qppzF; spf=pass (google.com: domain of prvs=064468e5c1=phil.penn...@spodhuis.org designates 94.142.241.89 as permitted sender) smtp.mailfrom=prvs=064468e5c1=phil.penn...@spodhuis.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=spodhuis.org The "no key" is bogus and should be "unsupported key". Regards, -Phil
--- Begin Message ---wibble
--- End Message ---
signature.asc
Description: Digital signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/