Forwarded to devs faulty DKIM record created after customer migration

[TomBoB]

Username:

TITLE

faulty DKIM record created after customer migration

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk 18.0.42 #1, AlmaLinux 8.5

PROBLEM DESCRIPTION

We migrated customers from one server (to be retired) to another server (new). Old server runs CentOS 7, latest. New server runs Almalinux latest. Both run latest Plesk.
Customers were migrated sometimes alone. Other nights 3 or 4 at a time.

On the receiving server, the DKIM record is created in this format [ tested and tried with : DKIM Record Lookup Tool - Free DKIM Check | dmarcian ]

v=DKIM1; p=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

It should be of the format

v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

Had clients contact me as their emails bounce back.

STEPS TO REPRODUCE

migrate a customer from one server to another - possibly with above mentioned specifics - and check the DKIM record that's created for the domains of those customers on the receiving server.

ACTUAL RESULT

faulty DKIM record

EXPECTED RESULT

correct DKIM record

ANY ADDITIONAL INFORMATION

disabling DKIM for the domain on the receiving server, then re-enabling it, creates a proper record. Am using that as a workaround to correct all the faulty records.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Maarten]

Issue - Some (recent?) upgrade broke the DKIM TXT records

Hi, Found an issue today. Some (probably recent) upgrade broke the DKIM TXT records for domains. I have a domain that I switched to CloudFlare some months ago and at that time I copied the DKIM TXT record that is: "v=DKIM1...

talk.plesk.com

 

[TomBoB]

Wow, that's going back to Jan 2021, 1.5 years, and not solved yet ?!?!?

Searched for DKIM in this thread, couldn't find anything. That's why I reported it. -- Will look VERY carefully at any client and their domains that we migrated over that period.

Look here Forwarded to devs - Plesk migrator breaks DKIM records that's June 2017 !!! I'm not going back checking 5 years of customer migrations... I've just sorted it for one server we migrated recently, I'll check on 2 more from shortly before that.
Ridiculous that that isn't resolved yet...

 

[Maarten]

I use this to list the DKIM status of the domains:

# DNSLIST='alldnstxtzones.csv'; plesk bin domain --list | while read i; do plesk bin dns --info $i | grep default | grep TXT >> $DNSLIST; done
# cat alldnstxtzones.csv | grep "p=DKIM1"

 

[TomBoB]

To be honest, i couldn't even be bothered to dig much deeper... Over time we migrated customers all over the place and many different servers. Just ran a

for domain in $(plesk db -Ne 'SELECT name FROM domains WHERE parentDomainId=0;'); do plesk bin domain_pref --update $domain -sign_outgoing_mail false; done

followed by a

for domain in $(plesk db -Ne 'SELECT name FROM domains WHERE parentDomainId=0;'); do plesk bin domain_pref --update $domain -sign_outgoing_mail true; done

on all servers to get things in order again. Don't want to think about the impact of this on the clients emails in the past though...

The notice that you can see hints of the bug in the debug.log isn't any help in real live. I'd expect a notice in the info.log for it to catch any attention. The debug.log is only good when you are debugging; IE know there is a problem. Which with this bug, one doesn't.

 

[Maarten]

I didn't go that far as that would generate a new public key for already signed emails that left the servers. Recipient servers use the public key published to the DKIM's domain to verify the source of the message, and that the parts of the message included in the DKIM signature haven't been changed since the message was signed.

 

[IgorG]

Thank you.
Bug confirmed, issue filed: PPPM-13549

 

[Maarten]

Thank you.
Bug confirmed, issue filed: PPPM-13549

This bug was also known as PMT-4640. What's the difference?

 

[IgorG]

This bug was also known as PMT-4640. What's the difference?

There is no difference. Just internal cross-communication.

 

[Maarten]

I noticed that the last few migrations went correctly. No more messed up DKIM records when you migrate a subscription to another Plesk server.

Has this issue finally been fixed in Plesk Obsidian 18.0.50 Update #2? I didn't see anything mentioned in the logs on this issue.

 

[Peter Debik]

@maartenv No, it has not been fixed yet.

 

[TomBoB]

we're about to migrate a major domain over to a new server. Will also keep a close eye on it. Thanks for the reminder !!

 

[TomBoB]

nope, Peter is correct. still happening.

 

[Maarten]

I did another migration, which ended up with the correct DKIM record.

@TomBoB Which Plesk and migrator version did you use?

I'm using this:
Plesk Migrator v2.24.0-1083
Plesk Obsidian 18.0.50 Update #2

 

[TomBoB]

We migrated to Almalinux 8, very latest updates, Plesk Obsidian 18.0.50 Update #2, using Migrator 2.24.0-1083. Domain was prior on another Plesk server with virtually same setup as the new server.

 

[Michael K]

This issue is still active one year after the start of this discussion.

I fixed this by switching DKIM off and on for each domain:

plesk db -Ne 'SELECT name FROM domains WHERE parentDomainId=0;' > domains.txt
for domain in $(cat domains.txt); do
   plesk bin domain_pref --update $domain -sign_outgoing_mail false;
done
for domain in $(cat domains.txt); do
   plesk bin domain_pref --update $domain -sign_outgoing_mail true;
done

 

[H.W.B]

Hello,
Problem still remains.
Had to manually edit all domains i migrated.
Henk

 

[frg62]

Hello,
Last day of January 2024, and the bug is still there...

 

[Peter Debik]

Why is the mass-update solution of #post-925347 above not suitable for you?

 

[frg62]

Because I host several domains for which the mail system is not hosted on my servers.
Acting globally would create incorrect DKIM records for these domains.