Re: [Exim] Message: "result of an earlier callout reused"

Pàgina inicial
Delete this message
Reply to this message
Autor: Bill Moseley
Data:  
A: Exim users list
Assumpte: Re: [Exim] Message: "result of an earlier callout reused"
On Tue, Jul 27, 2004 at 12:34:18PM +0100, Alan J. Flavell wrote:
>
> I now worked out that the bug I was dimly remembering was in 4.31,
> fixed in 4.32.


Which bug was that? I'm running 4.34.

> Hmmm, we've got just one example of that symptom, in all the last ~ 10
> weeks of archived logs. It wasn't apache.org, though.


You likely have much greater volume than in my logs, but it seems like
every 503 error is a result of a verify fail to apache.org. I'll ask
them about it.

> and here's the related callout cache entry for the domain:
>
> 01-Jul-2004 12:30:49 geography.net callout=reject postmaster=unknown random=unknown
>                                    ^^^^^^^^^^^^^^

>
> Sounds as if that could fit the symptoms which you described, no?


Yes, BUT I don't seem to have a cache entry for the domain, though.
That's the weird part. On July 30 I received another "ezmlm warning"
for six messages that bounced. Unfortunately, the message only
includes the bound from the oldest message, which was on July 18.

But, again, I have no cache entry for apache.org.

So what does that mean? Does it mean that I *did* have a reject cache
entry back on July 18th but it is now gone? Or is it truly a bug in
Exim that's causing it to report a failure due to the cache yet
there's not cache entry.


> > I.e. I'm not seeing the original SMTP logging of the callout failure
>
> I could believe that.


Ok, so see the next comment...

> > even though Exim is reporting "result of an earlier callout reused".
>
> But this leaves the question, where did it get the earlier result
> from, if not from the callout cache database?


So it sounds like we both suspect Exim is reporting a failure based
from an earlier callout that doesn't exist.

What's the next step for figuring this out?

I'll see what logs apache.org can find.

--
Bill Moseley
moseley@???