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

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.
Well, I had qmail, but qmail kept on running high cpu-load, even freezes the server several times. Once upgraded to postfix, that problem was solved. But received another problem instead of it :-(

I'm really looking to other products now. You pay a lot for Plesk, and what do you get. Only a fancy interface.
 
ok, 9.2.2 is out. In the what's new section, only Dr.Web 5 is mentioned. Nothing else!!!

So I asume the postfix issue has not been addressed.

If anyone has already installed it, please tell us if the postfix issue is still present
 
ok, 9.2.2 is out. In the what's new section, only Dr.Web 5 is mentioned. Nothing else!!!

So I asume the postfix issue has not been addressed.

If anyone has already installed it, please tell us if the postfix issue is still present

I obciously messed up with the dates... disregard my last message
 
JFYI:

We've updated all machines to 9.2.2 - nothing to worry about the upgrade but looking for fixes is a waste of time.
queue file write error still exists. just did another update like in KB (with autoinstaller via console) and it again updated postfix. we'll se if this brings good news... (will post it here)
 
smtp proxy

Guys,

My installation has been working great since I modified master.cf file

The problem is with the content filters or smtp proxies, if you remove all lines regarding filtering befire-queue and before-remote you'll be good to go.

This is my complete master.cf file after several modifications:

PLEASE BE AWARE THAT ANY CHANGES ON PLESK MAIL SETTINGS WILL RE-WRITE CONTENT FILTER PROXY OPTIONS.

#
# Postfix master process configuration file. For details on the format
# of the file, see the Postfix master(5) manual page.
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
submission inet n - n - - smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
pickup fifo n - - 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix - - n - - smtp
-o fallback_relay=
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache



#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent. See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
#
# The Cyrus deliver program has changed incompatibly, multiple times.
#
old-cyrus unix - n n - - pipe
flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
cyrus unix - n n - - pipe
user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient

plesk_virtual unix - n n - - pipe flags=DFORhu user=popuser:popuser argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p /var/qmail/mailnames
mailman unix - n n - - pipe flags=FR user=mailman:mailman argv=/usr/lib/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}
plesk_saslauthd unix y y y - 1 plesk_saslauthd status=5 listen=6 dbpath=/plesk/passwd.db

--------------------------------------------------------

After these modifications, I've not seen a single 451 Error.

Try it and post back how did it go.
 
@AlfredoP

With your solution it appears you are not filtering your messages with DrWeb or Spam Assassin at all?

Unless perhaps your doing something with procmail maybe.
 
ok, plesk 9.2.3 is out. From the release notes
"Mail forwarding not working and reporting broken pipe error when Postfix mail server is used bug is fixed."

Has anyone tried this release?
 
An more postfix related bugs
"Mail malfunctioning due to buffer length limitation in spam handlers bug is fixed."
"Postfix mail server crashing with segfault error on processing messages with strings larger than 4096 characters bug is fixed."
 
Postfix still doesn't work correctly. Just tried Plesk 9.2.3 with Postfix on a CentOS 5 testing server.
Even on Plesk 9.2.3, Postfix still raises queue file write errors on messages with large attachments (above 5MB), and when Postfix is used, DomainKeys protection is not working.
 
Anyone who has a running system or not switched back to qmail yet should NOT try this update. At least not if it's not older than round about 6 weeks. This avoids headaches.
 
hi,

thanks for all the posted hints.

i am just encountering the same problem - although not by sending email, but receiving.


i've changed as AlfredoP mentioned my master.cf - little addition: i didn't out-coment the pickup line completely.


in any case this is highly disturbing! qmail is not anywhere near beeing an alternative to postfix.

if anyone needs it, here the log part:

2009-11-04T04:47:32.614128+01:00 postfix/smtpd[22394]: connect from unknown[xx.xx.xx.xx]
2009-11-04T04:47:32.902066+01:00 postfix/smtpd[22403]: connect from unknown[127.0.0.1]
2009-11-04T04:47:32.945568+01:00 postfix/smtpd[22394]: NOQUEUE: client=unknown[xx.xx.xx.xx]
2009-11-04T04:47:32.960841+01:00 postfix/smtpd[22403]: EA7EF1AC187E: client=unknown[xx.xx.xx.xx]
2009-11-04T04:47:32.980686+01:00 before-queue[22400]: check handlers for addr: [email protected]
2009-11-04T04:47:32.980868+01:00 before-queue[22400]: check handlers for addr: [email protected]
2009-11-04T04:47:32.981207+01:00 before-remote[22402]: check handlers for addr: [email protected]
2009-11-04T04:47:32.981370+01:00 before-remote[22402]: check handlers for addr: [email protected]
2009-11-04T04:47:33.058132+01:00 postfix/spawn[22399]: warning: command /usr/lib/plesk-9.0/postfix-queue killed by signal 11
2009-11-04T04:47:33.058374+01:00 postfix/smtpd[22394]: warning: lost connection with proxy 127.0.0.1:10025


