* Robert Cohen <[EMAIL PROTECTED]>: > We recently started getting periods where postfix > would just spin its wheels for a while spitting out a stream of errors like > > ul 27 12:43:23 mailin2 postfix/smtp[29137]: 4CBB07E8009: > to=<[EMAIL PROTECTED]>, relay=127.0.0.1[127.0.0.1]:10025, delay=137638, > delays=137638/0/0/0, dsn=4.4.2, status=deferred (lost connection with > 127.0.0.1[127.0.0.1] while sending message body) > > > continuously for about 15 minutes before the smtpd got killed and restarted.
It's smtp, not smtpd. Has it occured to you that the content_filter on 127.0.0.1 may be the problem? > Essentially it was unable to send any emails to the content filter during > this period. Yes, because the content_filter "hangs up". > Killing/restarting the content filter had no effect. But killing/restarting > postfix fixed it which implies its postfix's problem. No. Postfix backs off form a dead destination (the content_filter) > We eventually tracked it down to a particular set of messages in the > deferred queue. Yes, I know that form broken content_filters. The message triggers an error in the content_filter, which fucks up, and then the message is deferred. I've seen that many times with amavisd-new and TrendMicro VirusWall. > Whenever it tried to process them, it would develop this problem, Of course. > When we cleared those messages, the problem disappeared. Of course. > The only obvious issue with the particular messages is that the headers are > gigantic. About 400k of headers which leads me to believe its a buffer > overflow. In the content_filter, for sure. Which content_filter do you use? -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de llama would be a more fitting name for OpenLDAP: It's big, stubborn and spits in your face when you need it the most.
