• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.

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

And their solution will be to increase the timeout from 100 seconds as I did above I'm sure.
If you have any scanning of the message by any filter, or if it goes to several recipients, or recipients that forward it to many destinations, it will take longer than this. I've found I only got the error message when any of these circumstances occurred, and since increasing the timeout, have yet to receive another one. I used to get dozens daily, haven't seen any in 3 days now.
 
actually galaxy I cannot agre with you.
It isn't that simple as I am receiving this error from time to time only.
They diagnosed that if message contains one long (4096 chars and above) line without line feeds. according to mails from them, they are going to repair postfix-queue and release it as a hotfix.
mail from yesterday: "This is just a ticket status upgrading message.
Development team is still working on the issue however without any luck. The bug report has high priority and hotfix was requested."
 
Perhaps there's more going on in postfix-queue, but I've eliminated their whole stack, including postfix-queue.

The reason for the error "451 Error: queue file write error" is that the smtpd_proxy_filter is taking too long. Period.
Thats the message postfix generates when the proxy filter takes too long.

I have my own filtering and delivery agents that I plugged in there and I still got the message occasionally as I stated before, however increasing the timeout made them go away.

So whatever they do to fix postfix-queue, they need to make it faster, and in many cases (like delivery to several folks, large attachments, etc) that make the delivery process take longer than the default of 100s, you will get this error message. Problems like postfix-queue crashing will of course never return, hence taking longer than 100s.

So regardless, you'll need to increase the timeout if you have any processing of messages going on and allow large messages (we allow up to 30M emails and anything you do to postfix-queue won't come back fast enough if you try to deliver that to 50 recipients).

I'm sure there's lots of bugs in the new code they've done to support postfix. I don't think they're going to get it all fixed any time soon. Thats why I've taken out all the parallels code doing that and put my own proxy in there to talk to a daemon rather than the 2-4 fork/exec's the way parallels decided to handle this. My load has been significantly reduced making the switch as well since I run all processes as lean daemons that are fast to process. I get about 5x throughput over qmail and much faster than the postfix-queue they had in there.
 
Galaxy: unfortunately a lot of us don't know how to write our own filtering and delivery agents, which is why we have to rely on Parallels :)
Heck we shouldn't even have to write our own code!
 
same problem here. I've added the code smtpd_proxy_timeout = 600s in main.cf
restarted postfix, but it didn't helped.

This is what i've got:

Out: 220 my.server.name ESMTP Postfix
In: EHLO *****
Out: 250-my.server.name
Out: 250-PIPELINING
Out: 250-SIZE 10240000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:<***@***.**> SIZE=30848
Out: 250 2.1.0 Ok
In: RCPT TO:<***@***.**>
Out: 250 2.1.5 Ok
In: DATA
Out: 354 End data with <CR><LF>.<CR><LF>
Out: 451 4.3.0 Error: queue file write error
In: QUIT
Out: 221 2.0.0 Bye
 
same problem here. I've added the code smtpd_proxy_timeout = 600s in main.cf
restarted postfix, but it didn't helped.