anyhow, i hope i got the problem solved and wish for a real fix by parallels
 
I finally decied to do the upgrade to 9.2.3 and ;yckily it worked without a problem. At first I really thought the the postfix problem was fixed too. I did not get any error message for about 2 days. Today it started again!!! This is really strange. Why does it stop for so many hours. and then start again. Would a restart of postfix or psa every 12 hours solve the problem??
 
Would a restart of postfix or psa every 12 hours solve the problem??

i would say probably not I believe there is not just one issue in the handlers & postfix-queue stuff!

There was once a fix which suggested to use the original postfix-queue for me this still works but might be to have other side effects. But my opinion is all the selfmade handlers fom paralles seems to be wired...

Brujo
 
ok, it's now about 2 weeks sice the update, and although I do get spradic error messages from postfix, it is nowhere near the amount od errors I got previously.
So 9.2.3 seems to indeed fix this problem almost completely.

I consider this issue solved (until further notice of course, because with Plesk you never know what awaits you...)
 
Any news on this?

It's been three weeks since the last post here. Doess anybody have some new about this issue?
I keep getting those messages, but it's not a matter of the size of the mail, as 21227 Byte should not be to much.

Out: 220 h999999999.stratoserver.net ESMTP Postfix
In: EHLO snt0-omc3-s7.snt0.hotmail.com
Out: 250-h999999999.stratoserver.net
Out: 250-PIPELINING
Out: 250-SIZE 1024000000
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=21227
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


I also get it when users try to send

Transcript of session follows.

Out: 220 h999999999.stratoserver.net ESMTP Postfix
In: EHLO Dell6
Out: 250-h999999999.stratoserver.net
Out: 250-PIPELINING
Out: 250-SIZE 1024000000
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: AUTH DIGEST-MD5
Out: 334

bm9uY2U9IitCQlZUL2JOZjFOK2JLUnVucjYxeXZKUTFnUm43UllMR1hjcWQzVlFqQXc9IixyZWFsbT0iaDE2NTU0NTEuc3RyYXRvc2VydmVyLm5ldCIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==
In:

dXNlcm5hbWU9ImFkcyIscmVhbG09ImthaXNlcnNsYXV0ZXJuYW1lcmljYW4uY29tIixub25jZT0iK0JCVlQvYk5mMU4rYktSdW5yNjF5dkpRMWdSbjdSWUxHWGNxZDNWUWpBdz0iLGRpZ2VzdC11cmk9InNtdHAvbWFpbC5rYWlzZXJzbGF1dGVybmFtZXJpY2FuLmNvbSIsY25vbmNlPSI2MjJlOWRmYzBmMWIzNjRmMzdjZjNkZjRjODM3MmM5MCIsbmM9MDAwMDAwMDEscmVzcG9uc2U9NTc3NDczNTZjOWM2OTNjZDE5ZWVhYjU4Yjc4MmVkYzUscW9wPWF1dGgsY2hhcnNldD11dGYtOA== Out: 535 5.7.8 Error: authentication failed: authentication failure
In: AUTH LOGIN
Out: 334 VXNlcm5hbWU6
In: YWRzQGthaXNlcnNsYXV0ZXJuYW1lcmljYW4uY29t
Out: 334 UGFzc3dvcmQ6
In: Y2FCMllhUjc=
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: RCPT TO: <[email protected]>
Out: 250 2.1.5 Ok
In: RCPT TO: <[email protected]>
Out: 250 2.1.5 Ok
In: RCPT TO: <[email protected]>
Out: 250 2.1.5 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


I'm using Plesk 9.2.3 on a opensuse 11.1.
 
Message like

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

appears due to greylisting operation. It is correct behaviour. Client has received DEFER (Tempfail) from GL handler on unknown address.
 
Back
Top