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

[Ricard Forn]

Here same problems, the "451 4.3.0 Error: queue file write error". We're receving dozens of emails in a day.

Ubuntu Server 7.10, Plesk 9.2.1 with postfix.

Only checked DNSBL in mail preferences, no antivir/SPF/DomainKeys activated.

Restarted services and server, still receving mails with the same problem.

Don't have applied the "http://kb.odin.com/en/6074" hotfix as parallels says that's included in the 9.2.1 and think the patch is older.

Any ideas?

Thanks in advance,

 

[william miller]

Hi, Any chance of a small write up on what exactly you did? I would love to do the same rather than wait ( decades) for an official plesk change...

 

[David Cottle]

As I discussed in the plesk 9.2 trouble forum I just backed up postfix-queue and reapplied the good old April 20 hotfox and the segfaults have once again stopped. This fixed a Fedora 7 and 8 server both were constantly segfaulting after the upgrade to 9.2.1

 

[PSi_101]

I'm starting to notice a trend of this problem being fixed for Red Hat/Fedora/CentOS type systems but not for Debian/Ubuntu systems.
Has the fix worked for anyone with a Debian based distro?

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

Debian 4.0

 

[105547111]

I would not say a 'trend' the ONLY binary to be any good was the April 20th hotfix release, to my knowledge there have been 5 now including the original release in 9.0.0. Forget the 9.2.1 release this was the worst of the lot for my two servers both redhat as I have got ossec running and any segmentation faults are emailed so I keep a watch on these.

I suggest anyone having issues try the April 20th hotfix, just backup the current binary, it can't hurt!

 

[lipek]

I still have segfault on Debian. I have hotfix installed but.... http://kb.odin.com/en/6074 says it was last reviewed April 20th. When i download the attachment http://kb.odin.com/Attachments/6513/Attachments/postfix-queue.tgz in headers I have:
Content-Type: application/octet-stream
Content-Length: 1391619
Last-Modified: Fri, 06 Mar 2009 08:06:17 GMT
it's not April 20th patch - it looks like March 06th patch
postfix-queue segfaults only in specific case:
Out: 220 abcde.pl ESMTP Postfix (Debian/GNU)
In: EHLO mail.xxx.pl
Out: 250-abcde.pl
Out: 250-PIPELINING
Out: 250-SIZE 20480000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-AUTH CRAM-MD5 PLAIN DIGEST-MD5 LOGIN
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:<[email protected]> SIZE=190695
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

it isn't very large message but this is what i can find in log: postfix/spawn[32240]: warning: command /usr/lib/plesk-9.0/postfix-queue killed by signal 11 (befor hotfix it was 255)
maybe this message is strange?
can I bypass postfix-queue somehow?

 

[Silicom Provider]

solution alternative

We can solve by using the mchk

/usr/local/psa/admin/sbin/mchk

[]´s

Silicom

 

[Silicom Provider]

