Question Some server domain email accounts accept encrypted passwords, others do not - why? Appears to be some obscure setting in a service plan?

[MHC_1]

Server operating system version

AlmaLinux 9

Plesk version and microupdate number

Plesk Obsidian 18.0.73 Update #4

We have server version:

Plesk Obsidian 18.0.73 Update #4​

Web Host Edition​

​

​

Last updated on Nov 19, 2025 03:50 AM

Which means things like https://support.plesk.com/hc/en-us/...n-type-after-update-to-Plesk-Obsidian-18-0-73 doesn't apply. However, we have two domain accounts which are both on the same server and both successfully connect to emails -- but one connects with encrypted password (CRAM-MD5) and the other connects via PLAINTEXT , but we can't see how to make the Plaintext connection work using Encrpyted password.

We have found these two accounts "encrpyted_domain" and "plaintext_domain" are on different subscriptions with different Service Plans and I assume something in these settings enable/disable email password encrpytion, but digging into the subscription and/or service plan options, we can't see what to tweak so that both subscriptions/service plans enable email password encryption.

All connections are via SSL/TLS

 

[Sebahat.hadzhi]

@MHC_1 , please execute the repair utility for the domain names related to the issue and let us know if it returns any errors:

plesk repair mail -v example.com -y

 

[MHC_1]

@MHC_1 , please execute the repair utility for the domain names related to the issue and let us know if it returns any errors:

plesk repair mail -v example.com -y

Hello!
Thanks, this returns:

Error messages: 0; Warnings: 0; Errors resolved: 0

 

[MHC_1]

@Sebahat.hadzhi further, it appears as far as we can tell to be an issue for emails imported via the Plesk Migrator. Email accounts created natively on the server seem to be ok. I have set both emails to the same subscriber (Administrator) and the issue remains (although didn't restart server or any services).

 

[Sebahat.hadzhi]

Thanks for the confirmation. I think that might be related to the issue reported in your other thread. If it still persists after changing the email account passwords, could you please also check what's being logged at /var/log/maillog at the time of the failure?

 

[MHC_1]

Thanks for the confirmation. I think that might be related to the issue reported in your other thread. If it still persists after changing the email account passwords, could you please also check what's being logged at /var/log/maillog at the time of the failure?

Hello
Thank you, yes re-entering the password for an account permits the end client to connect to the mailbox with encrypted rather than plaintext authentication.