Robert Cohen wrote:
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.
I agree with Ralf's analysis.
IIRC sendmail truncates single headers longer than 32k;
postfix by default allows 1M per header.
You can tell postfix to truncate headers by setting:
# main.cf
header_size_limit = 30000
This may break signatures on DKIM/DomainKeys signed mail, but
will probably make your content filter happier.
--
Noel Jones
