On 13/8/08 5:13 PM, "Ralf Hildebrandt" <[EMAIL PROTECTED]> wrote:
>
> 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?
That is with the policy milter that ships with sophos puremessage.
Its been reported to sophos, so if it is the milter, then they will
doubtless provide a patch.
I assumed it wasn't the milter because restarting postfix even without
restarting the milter fixed the problem, I'm pretty sure.
And the problem didn't occur with sendmail with the same milter. But its
always possible that sendmail communicates differently.
=======================================
Robert Cohen
Systems & Desktop Services
Division of Information
R.G Menzies Building
Building 2
The Australian National University
Canberra ACT 0200 Australia
T: +61 2 6125 8389
F: +61 2 6125 7699
http://www.anu.edu.au
CRICOS Provider #00120C
=======================================
