Re: [Exim] domain in relay_domains, exim being best mx, now …

Top Pagina
Delete this message
Reply to this message
Auteur: Philip Hazel
Datum:  
Aan: Tamas TEVESZ
CC: exim-users
Onderwerp: Re: [Exim] domain in relay_domains, exim being best mx, now what ?
On Thu, 8 Nov 2001, Tamas TEVESZ wrote:

> to be more specific, one of the nodes connected to the hub is down for
> some time now, and mails are being queued on the hub (as expected).
> however, i see no retry data for this domain (or any domain, to be
> precise).


Do you mean that exim_dumpdb for the retry database outputs nothing?
If so, check that there are files in spool/db of non-zero length.
Try a queue-run delivery with debugging to see if that gives any clue.
You can make it try just a single message with

exim -d9 -q <message-id> <same-message-id>

(The two ids are the start/stop messages.)

> now that i'm writing, i remember a number of cases, when i
> saw a couple of mails (to other domains, same mail hub) sitting on the
> queue for a while, and a queue run delivered them fine - there might
> have been a temprary failure, but those messages had never been
> retried.


Er, the queue run IS the retry. Perhaps that's what you are not quite
understanding?

> can this be the case ? what happens to the momentarily-undeliverable
> messages ? how are the retry rules apply (in general in that
> situation) ?


I have recently realized that the manual isn't too clear about this. I
will try to improve it for Exim 4.

. When a message arrives it gets put on the queue.

. Depending on the configuration and circumstances, a delivery process
for that message may be started immediately.

. If not, or if the delivery hits a temporary error, the message remains
on the queue.

. It will now only be delivered when a queue runner finds it (apart from
manual prods with -M, of course).

. When a delivery process works on a message, it tries only those
addresses that are past their retry time. Chapter 33 explains the
retry rules, and section 48.2 explains the different kinds of error
that outgoing SMTP may encounter.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.