When email is not delivered for 5 days, where in the heck is it hiding?

[104456]

If the documents are important and time sensitive you could set up some sort of passworded website or ftp server for people to up/down load documents to/from at set intervals.

[SpywareDr]

Maybe I'm reading it wrong but, to me the problem seems to be "omta09.mta.everyone.net":

Thu, 4 Oct 2007
Received by omta09.mta.everyone.net from dm25.mta.everyone.net

Tue, 9 Oct 2007
Received by bellsouth.net from omta09.mta.everyone.net

[Tuttle]

omta09.mta.everyone.net is where it got stuck, but it's hard to conclude from that where the fault lies. All you can really conclude is that omta09.mta.everyone.net couldn't reach bellsouth.net for 5 days, but you don't know whether that's because of a problem at one end or even with a transit provider in the middle. Someone would need to look at the logs on omta09.mta.everyone.net to work out more.

Unfortunately, email was never designed to be used for time-sensitive stuff; the main consideration in the protocol is reliability. If implemented as written, every message is either delivered to the recipient or returned to the sender as an error, eventually -- no guarantees on timeframe, except suggestions that servers should retry at most every 30 minutes and keep trying for at least 4-5 days. Of course, once you add spam filters that break the spec, all bets on the reliability are off too.

If stuff is time-sensitive, email alone is a bad solution. You need to back it up with something more interactive (phone call / IM) and have a backup plan if needed -- sometimes burning files to a CD and getting a courier will turn out faster.