Try changing postfix-queue binaries (maybe in hotfix where will be one which will work better than original) and wait for another hotfix (unfortunatelly I've got email that developers don't know how to solve this but their working week is over and they will get back to work on monday :( )
 
OK, the segment violation core dumps require the hotfix, however the problem with "451 Error: queue file write error" is only a by-product.

This error means that the smtpd_proxy_filter took longer than 100 seconds (the default).
This is typically the "postfix-queue" program and anything it also runs.

So if you have large attachments coming through and the scanner, and everything that postfix-queue does takes longer than 100 seconds, its going to report the "451 Error: queue file write error".

So to solve this, increase your timeout. I've increased mine to 600 seconds (10 minutes), your mileage may vary.

Add the following to /etc/postfix/main.cf:

smtpd_proxy_timeout = 600s

For more details on this, look at http://www.linux-faqs.com/faq/postfix/SMTPD_PROXY_README.php and search for smtpd_proxy_filter and smtpd_proxy_timeout.

Apparently did it worked here. After the change I did a postfix reload,... and then there wasn't any change. After a while I did a postfix restart, and after that, no more error messages...
 
Waiting on hotfixes.

/etc/postfix/main.cf:
smtpd_proxy_timeout = 600s
Done, evaluating...

Finally Parallels developers were able to reproduce this issue on their servers. They informed me that thay are
working on new hotfix now and priority is high.
I think we can only wait. Hope not long

I've got a ticket into them with a high priority, I think I finally gave them enough info and they were able to reproduce it like you said, the hot fix is being worked on, and I'm pleased to report their customer service is getting much better, starting to have a warm fuzzy.
 
So far so good

Seems the specific error messages in question are gone from the system. I have not received any postfix notification since this morning before installing the hotfix. I wish all the same success with their hotfix install.
 
I'm still seeing the errors after installing the patch from yesterday and having my smtpd_proxy_timeout set to 600s.

I still get warning: timeout talking to proxy 127.0.0.1:10025 fairly often.

Transcript of session follows.

Out: 220 xxxx.xxxx.net ESMTP Postfix
In: EHLO blu0-omc2-s36.blu0.hotmail.com
Out: 250-xxxx.xxxxxx.net
Out: 250-PIPELINING
Out: 250-SIZE 25729024
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:<[email protected]> SIZE=28701
Out: 250 2.1.0 Ok
In: RCPT TO:<[email protected]>
Out: 250 2.1.5 Ok
In: DATA
Out: 354 End data with <CR><LF>.<CR><LF>
Out: 451 4.3.0 Error: queue file write error
In: QUIT
Out: 221 2.0.0 Bye
 
Same here

I'm also receiving the same errors however I do have LESS of these messages compared to 30-100 per day I've received the one below... funny thing was the entire connection was down at this time due to a T-storm....

But this came in AFTER several reboots as well....

Transcript of session follows.
Out: 220 FQDNOFSERVER ESMTP Postfix
In: EHLO mail-qy0-f194.google.com
Out: 250-FQDNOFSERVER
Out: 250-PIPELINING
Out: 250-SIZE 1024000000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-AUTH PLAIN DIGEST-MD5 LOGIN CRAM-MD5
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:<[email protected]>
Out: 250 2.1.0 Ok
In: RCPT TO:<[email protected]>
Out: 250 2.1.5 Ok
In: DATA
Out: 354 End data with <CR><LF>.<CR><LF>
Out: 451 4.3.0 Error: queue file write error
In: QUIT
Out: 221 2.0.0 Bye
 
Last edited by a moderator:
Same Problem

This problem has been occuring ever since I upgraded Plesk 9.0 (was a fairly new install on CentOS 5) to Plesk 9.2. I've tried all the fixes that have been put forward so far by Parallels and none of them have helped at all. I can very easily repeat this, just by creating a mail with an attachment or two.

Jun 4 22:44:39 ds01 postfix/smtpd[7477]: connect from unknown[IPADDRESS]
Jun 4 22:44:39 ds01 postfix/smtpd[7477]: warning: SASL authentication failure: realm changed: authentication aborted
Jun 4 22:44:39 ds01 postfix/smtpd[7477]: warning: unknown[IPADDRESS]: SASL DIGEST-MD5 authentication failed: authentication failure
Jun 4 22:44:39 ds01 postfix/smtpd[7532]: connect from unknown[127.0.0.1]
Jun 4 22:44:39 ds01 postfix/smtpd[7477]: NOQUEUE: client=unknown[IPADDRESS], sasl_method=LOGIN, sasl_username=EMAILADDRESS
Jun 4 22:44:39 ds01 postfix/smtpd[7532]: EBEC937055F: client=unknown[IPADDRESS]
Jun 4 23:44:39 ds01 before-queue[7810]: check handlers for addr: EMAILADDRESS
Jun 4 23:44:39 ds01 before-queue[7810]: Processing handlers...
Jun 4 23:44:39 ds01 before-remote[7811]: check handlers for addr: EMAILADDRESS
Jun 4 23:44:39 ds01 before-remote[7811]: Processing handlers...
Jun 4 23:45:09 ds01 before-remote[7811]: Timeout reading data from stream
Jun 4 23:45:09 ds01 before-remote[7811]: Unable to read data from stream
Jun 4 23:45:09 ds01 before-remote[7811]: Some error occured
Jun 4 22:45:09 ds01 postfix/smtpd[7532]: lost connection after DATA from unknown[127.0.0.1]
Jun 4 22:45:09 ds01 postfix/smtpd[7532]: disconnect from unknown[127.0.0.1]
Jun 4 23:45:09 ds01 postfix/spawn[7530]: warning: command /usr/lib/plesk-9.0/postfix-queue exit status 255
Jun 4 23:45:10 ds01 before-queue[7810]: hook_dir = '/usr/local/psa/handlers/before-queue'
Jun 4 23:45:10 ds01 before-queue[7810]: recipient[3] = ' <EMAILADDRESS>'
Jun 4 23:45:10 ds01 before-queue[7810]: handlers dir = '/usr/local/psa/handlers/before-queue/recipient/ <EMAILADDRESS>'
Jun 4 23:45:10 ds01 before-queue[7810]: errno: Broken pipe
Jun 4 23:45:10 ds01 before-queue[7810]: System error: Broken pipe
Jun 4 23:45:10 ds01 before-queue[7810]: Unable to write data to stream
Jun 4 23:45:10 ds01 before-queue[7810]: Some error occured
Jun 4 23:45:10 ds01 postfix/spawn[7113]: warning: command /usr/lib/plesk-9.0/postfix-queue exit status 255
Jun 4 22:45:10 ds01 postfix/smtpd[7477]: warning: lost connection with proxy 127.0.0.1:10025
Jun 4 23:45:12 ds01 postfix/cleanup[7753]: AFA3B37055F: message-id=<20090604224512.AFA3B37055F@HOSTNAME>
Jun 4 22:45:12 ds01 postfix/smtpd[7477]: disconnect from unknown[IPADDRESS]

This is a sample maillog from trying to send a message that included two attachments. The total message size is probably about 1MB.
 
I submitted a bug report and I recommend everyone who has not done so submit one for the issue.

In response to my bug report I was asked 'Please revert your postfix-queue from KB 6394 to the original file.'
 
Back
Top