On Thu, 2007-05-03 at 11:18 -0700, Eric Goforth wrote:
> Here are my relative entries in exim.conf:
>
> ignore_bounce_errors_after = 6h
> timeout_frozen_after = 1w
OK, so you're saying: messages that get frozen stay that way for 1 week
(there are multiple reasons for freezing) and then get removed. Bounce
errors go away after 6 hours (they are only one type of frozen message).
> Looking back through the logs, this error has been happening for 3
> weeks, on each queue run.
>
> Here is the result of 'mailq' (obviously bounces to spammers):
>
> 5h 1.8K 1Hjaq7-000282-0p <> *** frozen ***
> jthomsonex@???
>
> 3h 3.0K 1Hjcxe-0004xQ-MZ <> *** frozen ***
> fyi9ues@???
>
> 3h 3.1K 1HjdAA-0005Hf-V4 <> *** frozen ***
> ulsk09harxe@???
>
> 8m 3.0K 1Hjfik-0000CS-MN <> *** frozen ***
> 4436stocknews@???
OK, so you have some frozen messages on the queue.
> Here is the result of "exim -Mrm 1HiwzY-0002VD-GI"
>
> Spool data file for 1HiwzY-0002VD-GI does not exist
> Continuing, to ensure all files removed
> Spool read error for 1HiwzY-0002VD-GI-H: No such file or
> directory
> Continuing to ensure all files removed
> Message 1HiwzY-0002VD-GI has been removed or did not exist
But that specific message ID is *not* in the queue and had already been
removed!
> And the entries as of 4 minutes ago in the log:
>
> 2007-05-03 11:18:45 1HjfsW-0000N4-GS == 4108047190@???
> R=relay defer (-1): host lookup did not complete
> 2007-05-03 11:18:45 1HjfsW-0000N4-GS ** 4108047190@???:
> retry timeout exceeded
> 2007-05-03 11:18:45 1HjfsW-0000N4-GS 4108047190@???: error
> ignored
So yet another one timed out and went away. This is intentional, and
desirable, behaviour - otherwise your queues clog with frozen messages;
many thousands of them would see your queue runner incur an unacceptable
overhead as it parsed the header and retry DB on each queue run.
> I suspect that this is a shadow message (probably not the correct term)
> from when I manually flushed my exim resolve cache while troubleshooting
> an unrelated issue. It started about that timeframe.
You have a separate problem, in my opinion: *how* are the bounce
messages getting into your queue in the first place? Are you using
MailScanner or Amavis or some similar router&transport based AV/AS
system? Are you acting as backup MX for another domain?
Under normal operation you should not experience them - they are
anomalies. The fact that your ignore_bounce_errors_after is set to 6h
may actually hinder you here, since the messages will go off your queue
before you get a chance to analyse their origin.
Consider raising it to 24h for a short period, and see what you can find
out with judicious use of "exim -Mvb <message_id>" - the bounce message
should contain enough details for you to trawl your logs.
Graeme
