Philip Hazel <ph10@???> wrote:
>On Tue, 17 Dec 2002, Miquel van Smoorenburg wrote:
>> However, mail to a certain domain (eos.ncsu.edu) stays stuck in the
>> queue for basically forever:
>Is there any useful information in the Exim log about those messages?
I've turned logging back to default (had it at 4 so that all those
'retry time not reached' messages don't fill the disk, this is
the outgoing SMTP server for our clients) and it says for example:
2002-12-17 14:05:09 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
2002-12-17 14:22:20 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
2002-12-17 14:23:23 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
2002-12-17 14:46:24 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
2002-12-17 14:48:11 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
2002-12-17 14:53:56 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
2002-12-17 15:09:28 18Kiq4-0006UQ-00 == cwu4@??? routing defer (-42): retry time not reached
(messages are produced by running an 'exim -q' queue runner)
However retry time is certainly reached:
# mailq
10d 3.5K 18Kiq4-0006UQ-00 <freeradius-users-admin@???>
cwu4@???
# exinext cwu4@???
Deliver: cwu4@??? 0 77 SMTP error from remote mailer after RCPT TO [<cwu4@???>:] error host: [152.1.
first failed: 05-Dec-2002 21:18:16
last tried: 17-Dec-2002 14:03:27
next try at: 17-Dec-2002 22:03:27
past final cutoff time
>> The question is, why is the queue runner not doing this? I have
>> exim running as '/usr/sbin/exim -bd -q30m'.
>
>Good question. Next time this happens, it may be worth trying a forced
>"queue run" style delivery, either using -Mc instead of -M or using -q
>with start and stop message ids (in this case, the same id), and
>debugging turned on (-d9 for Exim 3).
Did that, and in that case the message is processed right away,
delivery fails, and the message is bounced & removed from the queue.
So basically when the entry is processed by 'exim -<options> <message-id>'
it does work, and when it is processed by 'exim -q' it doesn't
>However, note that Exim 3 is obsolescent now; I haven't time to chase up
>anything other than really serious bugs (and I hope there aren't any of
>them!).
I understand, but we're running Debian and prefer to use the standard
package where possible to make it easier to follow security updates.
The main mailserver is running exim 4.10 though (rolled the .deb
in-house).
Mike.
--
They all laughed when I said I wanted to build a joke-telling machine.
Well, I showed them! Nobody's laughing *now*! -- acesteves@???
