• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

SMTP Auth on port 587 broken after each microupdate since 11.5

radykal

New Pleskian
Hello,

since I upgraded to Plesk 11.5 each time the panel updates with microupdates i noticed that smtp auth on port 587 does not work, on email client it keeps prompting for password and in maillog file it only appears as AUTH FAILED. The smtp auth on port 25 works as expected but some of our customers have the port 25 blocked by their ISP to prevent SPAM abuse and need to use 587. At this point the only way I have to make it work again is reconfigure mail settings with mchk like said in http://kb.parallels.com/en/944 (I run /usr/local/psa/admin/sbin/mchk --with-spam ) and just after it completes the customers can send again on port 587.
 
We are experiencing the same problem except we can't even fix it by using the command line tool to reconfigure. We are using Postfix as our MTA.


Hello,

since I upgraded to Plesk 11.5 each time the panel updates with microupdates i noticed that smtp auth on port 587 does not work, on email client it keeps prompting for password and in maillog file it only appears as AUTH FAILED. The smtp auth on port 25 works as expected but some of our customers have the port 25 blocked by their ISP to prevent SPAM abuse and need to use 587. At this point the only way I have to make it work again is reconfigure mail settings with mchk like said in http://kb.parallels.com/en/944 (I run /usr/local/psa/admin/sbin/mchk --with-spam ) and just after it completes the customers can send again on port 587.
 
Same here: I fixed the problem with "/usr/local/psa/admin/sbin/mchk --with-spam". Would be nice if Plesk could fix this problem... :)
 
Hi!

Same Problem here.
Today with the "new" MU (microupdate) smtp has failure. Our customer run OpenSuSE 12.3, Plesk 11.5.30 Update #12. He has the unlimited version. After each MU smtp crashes. When will Parallels fix this f****** Problem? It is very annoying, to fix it manually every time.

Could some Parallels staff please this Thread?

Thnx!
 
Hello!
I can not reproduce this problem on suse 12.3 i686 -- it's hard to guess what actually happened.
Could you provide any relevant records from /usr/local/psa/var/log/maillog , /tmp/autoinstaller3*.log or /var/log/messages?
Any other additional info would be nice too.
Thanks.
 
Poppsworld's solution "/usr/local/psa/admin/sbin/mchk --with-spam" - did work. Hopefully Parallels will get this permanently resolved so we don't have to do this after each update
 
Parallels Plesk Panel 11.5.30 MU #10 CentOS 6.4

Same problem here with same workaround (seen on 10+ servers).
Automatic updates are now disabled on our servers to prevent having any SMTP Auth problem during night.

From file "/usr/local/psa/var/log/maillog" when problem occurred (after MU automatic update), we can see the following info every time some user tried to submit their messages to the Qmail server:

Code:
Jul 30 14:28:45 server smtp_auth: SMTP connect from server.ext [a.b.c.d]
Jul 30 14:28:45 server smtp_auth: FAILED: [email][email protected][/email] - password incorrect from server.ext [a.b.c.d]
=> Until we apply the "mchk" workaround, the authentication were refused from valid users on several domains (not on all domains ...).

From file "/tmp/autoinstaller3.log", we can't see any error on the last automatic update performed on "Tue Jul 30 03:17:03 2013".

