451 Error: queue file write error (only when using postfix)

[PSi_101]

Alas, i've managed to work around the problem by disabling ALL postfix plugins. Dr Web, Kaspersky, SPF, Domainkeys, and DNS blacklists.
Not an ideal solution though.

 

[PSi_101]

Alas, i've managed to work around the problem by disabling ALL postfix plugins. Dr Web, Kaspersky, SPF, Domainkeys, and DNS blacklists.
Not an ideal solution though.

Correction. It worked around the problem mostly. Instead of dozens of queue file write error messages a day, this has been reduced to 1 or 2.
It certainly helps.

 

[galaxy]

I've solved it for myself, but it may not help others...

Essentially the problem is with the program at: /usr/lib/plesk-9.0/postfix-queue

This is the "hotfix" they keep replacing. Also the way that plesk is managing postfix mail processing is very inefficient. They fork/exec the postfix-queue program twice, and postfix-local once. The message passes through 4 or 5 processes before it gets delivered.

Since I don't use any of the spam, virus, or any of the extras plesk provides, I've totally eliminated them. I'm still in the process of testing though.

I've updated my /etc/postfix/master.cf to assure postfix-queue does not get called, ever. The two places it gets called is for 127.0.0.1:10025 (with before-queue processing) and 127.0.0.1:10027 (with before-remote processing). So looking for where mail is forwarded to 127.0.0.1:10025, I replace its "smtpd_proxy_filter" to go to 127.0.0.1:10026. So the following two lines are changed:

OLD:
smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025
smtps inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes

NEW:
smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10026
smtps inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10026 -o smtpd_tls_wrappermode=yes

It seems to work, but I'm testing quotas, mailgroups, etc.

One thing I did notice which bothers me in testing quotas is that regardless of whether I bypass or allow the postfix-queue to be called, it actually queues messages that put a user over quota rather than bouncing them. It marks them with "Message can not be delivered at this time" and they remain in the queue (for 2 days now).

 

[105547111]

Can we expect a fix sometime while it's still 2009?

 

[trauma]

Yeah... this is a serious deal-breaker for using Postfix with Plesk. I'm not sure how their internal testing is conducted, but this seems like more than just a "bug." It's really broken.

Does anybody know what issues I'll run into switching from Postfix to Qmail on a production server?

I'm currently limping along with the broken Postfix, but customers are starting to complain.

 

[albans]

Personnaly, I ran into the same problem and had to switch back to qmail on a production server.
So, the only issue I noted: the postfix queue is cleared! It doesn't "migrate" the queue to qmail...
But this shouldn't be a big deal.

 

[105547111]

The postfix-queue hotfix has yet again without Parallels saying anything updated again. Date is Apr 20.

Parallels - please can you update us when you keep changing these hotfixes - why the silence?

 

[James Drew]

Solution:
just uncheck a box.

Click Tools >Accounts >Mail >Properties >Advanced >untick break apart messages over 60kb

 

[James Drew]

Soulution:
just uncheck a box.

Click Tools >Accounts >Mail >Properties >Advanced >untick break apart messages over 60kb

2: If face still problem then you check account settings.

 

[105547111]

Interestingly enough with this update (20 Apr) of the postfix-queue, the segfaults in my /var/log/messages have stopped! This is great the first time the segfaults have stopped ever since upgrading to plesk 9.0 and using postfix.

This is indeed good, as its not segfaulting means it must be not dying in processing mail.

I urge you all to re-download the hotfix and update!

 

[Alexander Stamatis]

It worked.

 

[galaxy]

I've rewritten the plesk-postfix interfaces so that delivery goes through my own daemons now rather than using the inefficient postfix "pipe" command transport. As a bonus I got about a 10x performance boost. I can also reliably deliver 10-50M attachments. I have another daemon that replaces the postfix-queue command that I presume processes spam and virus filtering. I've recommended to the plesk folks to replace their pipe/command transport with a LMTP server daemon.

 

[105547111]

More than 3 days and still not one segfault, so for Fedora 8 atleast this hotfix finally resolved the issue.

 

[PSi_101]

The updated fix hasn't helped in my case.

 

[105547111]

Maybe post your OS and are you sure it's the April 20th update?

Parallels how about a list of all the OS and the exact filesize in bytes so people can know what version they have by filesize and notify us when it's updated it's loke the 3rd or 4th iteration so far.

 

[PSi_101]

I'm running on Debian 4.0 i386 and i'm 100% positive i'm using the April 20th update of postfix-queue.

 

[trauma]

Anybody know if today's 9.2 update fixes this? The release notes mention several Postfix bug fixes.

 

[Petrou Net]

Anybody know if today's 9.2 update fixes this? The release notes mention several Postfix bug fixes.

I have installed Plesk 9.2.1 on a test server, postfix now works, but not domainkeys.

 

[105547111]

Now I got to go and tweak postfix as emails to non existent users @domains I am receiving mailer daemon notices!

 

[105547111]

add to main.cf

notify_classes =

THis shuts it up.

But parallels please comment why is postfix-queue once again segfaulting

So is the April 20th patch newer than the plesk 8.2.1 fix?

Apr 30 18:05:42 server kernel: postfix-queue[22021]: segfault at 73657272 ip 0804a149 sp bf905e00 error 4 in postfix-queue[8047000+12000]

Full of these once again!