• 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

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

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.
Wow, 14 thread pages so far, this thread has become really big since I started it back in December 2008.

IgorG,
If I understood correctly you suggest that this error is basically the e-mail client's fault (if it's indeed sending a malformed message).
However, this error happens when using Postfix and a user tries to send an e-mail with a large attachment (in my case it started happening when my clients were sending attachments of 2MB or larger).
But when using QMail, this error doesn't happen at all and the user can send e-mails with attachments just fine, even sending successfully the exact same message, with the exact same e-mail client, that were used also when the server was running Postfix.
So if it happens only with Postfix and not with Qmail, how can we blame the e-mail client?
 
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.

I don't dispute it's the correct error code. But what is malforming my messages then?

Just a regular plain text message to my email address, from someone who sends me emails all of the time randomly comes up with this error. It then causes Postfix to have a fit and all other messages received by Postfix get that error message until Postfix is restarted.

Even if one of my users sends out an email it comes up with the same error code:

Transcript of session follows.

Out: 220 myserver.info ESMTP Postfix
In: EHLO Lenovo
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: AUTH DIGEST-MD5
Out: 334
bm9uY2U9IldvYmhUVmw1ZkR3VTg5Zm9yNHppa3k0b2tYTm5SZ3JnaUt6SEgzaFZoL0U9IixyZWFsbT0iczE1MzQxMzc3Lm9ubGluZWhvbWUtc2VydmVyLmluZm8iLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=
In:
dXNlcm5hbWU9Imp1c3Rpbi5idXJ0IixyZWFsbT0icmVub3duc2VydmljZXMuY28udWsiLG5vbmNlPSJXb2JoVFZsNWZEd1U4OWZvcjR6aWt5NG9rWE5uUmdyZ2lLekhIM2hWaC9FPSIsZGlnZXN0LXVyaT0ic210cC9yZW5vd25zZXJ2aWNlcy5jby51ayIsY25vbmNlPSIyNDQzZDI5NjQyMTRkMGQ0OWQxMzYzYjY5MmM4YWViYyIsbmM9MDAwMDAwMDEscmVzcG9uc2U9OTQ2MWU3YWQzNGVjZTZiODg4M2FiNzdiNDRjN2I5ZWIscW9wPWF1dGgsY2hhcnNldD11dGYtOA==
Out: 535 5.7.0 Error: authentication failed: authentication failure
In: AUTH LOGIN
Out: 334 VXNlcm5hbWU6
In: anVzdGluLmJ1cnRAcmVub3duc2VydmljZXMuY28udWs=
Out: 334 UGFzc3dvcmQ6
In: Y2FyZ28=
Out: 235 2.0.0 Authentication successful
In: MAIL FROM: <[email protected]> (ONE OF MY USERS)
Out: 250 2.1.0 Ok
In: RCPT TO: <[email protected]>
Out: 451 4.3.0 Error: queue file write error
In: RCPT TO: <[email protected]>
Out: 451 4.3.0 Error: queue file write error
In: RCPT TO: <[email protected]>
Out: 451 4.3.0 Error: queue file write error
In: QUIT
Out: 221 2.0.0 Bye

If malformation is the reason behind this then it's the implementation that is malforning these messages surely?

Thanks.
 
Last edited:
Wow, 14 thread pages so far, this thread has become really big since I started it back in December 2008.

IgorG,
If I understood correctly you suggest that this error is basically the e-mail client's fault (if it's indeed sending a mailformed message).
However, this error happens when using Postfix and a user tries to send an e-mail with a large attachment (in my case it started happening when my clients were sending attachments of 2MB or larger).
But when using QMail, this error doesn't happen at all and the user can send e-mails with attachments just fine, even sending successfully the exact same message, with the exact same e-mail client, that were used also when the server was running Postfix.
So if it happens only with Postfix and not with Qmail, how can we blame the e-mail client?

I have forwarded it to developers. Let's wait their answer.
 
Wow, 14 thread pages so far, this thread has become really big since I started it back in December 2008.

IgorG,
If I understood correctly you suggest that this error is basically the e-mail client's fault (if it's indeed sending a mailformed message).
However, this error happens when using Postfix and a user tries to send an e-mail with a large attachment (in my case it started happening when my clients were sending attachments of 2MB or larger).
But when using QMail, this error doesn't happen at all and the user can send e-mails with attachments just fine, even sending successfully the exact same message, with the exact same e-mail client, that were used also when the server was running Postfix.
So if it happens only with Postfix and not with Qmail, how can we blame the e-mail client?

Hi Petrou, welcome back!

I guess you ended up switching to QMail then? My server has been badly messing around for the last few days, Postfix is really struggling. Have you experienced any problems with QMail?

