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.pennock@??? designates 94.142.241.89 as permitted sender) smtp.mailfrom=prvs=064468e5c1=phil.pennock@???;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=spodhuis.org
The "no key" is bogus and should be "unsupported key".
Regards,
-Phil
wibble
