• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • 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)

Here ya all go

I'm not sure why when a problem like this is identified they don't post that information here, so... here is the lastest info on the issue from a parallels support staff member in the ticket I have open currently. I'm not sure what other problem they have confirmed with their previous fix, however my box currently has WAY less messages like the ones above then it ever had (well since recent updates of course). I am impressed that they have worked so closely with me on this so far, but I am like many of you waiting for THE official fix.

We have just received some additional information from the development team about the hotfix. They confirmed that another problem exists and it cannot be resolved with new hotfix unfortunately.


The KB article has been disabled.


Currently developers are working on the problem. After the it is resolved and the fix is approved by our Quality Assurance Team it will be included to next update of Parallels Plesk Panel. We do not have exact release date, please watch our website for announcements about new updates.
You may subscribe to the announcements through http://www.parallels.com/mailinglists/subscribe/ and receive the notifications by email.


For now we recommend to place old binary /usr/lib/plesk-9.0/postfix-queue that works normally.


Please accept our apology for the inconvenience.


With king regards, ..."
 
I think I fixed it.

I was getting 20 to 30 "Postfix SMTP server: errors from unknown[xx.xx.xx.xx]" emails per day.
Each one was an "Error: queue file write error."
Here is how I fixed it:

edit: /etc/postfix/main.cf

change message_size_limit to zero:

message_size_limit = 0

That's it! Save and restart postfix.

The "errors from unknown" emails have completely stopped. I havn't had a single one in over twelve hours.
 
I also just tried setting message_size_limit = 0, and I still get the postfix error messages

This is again one of these ridiculous Plesk situations where there is an obvious and highly visible Plesk bug and no support whatsoever in fixing it
 
I have the same problem. Messages around 10 MB and higher will come back with the following error.message. In /usr/local/psa/handlers/spool I can see a file which is going more and more bigger, up to ca. 18 MB. Then the transfer stop with errors:

Transcript of session follows.

Out: 220 my.domain.tld ESMTP Postfix
In: EHLO Atlas
Out: 250-my.domain.tld
Out: 250-PIPELINING
Out: 250-SIZE 1024000000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-AUTH PLAIN CRAM-MD5 DIGEST-MD5 LOGIN
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: STARTTLS
Out: 220 2.0.0 Ready to start TLS
In: EHLO Atlas
Out: 250-my.domain.tld
Out: 250-PIPELINING
Out: 250-SIZE 1024000000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-AUTH PLAIN CRAM-MD5 DIGEST-MD5 LOGIN
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: AUTH LOGIN
Out: 334 justacode
In: anothercode
Out: 334 morecodes
In: anothercode
Out: 235 2.7.0 Authentication successful
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: RSET
Out: 250 2.0.0 Ok
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: RSET
Out: 250 2.0.0 Ok
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>

Session aborted, reason: lost connection

Some more informations from /var/log/mail.err:
Jun 15 08:20:06 my-domain before-queue[24481]: Processing handlers...
Jun 15 08:20:24 my-domain before-queue[23478]: errno: Broken pipe
Jun 15 08:20:24 my-domain before-queue[23478]: System error: Broken pipe
Jun 15 08:20:24 my-domain before-queue[23478]: Unable to write data to stream
Jun 15 08:20:24 my-domain before-queue[23478]: Some error occured
Jun 15 08:20:25 my-domain before-queue[24494]: Processing handlers...
 
Last edited by a moderator:
The increasing timeout to 600 didn't worked on our server... it did, for a few days. But that's because I also increased the limit from 10000KB to 15000KB.

Now it starts with messages from > 18MB. Where does it ends?

I want the server to send a message that the size is to big, and I don't want error messages that the server has received messages bigger than the limit and can't handle it....
 
I can't send emailattachments bigger than 10 MB
OK, it must go on and here is all of them I have done:

Configuration:

Suse 11.0
Plesk 9.2.1
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md1 479629016 43460100 411805144 10% /
udev 2014396 100 2014296 1% /dev
/dev/md0 54348 10802 40740 21% /boot
tmpfs 2014396 0 2014396 0% /usr/local/psa/handlers/before-local
tmpfs 2014396 0 2014396 0% /usr/local/psa/handlers/before-queue
tmpfs 2014396 0 2014396 0% /usr/local/psa/handlers/before-remote
tmpfs 2014396 4300 2010096 1% /usr/local/psa/handlers/info
tmpfs 2014396 4036 2010360 1% /usr/local/psa/handlers/spool

awstats 6.7-42.123
bind 9.4.2-39.4
coldfusion Komponente wurde nicht installiert
coldfusion-support 9.2.1-suse11.0.build92090422.13
courier-imap 3.0.8-suse11.0.build92090422.13
drweb 4.33-suse5_psa
frontpage Komponente wurde nicht installiert
httpd 2.2.8-28.4
kav4ms 5.5-1-Plesk
mailman 2.1.9-159.2
mod_bw 0.8-5
mod_perl 2.0.3.99-46.1
mod_python 3.3.1-123.1
mysql 5.0.51a-27.2
perl-Apache-ASP 2.59-0.94884
php 5.2.9-0.1
plesk-billing Komponente wurde nicht installiert
postfix 2.5.1-28.5
postgresql-server 8.3.7-0.1
psa 9.2.1-suse11.0.build92090422.13
psa-api-rpc 9.2.1-suse11.0.build92090422.13
psa-atmail 1.02-suse11.0.build92090422.13
psa-autoinstaller 3.4.1-090204.18
psa-backup-manager 9.2.1-suse11.0.build92090422.13
psa-drweb-configurator 9.2.1-suse11.0.build92090422.13
psa-horde 3.1.7-suse11.0.build92090422.13
psa-imp 4.1.6-suse11.0.build92090422.13
psa-logrotate 3.7-suse11.0.build92090422.13
psa-migration-manager 9.2.1-suse11.0.build92090422.13
psa-miva Komponente wurde nicht installiert
psa-mod-fcgid-configurator 1.0.1-0.94849
psa-proftpd 1.3.1-suse11.0.build92090422.13
psa-qmail Komponente wurde nicht installiert
psa-qmail-rblsmtpd Komponente wurde nicht installiert
psa-rubyrails-configurator 1.1.6-suse11.0.build92090422.13
psa-spamassassin 9.2.1-suse11.0.build92090422.13
psa-tomcat-configurator 9.2.1-suse11.0.build92090422.13
psa-turba 2.1.7-suse11.0.build92090422.13
ruby 1.8.6.p114-6.2
samba 3.2.4-4.3
sitebuilder Komponente wurde nicht installiert
spamassassin 3.2.4-29.1
SSHTerm 0.2.2-9.278624
tomcat 6.0.16-6.4
webalizer 2.01-923.1

I can't show you all my configuration because there is a limit:
The text that you have entered is too long (16803 characters). Please shorten it to 10000 characters long.

So I have found a german forum and there I've been able post all my configuration-files: http://www.plesk-forum.de/viewtopic.php?f=14&t=1572
 
I had a similar issue. After upgrade Plesk to version 9.2.1 all my emails are going to yahoo spam folder. Something with the DKIM is not working, I am getting in the email headers DKIM (NO SIG). How can I manually fix this in Qmail ?

Thanks !
 
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.

Hi galaxy.

I tried adding a recommended here, "smtpd_proxy_timeout = 600s". But it's having no effect. Would you be willing to share instructions for your fix? Or I would even be interested in hiring you to do it. This problem is driving me nuts after having upgraded to 9.2.1 the other day and having Postfix configured as well.

David
 
So there is still no fix for this. What about the guys who had an open ticket with Parallels about tis?? Did they get any new feedback?
 
It's definitely SPF spam protection.

Hi All,

Yesterday I upgraded plesk from 8.x version to 9.2.1 (Which I regret now).

I can't belive this thread was opened on December 2008.

I should've read these kind of forums first. Anyway..... I've been testing trying to find the problem.

This is what I did:
- Changed Maximum message size to 0 (unlimited)
- Set smtpd_proxy_timeout to 900 in main.cf
- DomainKeys spam protection only for incoming email
- DNS blackhole list enabled using: sbl-xbl.spamhaus.org
- Dr. Web Disabled

None of these seemed to work until SPF spam protection was disabled. (Leaving all other settings as described before)

