Just a quick question before I look into this further...
Our aging main mailstore machine has been struggling recently so we are
keen to keep the queue as small as possible. In looking closely at the
queue (I know we should have been doing this anyway!) it seems that while
most crap is being timed out and bounced according to the retry rules
there are a number of messages stuck there seemingly forever.
The common thing with the ones that are stuck on the queue appears to be
that the user has no home directory.
Email is delivered to $HOME/.mail - when a user is suspended for some
reason their homedir is moved. This seems to be the only thing in common
with the stuck emails.
exinext shows that the next retry will be in a few hours even though they
should have timed out days (weeks) ago.
exim -M msgID causes:
2004-02-11 10:15:15 1AmG3y-0006bQ-Ed == *****@pelican.ukc.ac.uk R=userforward defer (-1): failed to st at /home/*****/. (No such file or directory)
(login name changed to protect the possibly not-very-innocent :-))
followed by:
2004-02-11 10:15:15 1AmG3y-0006bQ-Ed ** *****@pelican.ukc.ac.uk: retry timeout exceeded
and then a bounce. Question is, why is this not happening in the normal
process of queue runners? Why do we have to poke each of the messages to
get it to notice that they should have been bounced 15 days ago?
userforward router looks like:
---------------
userforward:
driver = redirect
allow_filter
check_ancestor
check_local_user
file = $home/.forward
file_transport = address_file
reply_transport = address_reply
no_verify
---------------
the only retry rule is (appears to be working for every other error):
* * F,2h,15m; G,16h,2h,1.5; F,4d,8h
Exim version 4.22.
I'm pretty certain this was not a problem with v3.x - the config was
converted using the script supplied and to be honest has not been
tweaked as much as we probably should have done. Are we missing something??
Darren
PS: exim -qf has been run this morning and has now cleared out the q...
