On Tue, 17 Dec 2002, Tim Jackson wrote:
> I've looked into the logs/db, and AFAICT, the host in question has been
> down since 1 December. Therefore, if I understand it correctly, all
> messages received after ~6 December should have been bounced immediately
> or fairly soon (next queue run) after, assuming the host didn't come back
> in the meantime?
Yes, except that if the retry data is old enough (default 1 week), Exim
ignores it. It is equivalent to the host being assumed to have "come
back" one week after it was last tried. (Otherwise, when there are very
few messages, you can get bad effects.)
> I did this (very handy debugging, BTW!),
Thanks.
> Interestingly, the first failed timestamp is 14:20 on 16 December, so does
> that suggest that the host has in fact been up recently? Or just that all
> the retry data was "expunged"/ignored before then, and that was the first
> retry after that?
Either of those.
> "Last" as in the righthand-most part of the retry rule? (in this case
> F,4d,6h)? So, if I get this right, if Exim decides a host is "dead" (the
> last cutoff is exceeded), and there are messages in the queue for that
> host at a later time, Exim will retry at 4 hour intervals (irrelevant of
> how many messages have arrived in the intervening period, assuming
> delay_after_cutoff is true)?
Yes, sort of. Until 4 hours have passed since the last retry, messages
should be bounced immediately. If a message arrives after 4 hours have
passed, Exim will try to deliver, but bounce if there's a failure. The 4
hours then starts again. However, if nothing happens for a week, the
retry data is completely forgotten.
> Anyway, this is making my brain hurt now. I'm still not sure I understand
> 100% what's happening, but by and large things do seem to be moving in and
> out of the queue, getting bounced etc. *broadly* as I would expect. I
> think there may be some complicating factors I don't know about here, like
> the host being intermittently accessible (as opposed to totally down,
> which was my understanding),
Yes, that is the situation that causes the most hassle, both to the code
and to one's brain.
> Thanks for the help (and for the truly awesome software, which does pretty
> much everything I want, although a 'MAIL' ACL would be nice so my vote's
> on that wishlist item), and I'll let you know if I have any more insights!
There is a MAIL ACL in the new release, recently out.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
