Am having a problem with Exim seg faulting here. One of our main relays
has some messages stuck in the queue for over two months now and crashes
every time trying to deliver them. I remember seeing something about
this on this list earlier this year but a quick search of the archive
didn't couldn't find much. Have tried running "exim -d XX -M <ID>" on a
few of the messages and they appear to crash in different places (no
core dumps being created).
This doesn't concern me too much - I expect a few messages to have garbage
addresses and thus cause problems for most MTAs. While it would be nice
to fix this, it's not main problem. The real problem is that these
messages are not bouncing once they've passed the retry cutoff time
(retry times are from the default config). From looking through the docs,
delay_after_cutoff appears to be about the only option controlling this
but it doesn't make a difference (didn't expect it too either). This is
probably because the delivery crashes out before anything gets written
to retry.db.
Has anyone else out there had similar problems and if so, what's the best
work around? An option to bounce all mail that's been in the queue for
Y days or more would be nice but probably won't happen so I'm looking for
the best possible work around. This box is our main spam filter and often
handles somewhere in the region of 15K - 16K messages per day. Apart from
these message permanently stuck in the queue, it has no other problems.
I'd appreciate hearing if anyone has successfully worked around this problem.
Thanks,
Dave
--
*** Exim information can be found at
http://www.exim.org/ ***
