Only create DKIM RSA key(s) by default for new domains, not both RSA and ed25519 #299
Comments
|
Hi @mjl-, first of all thank you so much for Mox. I just started using Mox and it is amazing. I configured both DKIM RSA and ed25519 following Mox Quickstart. Checking the raw sources of the emails sent to Gmail accounts, I noticed that Google returns After reading your note, I kept only the DKIM RSA keys. So far sending emails to Gmail and Outlook is working well. Unfortunately I have some issues with iCloud, but I need to make some more tests. |
We'll need RSA DKIM keys for a long time to come because many systems don't support ed25519 DKIM signatures. We've been adding both types of keys when adding a new domain, and adding both two DKIM signatures to outgoing messages. This works fine in practice, other mail servers are correctly ignoring the ed25519 signature if they don't understand it. Unfortunately, it causess noise in DMARC reports: Systems will warn that a DKIM check failed. Sometimes with a vague message about a missing key, or a 0-bit key. Sometimes they leave the selector out of the report, making it hard to understand what's going on. This causes postmasters to investigate because they think something is wrong, only to eventually find out it's all fine. So we're causing needless chores for postmasters. By having only an RSA DKIM signature, we skip that noise. This also reduces the number of DNS records postmasters have to add for a domain. The small ed25519 DKIM DNS TXT records would make them preferrable over the long multi-string RSA DKIM DNS TXT records (which are often hard to add correctly through DNS operator web interfaces), but as mentioned, we'll have to add the RSA DKIM keys anyway. Another reason why RSA keys _may_ be preferrable over ed25519 keys is that with RSA, signing is more computationally expensive than verifying, while it's the other way around for ed25519 keys. Admins can always add an ed25519 DKIM key to their domain. And we can always switch back to adding them to new domains by default in the future. For issue #299.
|
Great to hear! With the commit above, we'll no longer create ed25519 dkim keys by default. Which errors are you seeing from icloud? I've gotten rejects with the following message: |
|
Hi @mjl- , with iCloud it is rejected exactly with the same message. I tried also sending from my iCloud email and reply, but it is rejected with the same reason. By the way at the second attempt the sender email is temporarily blocked: |
|
Anyway its is not a Mox specific issue. I just reverted back for testing to Postfix/Dovecot and failed to deliver to iCloud as well. 2025-03-08 17:33:54 eygem postfix/bounce[765117]: 9289536010C: sender non-delivery notification: EA53A360111Some years ago it was working, it may be possible iCloud has become more selective to filter incoming email. Since a couple of months I noticed spam drastically decreased in my iCloud mail. |
|
Hi @mjl- , just to share that now I can send also to iCloud. On Sunday I sent an email to Apple iCloud ([email protected]) explaining that the messages sent from my self-hosted email server to my private iCloud email were bounced. I explained that the same emails are delivered to Gmail and Outlook accounts (I annexed the raw sources of two messages). After 2 hours they replied asking my host provider to reach them. I opened a ticket with my host provider (Contabo in my case) and they contacted Apple. Few hours later the iCloud Team informed they made some changes and asked me to try resending. In 36 hours the issue was resolved. I hope these information can be helpful for others facing the same issue. |
All DKIM-verifying software support DKIM RSA keys. Only some (not that many)
support ed25519 keys. We currently create both keys for new domains, and sign
outgoing messages for that domain with both keys.
If a remote server does not support an algorithm, it has to (and does in
practice) ignore that signature, and uses other signatures with algorithms
that it does support. However, some of those servers then send DMARC reports
that mention a failing DKIM verification. And unfortunately, often with bad
diagnostics and/or few details. E.g. missing selector. The same applies to
the Authentication-Results headers that they create, which sometimes mention
"0-bit" keys. This confuses postmasters, causing them to investigate. It
takes time and is a chore. We can probably prevent this by only using RSA
keys.
I originally added both on the assumption that there would/should be a
move from RSA keys to ed25519 keys for DKIM. But that is probably not
happening:
need RSA for a long time to come. RSA isn't broken, it works just fine
(well, except that the long public keys are annoying, they result in long
DNS TXT records, with multiple 255-byte strings, that some DNS provider
interfaces botch; but at least we check for in the self-check; ed25519 DKIM
DNS TXT records don't have this problem).
it's the other way around for ed25519. The RSA-case seems more attractive
for postmasters. Not sure if this makes an actual difference.
setting up a domain.
The text was updated successfully, but these errors were encountered: