• 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)

/usr/lib/plesk-9.0/postfix-queue is causing the problems

cPanel???

Just switch to Qmail if you have problems with Postfix....

Hi Igor,

thanks for the support and the effort to tackle this problem!

The problems are not with the Postfix software, but in an additional proxy queue filter written by Parallels.

Could you please ask the development team why they wrote their own implementation of a proxy filtering system for postfix when they also could have used the default postfix milter system with packages like the spamass-milter software?
 
looks like the problem is gone after i updated from 9.3.2 to 9.5.2.
at least i did not get any more postfix errors sind the update finished.
 
I had that issue as well this morning when I tried to send out emails to customers.

While getting stressed I remembered that yesterday an email has not been delivered to some email address but I didn't get any bounce message.

Here is what I did:

1. checked /var/log/maillog <-- nothing in there
2. restarted Posfix <-- Same issue
3. thought about switching to qmail <-- not an option
4. got really stressed <-- didn't help either
5. logged in to Plesk and went to: Settings -> Mail Server Settings -> Mail Queue
6. there was the culprit: The mail from yesterday was stuck in there with an attachment
7. deleted the stuck mail from the queue
8. restarted postfix <-- just to be on the safe side
9. after a few minutes I've been able to send out emails as usual without getting "Error: queue file write error"

Hope this will help somebody out there

Cheers
Oliver
 
I still have the problems. I have CentOS 5.5 and latest Plesk 9.5.2. This error happens to me with one sender only. They allways try to send one PDF and this mail is autogenerated paymanet confirmation mail. Any idea what else to try? Change to qMail is not option. Please help.
 
I have use qMail with 9.3.0 version of Plesk. But with upgrade to CentOS 5.5 in Plesk to 9.5.2, qMail stop working correctly and every new incoming mail bounces and make new qmail-xxxxxxxx.pl process and this processess filed up the server. When I switch to Postfix + Clapf everything is ok excpet this error. Will this be corrected or where is the problem?

Kind Regards, Davor
 
I have use qMail with 9.3.0 version of Plesk. But with upgrade to CentOS 5.5 in Plesk to 9.5.2, qMail stop working correctly and every new incoming mail bounces and make new qmail-xxxxxxxx.pl process and this processess filed up the server. When I switch to Postfix + Clapf everything is ok excpet this error. Will this be corrected or where is the problem?

Kind Regards, Davor

I think that you didn't rebuild qmail setting after upgrade with '/usr/local/psa/admin/sbin/mchk --with-spam'
 
I have rebuild qmail. I have used qmail-scanner ... is maybe problem in qmail-scanner?
 
I have rebuild qmail. I have used qmail-scanner ... is maybe problem in qmail-scanner?

It is difficult to say what is wrong in your case but I know a lot of Plesk 9.5.2 owners with qmail instead postfix without any problems.
 
This is error with postfix ... I just recieved this mail and only from this one domain ... It's not blocked, It's not on blacklist ... nothing ... I will try swith to qmail at weekend but I have not a good filling about that ...

Transcript of session follows.

Out: 220 xxxxxx.mydomain.me ESMTP Postfix
In: EHLO ns5.sendersmailserver.com
Out: 250-farm01.obiskuj.me
Out: 250-PIPELINING
Out: 250-SIZE 102400000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: STARTTLS
Out: 220 2.0.0 Ready to start TLS
In: EHLO ns5.impex.ro
Out: 250-xxxxxx.mydomain.me
Out: 250-PIPELINING
Out: 250-SIZE 102400000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-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

Session aborted, reason: lost connection
 
Hi

I have Plesk 9.5.2 and not 9.3 ...

df -h:

Filesystem Size Used Avail Use% Mounted on
/dev/md2 1.4T 24G 1.3T 2% /
/dev/md1 2.0G 97M 1.8G 6% /boot
tmpfs 5.9G 0 5.9G 0% /usr/local/psa/handlers/before-local
tmpfs 5.9G 0 5.9G 0% /usr/local/psa/handlers/before-queue
tmpfs 5.9G 0 5.9G 0% /usr/local/psa/handlers/before-remote
tmpfs 5.9G 76K 5.9G 1% /usr/local/psa/handlers/info
tmpfs 5.9G 20K 5.9G 1% /usr/local/psa/handlers/spool

smtpd_timeout=3600s

and

smtpd_proxy_timeout=3600s

is in main.cf by default ...

notify_classes is changed to and debug mode has been enabled for 4 hour when this mail was send (or try to send) in debug log is nothing strange, everything is ok ...

do u need debug log?
 
As far as I know this bug should be fixed in 9.5.3 version.
 
Sorry. We never provide any ETA. I can say only - in the autumn.

Right, it's well into the Autumn now, and I'm on v10.0.1 and still getting the 451 queue file write error. It's been happening since the beginning of v9, and people keep saying that it will be fixed in 9.0, 9.2, 9.3, 9.5, 9.5.1, 9.5.2, 9.5.3 and then now "in the autumn". But now I am on v10.0.1 and it's still not fixed. I guess it will be sorted in v10.0.2 ?

Why is it taking so long to sort out this issue?

Cheers.
 
Right, it's well into the Autumn now, and I'm on v10.0.1 and still getting the 451 queue file write error. It's been happening since the beginning of v9, and people keep saying that it will be fixed in 9.0, 9.2, 9.3, 9.5, 9.5.1, 9.5.2, 9.5.3 and then now "in the autumn". But now I am on v10.0.1 and it's still not fixed. I guess it will be sorted in v10.0.2 ?

Why is it taking so long to sort out this issue?

Cheers.

http://forum.parallels.com/showthread.php?t=106114
 

---------------------------------------------------------------
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Parallels Panel v10.0.1

CentOS - Linux 2.6.9-023stab052.4-smp

VPS running AuthenticAMD, Quad-Core AMD Opteron(tm) Processor 2352

1GB RAM (my share)

10GB HDD (my share)


PROBLEM DESCRIPTION AND STEPS TO REPRODUCE

Someone sends someone on my server an email. It occasionally bounces reporting a 451 4.3.0 Error: queue file write error.


ACTUAL RESULT

I get emailed the following when it happens:

Transcript of session follows.

Out: 220 myserver.info ESMTP Postfix
In: EHLO other.mel.local
Out: 250-myserver.info
Out: 250-PIPELINING
Out: 250-SIZE 10240000
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: STARTTLS
Out: 220 2.0.0 Ready to start TLS
In: EHLO other.mel.local
Out: 250-myserver.info
Out: 250-PIPELINING
Out: 250-SIZE 10240000
Out: 250-ETRN
Out: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:<[email protected]> SIZE=83599
Out: 250 2.1.0 Ok
In: RCPT TO:<[email protected]>
Out: 451 4.3.0 Error: queue file write error

Session aborted, reason: lost connection


EXPECTED RESULT

The email should get delivered.


ANY ADDITIONAL INFORMATION

This doesn't happen too often on my server as the email traffic is not that high at all. But it's been happening for over 1 year now.

When one queue file write error occurs, I then get about 15 after it where all following emails to the server receive the same error. Postfix then needs restarting which seems to sort out the issue.
--------------------------------------------------------------


Thank you.
 
Last edited:
451 is the correct error code as defined by RFC 821.
Most probably that problem is in malformed message. Qmail rejects it with the same error code as Postfix.
 
Back
Top