• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

[PPP-14342, PPP-14359] Postfix wants to run on port 587 even though this is turned OFF

Frater

Regular Pleskian
Each migration in the last years I'm running into this bug that Postfix wants to run on port 587 even though this is turned OFF in the Plesk Panel.
Sometimes it does this after some update.
Because another process is running on port 587 this means that postfix does not start and I have some downtime until I "repair" this.

"Repairing" means going into Plesk panel and turning ON SMTP-Auth.... Wait a moment for it to apply and then turning it OFF again....

This unwanted behaviour can be easily reproduced by having this option turned off in the Plesk panel and then running /usr/local/psa/admin/sbin/mchk --without-spam

This will end up in a non-running postfix if another process is already running on port 587.

This shouldn't be happening.
Especially because I reported this behaviour years ago
 
Because another process is running on port 587 this means that postfix does not start
Please clarify what sort of "another process" do you mean?
 
Please clarify what sort of "another process" do you mean?
It's ASSP (an anti-spam reverse proxy).
But does it really matter?
I "told" Plesk I don't want to make use of port 587, so it shouldn't configure postfix to do so.

On Plesk's panel it is still turned off.

BTW... The Dutch translation for this item is getting non-descriptive. It doesn't mention port 587 anymore nor does it mention SMTP-AUTH. It merely says it's for using it to send mail.
You can still send mail using port 25 and port 465 so it's ambiguous to say the least.
I have no modern English versions, so I don't know what it says there.
It used to mention SMTP-AUTH (didn't it?)


It can run for years and then all of a sudden out of the blue some update triggers it and I have a non-working postfix. I'm glad I have this all monitored and I can immediately see "it did it again" on my Zabbix dashboard.
I now did a migration from Plesk 11 to Plesk 12, but this time I found something to reproduce this bug. That's the reason I'm posting it again.

Plesk should always follow the rules that are given on its panel.

I probably should have written:
This will end up in a postfix using port 587.
instead of
This will end up in a non-running postfix if another process is already running on port 587.
 
Last edited:
Thanks a lot for your attention!

I now did a migration from Plesk 11 to Plesk 12, but this time I found something to reproduce this bug.
You were talking about “each migration” and “after some update”... We tried to reproduce the situation with migrations from Plesk 11 to Plesk 12, but nothing happened while we just transferred data between the servers.

However, we reproduced the problem using the way you described. We found the bug, but for now we think that this bug arises after manually started mchk running only. Maybe there is one more bug somewhere with migrations, the one you were talking about which one we have not yet found. So that would be very useful to understand — what exactly did you do? I would be grateful if you will describe it a little bit more detailed.

BTW... The Dutch translation for this item is getting non-descriptive. It doesn't mention port 587 anymore nor does it mention SMTP-AUTH. It merely says it's for using it to send mail.
You can still send mail using port 25 and port 465 so it's ambiguous to say the least.
I have no modern English versions, so I don't know what it says there.
It used to mention SMTP-AUTH (didn't it?)
For now in current English versions (12.0.x) the item has not very descriptive text of its caption too (“Enable message submission”), and the item has no other description unlike other items on the same form.
The translations of the text are also non-descriptive as the original text, besides, some translations (including the Dutch one) are made not even close to original text by the meaning.
We decided that all this is a serious bug, especially for our localizations.

Thank you for reporting and cooperation!
 
Last edited:
Hi Evgeny,

As a matter of fact I was prepared for this anomaly and it didn't occur this time. It did several months ago when I updated 2 other servers to Plesk 12.
After the migration I had some trouble with Nginx not starting, because it couldn't read the SSL-key.
On the Plesk forum I found a way to solve it.

I now can't remember why I ran that mchk routine, but I think I needed to do that to solve the problem with Nginx.
As I remember it I then had a working Nginx, but then my Postfix stopped working....
That problem was easily solved because I had to do that many times before.
Being annoyed I started this thread.
Could it be that "mchck" was part of the migration process before?
Or maybe that bug was already squashed?
So we agree it didn't do it this migration (it did on the 2 other plesk 12 migrations and the migrations before that.)

I'm looking forward for this better description of what that checkbox is actually doing.
Each time I'm in quite a hurry to fix it and every time it takes more time to find it because of its non-technical description.
Being non-technical isn't always better.
But I believe we agree on this.
 
Could it be that "mchck" was part of the migration process before?
Or maybe that bug was already squashed?
Yes, it could be in the past, and the bug could be already squashed. It's hard to say, if we can't reproduce it now.
However, we confirm the bug with “mchck” (for the reference: PPP-14342).

I'm looking forward for this better description of what that checkbox is actually doing.
Each time I'm in quite a hurry to fix it and every time it takes more time to find it because of its non-technical description.
Being non-technical isn't always better.
But I believe we agree on this.
I totally agree.
I have filed the issue to our development team, its ID is PPP-14359 for your reference.
Thank you once again!
 
Back
Top