On Wed, Oct 01, 2008 at 07:07:36AM +0200, Ingo Juergensmann wrote: > On Tue, Sep 30, 2008 at 05:19:05PM -0500, Lance Tagliapietra wrote: > > > Looking closer, exim is run by a cron task periodically, to try to > > re-send email that could not be sent, or was queued for some reason. If > > the message could not be delivered, it sits in the queue. Due to a > > mis-configuration of exim, I had system messages to root sitting in > > there, all the mail to support popularity-contest, and others, for about > > 6 years! There were about 1000 files there to be processed, each time, > > which simply took time. > > [...] > > Note that all this time I was able to send email/ receive email and > > didn't really know about much system generated email. > > You could run exim -d -qff <msgid> to see why those mails in the queue are > failing. > > I suffered from a similar problem once and wrote a little Python script to > deal with this problem. It tries to flush the queue and depending on the > error code it gets back, it either tries to deliver the mail again, spool it > again or simply delete it. If it can't send mails for a certain amount of > time in the queue, it deletes the mail as well.
Actually, exim can do that itself. Just set 'timeout_frozen_after' to a sane value (say, '1 month' or some such), and exim will remove all frozen mails that it can't deal with after a while. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