after 20 minutes, this problem rollback :-(

wait for solution by parallels

 

[lipek]

could you explain more clearly?

 

[Ricard Forn]

Still problems with postfix-queue

The same problem that lipek is having...

Us, with Ubuntu 7.10 32bits.

With postfix-queue provided with plesk 9.2.1 we get the "command /usr/lib/plesk-9.0/postfix-queue killed by signal 255"

With postfix-queue provided by http://kb.odin.com/en/6074 (20 April) we get the "command /usr/lib/plesk-9.0/postfix-queue killed by signal 11"

Now a segfault problem?

Think that the hotfix doesnt works in Debian/Ubuntu distros. Please, paralells, could you do something to solve this problem?

 

[lipek]

I am now switching postfix-queues binaries (one for debian4, one for debian3 and one for ubuntu6) every time i receive queue error. it helps sometimes (some of mails reached the recipients) but as far as I can tell where isn't binary which works on my system (Debian4) and allow all mail.
i have opened ticket yesterday and hope that support resolve this problem. I will give you detailed report as soon as they will finish

 

[rodrigo@]

greylisting

Had the same error here. Plesk 9.2, CentOS.

I just disabled greylisting and it's working now. (Server > Spam filter settings)

Someone with greylisting enabled without problems?

Thanks

 

[htdnet]

Still having issues...

Well finally I found the correct forum for this. I'm still having this issue and have tried all of the suggestions except notify_classes = which would probably just allow me to forget this issue occurs... Cool thing is that all the notifications are obviously for invalid senders but only for 1 Domain of mine. It was for one particular user but then now two people on that domain are effected. Firgure that one out. I've applied the latest download from 6074 and still have issues. Seems to me like I have issues whenever I upgrade plesk and almost always have to pay one of their staff to come in and save the day. Luckily nothing has been serious or I'd be out of business.

Parallels do you have any further suggestions?

 

[htdnet]

Possible Fix?

http://www.experts-exchange.com/Net...lication_Protocols/Email/SMTP/Q_24376875.html
and maybe http://www.howtoforge.com/forums/showthread.php?t=72&highlight=relayhost
Other commands passed to the server: (Parallels?)

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
postconf -m
postconf -n
postmap /etc/postfix/access
/etc/init.d/postfix restart

Maybe someone else will have some luck like I have... I'll let you know if the messages continue

 

[htdnet]

Ut oh

Transcript of session follows.

Out: 220 FQDN ESMTP Postfix
In: HELO 221.215.169.102
Out: 250 FQDN
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

So the plot thickens... like I said before all these messages are from SPAMMERS which is half way cool I can only think the tool they are using is not talking with the server correctly and that is why it is not sending through or stopping after the queue file write error.... ALL GOOD mail seems to be going through ok. I tend to get these almost on the hour about 5-6 of them. Only effecting the one domain name and two e-mails associated to that domain. all other domains have NOT had this issue.

 

[htdnet]

Parallels can you work on this?

If you can not provide a solution can you at least tell me how to prevent Postfix SMTP server: errors from being sent out I receive 50 of these per day for emails that are described above. Seems like every time I have an update to my plesk server I get more and more problems that I need to contact you every time for assistance. Why should I pay $75 for you to come in and fix something that your upgrade broke or changed causing the problems? I also can not use SPF and DomainKeys or I get invalid messages popping up on sending and receiving with results as follows:
* = removed for privacy

domainkeys and or SPF cause the additional element into the mail message which does not allow it to be read properly:
L Õ· Õ·†ð-|èýë· <-- what causes this. Why can't DomainKeys work using Plesk Why promote a product that you have in production that does not work. Why does SPF fail and screw up my e-mails? Why should we pay $75 for you to fix things that you break?

-----Original Message-----
From: *VALID EMAIL*@yahoo.com [mailto:*VALID EMAIL*@yahoo.com]
Sent: Saturday, May 16, 2009 3:26 PM
To: undisclosed-recipients:
Subject:

L Õ· Õ·†ð-|èýë·
X-No-Auth: unauthenticated0 sender
X-No-Relay: not in my network
Received: from web34404.mail.mud.yahoo.com (unknown [66.163.178.153])
by *MYSERVER* (Postfix) with SMTP
for <*[email protected]>; Sat, 16 May 2009 19:25:35 +0000 (UTC)
Received: (qmail 82372 invoked by uid 60001); 16 May 2009 19:25:28 -0000
DKIM-Signature: *DKIM SIGNATURE*
s=s1024; d=yahoo.com;
h=Message-ID:X-YMail-OSG:Received:X-Mailerate:From:Subject:To:MIME-Version:Content-Type;
b=*DOMAIN KEY*
Message-ID: <*MESSAGE ID*>
X-YMail-OSG: *OSG*
Received: from [*MYIP*] by *.yahoo.com via HTTP; Sat, 16 May 2009 12:25:28 PDT
X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10
Date: Sat, 16 May 2009 12:25:28 -0700 (PDT)
From: *My Friend* <*VALID EMAIL*@yahoo.com>
Subject: Re: test
To: [email protected]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1755132689-1242501928=:82330"


--0-1755132689-1242501928=:82330
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

 

[tech01]

Fixed?

So here is what I did, I re-enabled SPF protection and ensured I had the proper settings:

I disabled domainkeys on ALL domains then enabled them again this cleared out the domainkeys and put the proper DNS settings in.

Then enabled SPF protection and ensured I had the proper settings:

SPF checking mode: Only create Received-SPF headers, never block
SPF local rules: v=spf1 ip4:IPADDRESS1 ip4:IPADDRESS2 a include:spf.trusted-forwarder.org -all
SPF guess rules: v=spf1 +a/24 +mx/24 +ptr ?all
SPF explanation text: whatever you want to put here.

I then allowed signing of outgoing mail for DomainKeys.

Then rebooted and so far so good been 2 days free of thoes pesky notifications above. hope this helps with any resolutions out there.

 

[tech01]

also

btw the autowhite listing seems to be working as well... so really all my problems have gone away except I want to enable domainkey checking but that seems to screw everything up in the past so I think I'll leave well enough alone.

 

[galaxy]

Problem Solved

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.

 

[lipek]

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