DKIM signing fails when the system itself sends emails.
Failure refers to the fact that the email is first processed with my domain key and then with a fixed key and a completely custom signing template.
This also changes the header, and nothing matches my key anymore.
The following is added: X-Keep-CipherMail-DKIM-Signature: a=rsa-sha256; b=[manually removed] c=relaxed/relaxed; s=selector; d=CipherMail; v=1; bh=FNFzXw6nBYmrYyoERf1j4O62pd4OwZvtVKnotoFkRB0=; h=From:X-Keep-CipherMail-Auto-Submitted;
How can I prevent the final, pointless DKIM signing from being performed with some random key? (Emails that are not sent by the system itself but only “pass through” Ciphermail are correctly signed.)
X-Keep-CipherMail-DKIM-Signature is not a DKIM header but a custom CipherMail header and therefore should not result in DKIM failure unless you have a very broken DKIM verifier.
X-Keep-CipherMail-DKIM-Signature is used to prevent mailloops when email is being forwarded again through the gateway (which in typical setups never happens).
The most likely reason for the DKIM failure is that you generate a DKIM signature before the gateway handles the message.
It only affects the email sent when I have enabled “pdf Portal auto signup” in the general settings.
In the logs, I see that the same email is DKIM signed twice.
No DKIM signing is performed anywhere else in my server setup.
My key is only stored in Ciphermail.
And this signing works perfectly for normal emails. These emails also lack the “X-Keep…” from Ciphermail itself, and the log shows only one(!) entry for a DKIM signing.
But none of this is the case when the system itself sends the email.
If it claims that this email passes through the gateway twice: Is this auto-generated email injected on port 10025? Then I wouldn’t be surprised, since your Postfix template specifies reinjection on port 10026.
Locally generated notifications may fail DKIM verification if the message is
sent without a Date header. In this case, Postfix automatically inserts a Date
header (because local_header_rewrite_clients matches), which changes the headers
after the message was signed. Since the Date header is included in the DKIM
signature, this modification invalidates the signature. To prevent this, I
updated the code that sends locally generated email notifications to always add
a Date header.
Two different keys are being used. One is the one I generated, and another (X-KEEP…) is hard-coded somewhere.
I don’t understand the purpose of DKIM signing to prevent a loop. For this, you can set additional headers like “Ciphermail-processed: True,” but you don’t use internal DKIM signing, which in turn invalidates a necessary external “real” DKIM signing… This contradicts the purpose of DKIM. (d=Ciphermail alone is an invalid domain…)
I think the timing of DKIM signing, which, for example, was set in the “Domain Menu” in my case, is incorrect. I suspect that with Ciphermail’s backend, the DKIM signing stored in the domain is performed first and then passed on to the process that inserts the internal, hard-coded signing with the “X-Keep-” header.
Regarding your question about the DKIM signature header: This is inserted by CipherMail. There is no other entity that performs DKIM.
Of course, I have to adapt the template for my domain and my requirements.
Try it yourself. Use a valid email server with a public domain and create a DKIM, enter all the required information in the DNS, and then send an email via the gateway. The email containing the encrypted PDF is signed correctly. The second one with the subject “Signup for the CipherMail Secure Email Portal” is DKIM-invalid.
You changed the DKIM template for a user or domain. Is that on purpose? Normally you change this for the global settings because it’s now unclear which template is used because it depends on the sender
I did that, and unfortunately, there was no improvement.
Perhaps the logs will be more helpful – they are signed twice, which isn’t the case if the DKIM remains valid. Then the entry “was DKIM signed” appears only once (!) in the logs.
I understand why you think DKIM failure is related to the additional “DKIM” signature (note the quotes to indicate that this is not a DKIM signature) but the DKIM failure is not related to the custom DKIm signature.
May I ask how you configured DKIM? A assume with the CLI?
We released an update (6.2.2) which should fix the issue. We also included documentation for configuring DKIM. We made the system DKIM key hidden (i.e., no longer shown from the UI) because it was confusing.
I didn’t change anything with the key, though. I simply installed the .deb packages and tried it out.
Thanks for the update. And also for the very quick response.
I’d be interested to know what the cause of the problem was? But only if there’s time to explain it
