Facebook
Twitter
-
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
GravuTrad
Regular Pleskian
No solutions?
GravuTrad
Regular Pleskian
M
MeikR
Guest
Seems to work for now
@IgorG:
I follow the instructions from the developer (above) to change the port only in this line:
to port 10026 like this :
smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10026
Your are asked twice, if we only have to change this line, or if we have to change lines smtps and submission, too?
Do we have to?
Since I changed this and made a smtp restart in plesk backend, there are no more queue entries in the mail.warn for now:
The last questions for now:
Do we disable the queue, or just switch it on a different port? So do we not get following errors by not changing all ports 10025 to 10026 for the smtp entrys?
If we just disable the queue, do we prevent just the error messages, or are the mails correctly delivered? Do we have another indicator for mail failed messages?
Thanks for ansering.
@IgorG:
I follow the instructions from the developer (above) to change the port only in this line:
to port 10026 like this :
smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10026
Your are asked twice, if we only have to change this line, or if we have to change lines smtps and submission, too?
Do we have to?
Since I changed this and made a smtp restart in plesk backend, there are no more queue entries in the mail.warn for now:
The last questions for now:
Do we disable the queue, or just switch it on a different port? So do we not get following errors by not changing all ports 10025 to 10026 for the smtp entrys?
If we just disable the queue, do we prevent just the error messages, or are the mails correctly delivered? Do we have another indicator for mail failed messages?
Thanks for ansering.
1. > Your are asked twice, if we only have to change this line, or if we have to change lines smtps and submission, too?
Change smtp string only. Because before-queue does not installed on submission/smtps ports.
2. > Do we disable the queue, or just switch it on a different port? So do we not get following errors by not changing all ports 10025 to 10026 for the smtp entrys?
Switching on the another port is equivalent disabling of postfix-queue from MTA. It means what all before-queue handlers(drweb, kav, spf, GL) will be switched off. In this case doesn't destroy delivering a mails. The point such action - to monitor errors if postfix-queue disabled.
3. tail -n 1000 /var/log/mail.warn | grep before-queue | more
This is not correct test. You should check warnings from native postfix smtp daemon. For example:
tail -n 1000 /var/log/mail.warn | grep -C 3 smtp | more
Change smtp string only. Because before-queue does not installed on submission/smtps ports.
2. > Do we disable the queue, or just switch it on a different port? So do we not get following errors by not changing all ports 10025 to 10026 for the smtp entrys?
Switching on the another port is equivalent disabling of postfix-queue from MTA. It means what all before-queue handlers(drweb, kav, spf, GL) will be switched off. In this case doesn't destroy delivering a mails. The point such action - to monitor errors if postfix-queue disabled.
3. tail -n 1000 /var/log/mail.warn | grep before-queue | more
This is not correct test. You should check warnings from native postfix smtp daemon. For example:
tail -n 1000 /var/log/mail.warn | grep -C 3 smtp | more
M
MeikR
Guest
Thank you for the answers, IgorG.
Here is a slice of the output from the command:
So there are hundrets of those entrys:
1. dirty spam IPs (I think) Name ore service not known
2. the message of the dk_check
3. one regurlar entry for every LOGOUT of a popconnector from our clients
But my customers get very angry by getting a lot of spam now, because this workaround disables the Greylisting.
This is no solution for us.
Your fix
IgorG, is there way to fix this problem for now? Plz force your developers to deliver a working mail queue like the versions before PLESK 9.3.
regards
Here is a slice of the output from the command:
So there are hundrets of those entrys:
1. dirty spam IPs (I think) Name ore service not known
2. the message of the dk_check
3. one regurlar entry for every LOGOUT of a popconnector from our clients
But my customers get very angry by getting a lot of spam now, because this workaround disables the Greylisting.
This is no solution for us.
Your fix
does not work correctly, so why is it still online? This fix makes it worse by enabling greylisting for the sending procedures of all customers.
IgorG, is there way to fix this problem for now? Plz force your developers to deliver a working mail queue like the versions before PLESK 9.3.
regards
M
MeikR
Guest
Yes, this article solves the queue file write problem, but it also enables the internal greylisting block handle for regular customers. You remember thread http://forum.parallels.com/showthread.php?t=101162 ?
This is still open and not solved. So both solultions, turning off the queue which disables the GL or patch the queue like in the KB article which forces the admin to manually disable the GL, are not very lucky. For me this is not a 100% correct patch.
Please correct me, if I am wrong.
I will if you provide free support for this update error. I found only a way to contact support for 150$/hour. But this error is forced by parallels update (and not only at our servers
, so I hope to find free answers by asking you and this forum. Is there a way to get free support for this?regards
C
ChristopheP
Guest
Hi,
I upgraded to 9.5.2 today and noticed you put this at the bottom of main.cf now:
smtpd_timeout = 3600s
smtpd_proxy_timeout = 3600s
That's seriously the most dumb thing you could have done to fix the problem : I have 1200 postfix-queue process idling on my box. Again re-read all my messages and show us your skills by trying to understand what I say and fix the problem for good.
When will the final patch (included in stock rpms) be avaible from the official repos ?
Today I received 7000+ errors emails from over 24 servers. Like I said 2 months ago, I started to move from Plesk to Cpanel and the move is not going to stop if you don't give this problem a serious look at.
I upgraded to 9.5.2 today and noticed you put this at the bottom of main.cf now:
smtpd_timeout = 3600s
smtpd_proxy_timeout = 3600s
That's seriously the most dumb thing you could have done to fix the problem : I have 1200 postfix-queue process idling on my box. Again re-read all my messages and show us your skills by trying to understand what I say and fix the problem for good.
When will the final patch (included in stock rpms) be avaible from the official repos ?
Today I received 7000+ errors emails from over 24 servers. Like I said 2 months ago, I started to move from Plesk to Cpanel and the move is not going to stop if you don't give this problem a serious look at.
C
ChristopheP
Guest
I managed to reinstall all rpms on a production server : upgrade from web interface was skipping some of the updated packages. I will see if 9.5.2 is fixing it.
C
ChristopheP
Guest
After a few days here are the results:
- I got no more emails about queue file write error and postfix-queue
- My customers are still complaining about unreceived emails
- maillog is still full of postfix/spawn[27124]: warning: command /usr/lib64/plesk-9.0/postfix-queue exit status 255
My question is : did you disable email alerts to make us think you fixed the problem while it's not the case ?
- I got no more emails about queue file write error and postfix-queue
- My customers are still complaining about unreceived emails
- maillog is still full of postfix/spawn[27124]: warning: command /usr/lib64/plesk-9.0/postfix-queue exit status 255
My question is : did you disable email alerts to make us think you fixed the problem while it's not the case ?
ChristopheP, problem is not trivial and can be caused by a lot of reasons. Developers can't reproduce all these reasons on our test environments. They can try to investigate it directly on your server if it is possible. I can offer following way for you - you can submit ticket to support team with link to this thread, number of our internal developers request #41286 and request to pass your ticket directly to Second Line Support team. After that experienced supporter with developers will check this problem directly on your server. Also you can provide me ticket ID and I can escalate it just in case.