After disabling SPF, Postfix auto-reloads (you can see when the IMAP connection is broken), and then all those big size emails starting to be delivered.

In my experiencie..... qmail was faster and more reliable, but none of the spam verifications worked as they should.

As I upgraded to postfix, all anti-spam features started to work pretty good, SPF, DomainKeys, DNS Blackhole, etc. and spam was reduced dramatically.

The problem must be a the timeout while writting file to the queue.

Postfix send incoming email to a mail proxy, and then passed through all those verifications, that's why in some cases removing the proxy part of the master.cf line:

smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025

makes it work.

I'd like to do some more testing but the slow internet connections we have in Mexico takes 30 min. to send a 20MB email.

If any support personal from parallels would like to access my server and do some testing, just send a line here.


Hope this helps for some of you.
 
Also noticed

I also noticed something wrong with the postfix queue.

An email sent July 21, 2009 10:43 AM , says that the age is: 14446 day(s) 23:31:57

Weird huh ?
 
20 MB Email Sent Successfully

I've just sent a 20 MB Email successfully disabling SPF (view previous post).

I'll try with a larger e-mail later.
 
Hi,

I switched back to qmail and setup Spamdyke to fight spam. I'm sorry to say… but I don't think that Parallels even know what they do, sometimes (or most of the time). Just have a look at the changelog for 9.2.1 – there were bugs fixed that should never even have been introduced by professional software developers and well thought release cycles. I think they never heard of testing, continous integration & friends. Their software feels like they must be sitting and hacking all day long.

So… I finally gave up. Since this mess here we're working to roll our own control panel based upon Ruby on Rails.
 
Last edited:
I had no SPF activated, and had this problem.

I also disabled DNS blackhole lists, and continue to get this error.

So I'm afraid that for me at least, Alfredo's workaround does not work.

I can only concur to Yves comments
 
Finally got if working....

All right... this is what I did.


After detection several (a lot) messages of 'lost connection with proxy' I decided to unplug any smtp proxy from postfix.

I had to comment some lines in master.cf file.... these are some of the lines I moved:

smtp inet n - - - - smtpd
###-o smtpd_proxy_filter=127.0.0.1:10025

###pickup fifo n - - 60 1 pickup -o content_filter=smtp:127.0.0.1:10027

###127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
###127.0.0.1:10026 inet n - - - - smtpd
###127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote

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

submission inet n - - - - smtpd
###-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=127.0.0.1:10025

The problem is in the smtp_proxy

I sent big attachments and they work now !

Hope this helps already
 
All right... this is what I did.


After detection several (a lot) messages of 'lost connection with proxy' I decided to unplug any smtp proxy from postfix.

I had to comment some lines in master.cf file.... these are some of the lines I moved:

smtp inet n - - - - smtpd
###-o smtpd_proxy_filter=127.0.0.1:10025

###pickup fifo n - - 60 1 pickup -o content_filter=smtp:127.0.0.1:10027

###127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
###127.0.0.1:10026 inet n - - - - smtpd
###127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote

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

submission inet n - - - - smtpd
###-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=127.0.0.1:10025

The problem is in the smtp_proxy

I sent big attachments and they work now !

Hope this helps already
Haven't had any time to test this, but does anybody else tried this?
(Still think it's a SHAME that Plesk/Parallels dont come up with a good working solution.)
 
Hi,

I would like to loose a few words, again.
What I'm going to tell is proven bei reality – we administer round about 40 servers with Plesk installed.

1. Plesk has no real Postfix integration. It's a bluff package. Pure marketing. Believe it and stay with qmail. If already switched to Postfix – switch back and stop the pain.

(I'm sorry to say that because Postfix is my favorite, too.)

2. Don't hope for help from Parallels.

I tried to escalate those issues over an Enterprise Platinum Support Contract. This is the most expensive and best one Parallels has to offer. It's over half a year since I told them that this Postfix mess f***s up our business. They don't really care. They are sorry about that. But they are not able to fix this.

So… if you need to stick with Plesk because of customer demands and requests – do yourself a favor and stay with qmail. Even if you dislike qmail and the Bernstein philosophy.
 
Back
Top