Similarly to your issue it appears that sending / receiving attachments screws Postfix up. When users receive or send attachments Postfix starts issuing these 451 errors, then nothing can get sent or received after that (with or without attachments) as everything comes up with 451 errors until Postfix is restarted.

Cheers.
 
Last edited:
Just to note - I am also seeing this error after upgrading (again) to 9.5.3 (not ready to make the jump to 10.x yet)... once again, I took the plesk 9.2x binary for 'postfix-queue' (md5sum f8ad3bc68202fac408c71bbbb7d2a9d8) and replaced the one that 'psa-mail-pc-driver' installed, and all the issues went away.
 
Just to note - I am also seeing this error after upgrading (again) to 9.5.3 (not ready to make the jump to 10.x yet)... once again, I took the plesk 9.2x binary for 'postfix-queue' (md5sum f8ad3bc68202fac408c71bbbb7d2a9d8) and replaced the one that 'psa-mail-pc-driver' installed, and all the issues went away.

I only jumped from v9 to v10 as I thought (from this exact thread) that this issue was due to be fixed "in the next update" by "the autumn", so I only updated to try and get rid of this issue. Where in actual fact it's worse than its ever been now. After upgrading to v10 it seemed OK until yesterday, where I think there may have been another update to Plesk the day before that was installed.

Before I had the error once every week, and a restart sorted it. Now I have this error every day, and restarting only stops it from happening again for a few hours at the most.

Where did you get the 9.2x binary from? Is it a simple overwrite and restart job? Cheers.
 
Hi Petrou, welcome back!

I guess you ended up switching to QMail then? My server has been badly messing around for the last few days, Postfix is really struggling. Have you experienced any problems with QMail?

Similarly to your issue it appears that sending / receiving attachments screws Postfix up. When users receive or send attachments Postfix starts issuing these 451 errors, then nothing can get sent or received after that (with or without attachments) as everything comes up with 451 errors until Postfix is restarted.

Cheers.
Yes, I switched back to QMail in December 20th 2008 (4 days after I started this thread) and still using QMail ever since (currently still using it on Plesk Panel 10.0.1), this problem doesn't appear when using QMail.
 
Yes, I switched back to QMail in December 20th 2008 (4 days after I started this thread) and still using QMail ever since (currently still using it on Plesk Panel 10.0.1), this problem doesn't appear when using QMail.

If I knew how easy it was to switch MTAs I would have done this a year ago. But I put up with Postfix as I was only getting an error every now and then. I didn't want to mess things up further by switching MTAs as I'd had no experience of QMail and thought that may have the same / different bugs which may be worse.

Postfix was crashing due to these errors, and seemed to be taking up all my servers resources each time, therefore crashing the server too. The last couple of days this has been unbearable, with the server needing a full reboot every 2 to 3 hours. So I figured I would bite the bullet and switch to QMail, as that couldn't possibly be any worse than the Postfix implementation.

Now the server has been amazing for 6 hours! Hopefully this will continue.

I have to admit that the solution to this thread should NOT be to switch to QMail. The developers should actually fix the problem!!!

But I've given up on that for now, and seeing as this thread is 2 years old and they haven't fixed it yet, I don't hold out much hope for a future fix. Maybe they don't want to fix it / can't actually fix it, so everyone HAS to switch to QMail where they can then retire and remove Postfix from Plesk.

Thank you.
 
Last edited:
If I knew how easy it was to switch MTAs I would have done this a year ago. But I put up with Postfix as I was only getting an error every now and then. I didn't want to mess things up further by switching MTAs as I'd had no experience of QMail and thought that may have the same / different bugs which may be worse.

Postfix was crashing due to these errors, and seemed to be taking up all my servers resources each time, therefore crashing the server too. The last couple of days this has been unbearable, with the server needing a full reboot every 2 to 3 hours. So I figured I would bite the bullet and switch to QMail, as that couldn't possibly be any worse than the Postfix implementation.

Now the server has been amazing for 6 hours! Hopefully this will continue.

I have to admin that the solution to this thread should NOT be to switch to QMail. The developers should actually fix the problem!!!

But I've given up on that for now, and seeing as this thread is 2 years old and they haven't fixed it yet, I don't hold out much hope for a future fix. Maybe they don't want to fix it / can't actually fix it, so everyone HAS to switch to QMail where they can then retire and remove Postfix from Plesk.

Thank you Petrou.
Yes, technically switching to QMail, means just avoiding the problem, this can't be considered a true solution. However the users on a server usually don't care much about what an MTA is, they just want to send their e-mails successfully, so I did what I thought it was necessary to keep my users happy.

