DKIM Keys Corrupted in Build 8125
Problem reported by Scarab - 6/30/2022 at 2:34 PM
Just now discovered 48 domains out of 260 that had their DKIM keys corrupted during our April Monthly Maintenance window when we upgraded to Build 8125 (from Build 8097). The keys were truncated after the the mechanisms "v=DKIM1; k=rsa; h=sha256;". It seems to have occurred when the "h=sha256" mechanism was added to the DKIM key in SmarterMail.

After fixing all the affected domains by deleting the DKIM key and having SmarterMail generate a new key to be updated in DNS I discovered the commonality. Those domains affected had their DKIM keys generated in SmarterMail long ago prior to the addition of the "v=DKIM1;" mechanism (they all started with the mechanism "k=rsa;"...would that be the pre-v14 days?). Apparently the upgrade script to insert the new "h=sha256;" mechanism would silently fail on a domain if the string began with anything other than what the upgrade script expected. It seems to have taken the first 15 characters of the string (str.Substring(0,15);), appended a space+h=sha256;+space regardless of what the string actually started with, resulting in the p= string being truncated because there was previously no v=DKIM1; to pad the first 15 characters of the string.

For example, the old key prior to upgrading began as follows:
k=rsa; p=MIIBIjANBgk...

The key would be upgraded to:
v=DKIM1; k=rsa; h=sha256; ANBgk...
(notice the p=MIIBIj is missing)

Upon validation the key would be truncated as follows:
v=DKIM1; k=rsa; h=sha256;

2 Replies

Reply to Thread
Zach Sylvester Replied
Employee Post
Hello Scarab, 

Thank you for reaching out to the community. That is actually really interesting. Maybe I can replicate this bug now. 
I will let you know when we get back into the office on Tuesday. 

Kind Regards, 
Zach Sylvester
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
Chris Daley Replied
I doubt the developers would use substring or append on this. As a DKIM record has a clearly defined structure (key-tag) you would just parse this into a class then have a simple ToString() override that outputs in the desired format. This would make altering an individual element far easier.

We are still running 8055 as its more stable for our workload

Reply to Thread