Code:
Installing patches...
FileFetcher: get file (~empty)/PSA_11.5.30/microupdates/MU8/rpm-CentOS-6-x86_64/_usr_local_psa_admin_sbin_deployer
File downloading PSA_11.5.30/microupdates/MU8/rpm-CentOS-6-x86_64/_usr_local_psa_admin_sbin_deployer: 10%..20%..30%..40%..50%..60%..70%..80%..90%..100% was finished.
FileFetcher: get file (~empty)/PSA_11.5.30/microupdates/MU8/rpm-CentOS-6-x86_64/_usr_local_psa_admin_sbin_pmm-ras
File downloading PSA_11.5.30/microupdates/MU8/rpm-CentOS-6-x86_64/_usr_local_psa_admin_sbin_pmm-ras: 10%..20%..30%..40%..50%..60%..70%..80%..90%..100% was finished.
FileFetcher: get file (~empty)/PSA_11.5.30/microupdates/MU8/common/_usr_local_psa_PMM_agents_PleskX_Packer.pm
File downloading PSA_11.5.30/microupdates/MU8/common/_usr_local_psa_PMM_agents_PleskX_Packer.pm: 10%..20%..30%..40%..50%..60%..70%..80%..90%..100% was finished.
FileFetcher: get file (~empty)/PSA_11.5.30/microupdates/MU8/common/_usr_local_psa_PMM_agents_PleskX_SpecificConfig.pm
File downloading PSA_11.5.30/microupdates/MU8/common/_usr_local_psa_PMM_agents_PleskX_SpecificConfig.pm: 14%..34%..53%..72%..92%..100% was finished.
FileFetcher: get file (~empty)/PSA_11.5.30/microupdates/MU8/common/_usr_local_psa_PMM_pmm-common.xsd
File downloading PSA_11.5.30/microupdates/MU8/common/_usr_local_psa_PMM_pmm-common.xsd: 10%..20%..30%..40%..50%..60%..70%..80%..90%..100% was finished.
Patching file /usr/local/psa/admin/sbin/deployer
Patching file /usr/local/psa/admin/sbin/pmm-ras
Patching file /usr/local/psa/PMM/agents/PleskX/Packer.pm
Patching file /usr/local/psa/PMM/agents/PleskX/SpecificConfig.pm
Patching file /usr/local/psa/PMM/pmm-common.xsd
Restoring SELinux security context for patched files
Patch plesk-11.5.30~patch8 installation summary: 5 items applied, 0 items skipped, 0 items failed.
Patches were installed successfully.
From file "/var/log/messages", we just see info on the update performed:

Code:
Jul 30 03:17:40 server yum[19680]: Updated: pp11.5.30-bootstrapper-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:10 server yum[20998]: Updated: psa-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:13 server yum[20998]: Updated: plesk-skins-11.5.30-578.13072512.noarch
Jul 30 03:18:14 server yum[20998]: Updated: psa-locale-base-en-US-11.5.30-cos6.build115130722.19.noarch
Jul 30 03:18:14 server yum[20998]: Updated: libaps-1.0.6-798670.13071616.x86_64
Jul 30 03:18:16 server yum[20998]: Updated: sw-engine-2.9.7-201307161840.centos6.x86_64
Jul 30 03:18:17 server yum[20998]: Updated: plesk-base-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:17 server yum[20998]: Updated: psa-pylibplesk-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:19 server yum[20998]: Updated: plesk-service-node-utilities-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:20 server yum[20998]: Updated: psa-libpam-plesk-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:28 server yum[20998]: Updated: plesk-core-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:29 server yum[20998]: Updated: psa-migration-manager-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:32 server yum[20998]: Updated: 2:psa-qmail-1.03-cos6.build115130724.19.x86_64
Jul 30 03:18:34 server yum[20998]: Updated: psa-courier-authlib-0.65.0-cos6.build115130724.19.x86_64
mail.none			-/var/log/messages
Jul 30 03:18:35 server kernel: Kernel logging (proc) stopped.
Jul 30 03:18:35 server rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="20285" x-info="http://www.rsyslog.com"] exiting on signal 15.
Jul 30 03:18:36 server kernel: imklog 5.8.10, log source = /proc/kmsg started.
Jul 30 03:18:36 server rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="22052" x-info="http://www.rsyslog.com"] start
Jul 30 03:18:36 server yum[20998]: Updated: psa-mail-driver-common-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:38 server yum[20998]: Updated: plesk-mail-qc-driver-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:39 server yum[20998]: Updated: psa-migration-agents-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:39 server yum[20998]: Updated: plesk-management-node-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:41 server yum[20998]: Updated: psa-watchdog-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:47 server yum[20998]: Updated: plesk-l10n-11.5.30-cos6.build115130722.19.noarch
Jul 30 03:18:49 server yum[20998]: Updated: psa-firewall-11.5.30-cos6.build115130724.19.x86_64
Jul 30 03:18:51 server yum[20998]: Updated: plesk-completion-11.5.30-cos6.build115130724.19.noarch
Jul 30 03:18:52 server yum[20998]: Updated: plesk-web-hosting-11.5.30-cos6.build115130724.19.x86_64
We are waiting for a correction from Parallels on this issue and available for any test/log.
Thanks!
 
Okey.
At least I've reproduced the issue which is very similar to the described problem.
So we have possibility to investigate and fix this :)
 
Thanks for this great news!
We are waiting for info on the release of the correction in order to re-apply automatic updates.
 
Well, I've found what is wrong and have made a fix.
The fix will be released in microupdate #13 so you can turn autoupdates on :)
 
Back
Top