When using either Postfix or QMail, all the directories and files regarding e-mails, always reside in the same location (/var/qmail/mailnames) in my case I didn't have any trouble switching back to QMail, since the files basically stayed where they always were. However if you would like to switch back to QMail, take backup measures before attempting it.
You could use the autoinstaller (probably /usr/local/psa/admin/bin/autoinstaller, if you are using an rpm based linux) and the switch should be completed quickly without any trouble, just stop postfix before attempting it, and it would be preferred to uninstall postfix when the switch to QMail was done.

The above is just my personal opinion, it worked in my case but I don't know if it works in your case. If you try it, then try it at your own risk.
 
Last edited:
Yes, technically switching to QMail, means just avoiding the problem, this can't be considered a true solution. However the users on a server usually don't care much about what an MTA is, they just want to send their e-mails successfully, so I did what I thought it was necessary to keep my users happy.

When using either Postfix or QMail, all the directories and files regarding e-mails, always reside in the same location (/var/qmail/mailnames) in my case I didn't have any trouble switching back to QMail, since the files basically stayed where they always were. However if you would like to switch back to QMail, take backup measures before attempting it.
You could use the autoinstaller (probably /usr/local/psa/admin/bin/autoinstaller, if you are using an rpm based linux) and the switch should be completed quickly without any trouble, just stop postfix before attempting it, and it would be preferred to uninstall postfix when the switch to QMail was done.

The above is just my personal opinion, it worked in my case but I don't know if it works in your case. If you try it, then try it at your own risk.

Thanks, I did run the autoinstaller for QMail and that completed within 5 minutes, it was perfect. I'll look at removing Postfix then. Yes all the email files do stay in the same place, which is handy.

I don't know why QMail isn't the default MTA on Plesk, it would make more sense if it works correctly.
 
Thanks, I did run the autoinstaller for QMail and that completed within 5 minutes, it was perfect. I'll look at removing Postfix then. Yes all the email files do stay in the same place, which is handy.

I don't know why QMail isn't the default MTA on Plesk, it would make more sense if it works correctly.
Glad to know the switch completed successfully.
Actually I think QMail is the default MTA when installing plesk panel for the first time (at least I think it is when installing Plesk Panel on an rpm based linux).
 
Glad to know the switch completed successfully.
Actually I think QMail is the default MTA when installing plesk panel for the first time (at least I think it is when installing Plesk Panel on an rpm based linux).

I have a 1&1 VPS in the UK and the default on there was Postfix. Guess they must have set it up like that.

Cheers.
 
Oh, and anyone having this issue with Postfix, DON'T think twice about switching like I did, just do it straight away, or it will get worse!

/usr/local/psa/admin/sbin/autoinstaller --select-release-current --install-component qmail

Run that and you'll be done in 5 mins! Absolutely great.
 
Also having this with 9.5.2

One of my 9.5.2 servers started throwing the queue file write error the other day. Same symptoms as the other posters.

I saw Igor's post saying "sent to developers" so I'm waiting to see what he/they say, but I wanted to register that yes, this is still happening with 9.5.2

# cat /usr/local/psa/version
9.5.2 Ubuntu 8.04 95100504.17
 
One of my 9.5.2 servers started throwing the queue file write error the other day. Same symptoms as the other posters.

I saw Igor's post saying "sent to developers" so I'm waiting to see what he/they say, but I wanted to register that yes, this is still happening with 9.5.2

# cat /usr/local/psa/version
9.5.2 Ubuntu 8.04 95100504.17

Sorry to be pessimistic but it won't get fixed. It's been like it for 2 years already. I'd switch MTAs.
 
The problem in that there are can be thousand reasons of this error and it is very-very difficult to determine and fix all these reasons. Many of these reasons can't be fixed due to RFC.
We are really very anxious by this problem. It is prime with the higher priority and we want to solve it definitively. In the near future we will make the decision.
 
We are fully aware of the dismay the dreadful error 451 causes among our customers. I have created KB article http://kb.odin.com/en/9357 with instruction for gathering necessary logs for developers. You can use it for reporting this problem. Also if someone has "451 Error: queue file write error" on Plesk 10.x and he can provide direct access to server for detailed investigation by our developers - it would be very useful. Login credential can be sent to me in PM with short description and error logs.
 
I am seeing that this is affecting Small Business Panel 10.2 as well, but unfortunately there is no option to install QMail for SBP.

Do you have a possible ETA for this fix?

Regards,

Chris Y.
 
I am seeing that this is affecting Small Business Panel 10.2 as well, but unfortunately there is no option to install QMail for SBP.

Do you have a possible ETA for this fix?

Regards,

Chris Y.

I don't have SBP installed but can you not run the auto installer:

/usr/local/psa/admin/sbin/autoinstaller --select-release-current --install-component qmail

?
 
Back
Top