Russell Stuart wrote:
> On Thu, 2005-02-10 at 00:10, Tom Kistner wrote:
>
>>You forgot to ask a question ... :)
>>
>>You are passing messages to the AV scanner by LMTP, and you think there
>>is a bug in exims LMTP transport?
>
>
> The email wasn't asking a question. It was making a statement.
> The statement was in the subject: "Bug in exim". In other words
> I believe there is a bug in exim. In the body of the email I
> tried to explain why I think the statement was true.
>
> As for whether the bug is in exim's LMTP transport: I don't know.
> I am convinced there is a bug in exim, but beyond that I can not
> say. I am going to look at the source today, perhaps I will know
> more after I have done that.
>
> Just by the by, the bug is causing me a lot of grief. The
> organisation has some 200 people in it. It seems most of them
> have taken the time to express their feelings to me about
> loosing email - from the CEO down.
>
'Been there" w/r the 'management attntion', and don't mean to sound
negative, but IMHO, the 'bug', as you decribed it the situation, appears
to be external to Exim.
Unless I have misunderstood, you need to look deeper at the rest of the
environment:
First a 'side note' - your exim config is unusual and complex.
That doesn't mean 'wrong', but it does mean it deserves detailed review.
I have not done such.
Second: - you said this had happened to: "...recipients that didn't
receive an email sent via exim."
*sent* is not always the most specific of terms when applied to an MTA.
Because you stress LMTP, and the config seems geared to specialized
internal mail handling, I will presume, unless corrected, that you refer
to messages generated in one part of the organization and destined for
other parts of the organization, NOT traffic (in either direction) with
the outside world.
Third: - You point out:
"All the messages that were lost got an LMTP 4.x.x error
while they were being passed to the virus scanner. All
the messages bar that got an LMTP 4.x.x error, bar one,
had a recipient dropped. A couple had more than one
recipient dropped."
"Although the source of the LMTP error is probably not
relevant, it is caused by some issue with the Kaspersky
anti virus scanner we are using."
- so far, so good.
Fourth: - You observe:
"It had been working well, but at about the end of January
Kaspersky released major update, which according to the their
representatives
here in Australia overloaded their virus pattern update
servers. Thereafter the update server has been slow
and unreliable. During the update process the anti
virus daemon is disabled, and this is the source of the
LMTP errors. What has changed is that because of the
issues Kaspersky is having, daemon is being disabled
far more often than it was before."
- also on point.
Fifth: You call this a bug in *Exim* ..... ???
That fifth part simply does not compute. Doesn't match what you have
laid out.
To the extent Exim is configured to hand-off traffic to a scanner,
*attempts* to do so, *believes it has done so* - it would take a great
deal more code than Exim carries, or you than have added, to say to Exim:
"oh, and by by way, find SOME DAMN WAY to deliver this message even
if/as/when known-problematical Kaspersky is not where it is expected to
be, not doing what is expected of it, and/or is Cluster-Fscked 40,000
CPU-cycles down the timeline, and has neither means nor inclination to
tell you so."
So I don't see that as an 'Exim bug' in any way, shape, or form.
Kaspersky, probably. Fallback/alternative/work-around configuration (or
lack thereof) also.
But 'Exim bug'? How so?
Exim is an MTA, not a whole OS or some omniscient being.
Bill Hacker
