After getting the mail transport operational, i've done quite a bit of
reading (man page & faqs) on ways to resurrect any "lost" INCOMING items
during downtime, i've done a ./exim -bp and run some -M on a few messages.
The queue displayed doesn't seem to cover what I know to be a much higher
volume of expected incoming mail though. Is there a spool of "lost"
incoming messages in an Exim directory that can be "unzipped" and "let fly"
in much the same way "thawed" applies to the queue?
I figure the queue is "it" after digesting the entire man page & the
contents of
http://tux.creighton.edu/exim/spec_5.html#SEC37 .
But does this apply to "incoming" mail? If so, then maybe the missing data
lies elsewhere in the architecture i've inherited admin over. Shows what
pitfalls a box that hasn't been rebooted in a long time can contain for a
new admin. Thanks to Suresh re: running exim via init.d instead of via
inetd.conf, and thanks to the list for help thus far :)
We use Exim to process bids on translation jobs worldwide, ran flawlessly
for 600+ days of high volume till *someone changed stuff* :0
