I'm happy to report James already does this (and actually has been doing it since day 1). When messages are received via SMTP, James does not send a 250 Message received until it is written to disk. Then as it is processed, the message is not removed from the spool until it is successfully processed. Pretty much no matter when you kill James, it shuld never lose a message and in certain cases duplicate a message if a processing was interrupted half way through. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/
Jeff Keyser wrote: > I would like to make a suggestion that I feel would make James a little more > robust. (I would offer to make the change myself, but I'm not familiar > enough with the code to do this.) > > Here is the potential situation: James receives an e-mail, and responds to > the sender that it has been received. James then begins to process this new > e-mail, but something happens before it's done - either the computer > crashes, James crashes, or whatever. This e-mail is lost, because the only > copy of it was in memory. > > What I would suggest is that James write the e-mail to a store while it is > receiving it, before it sends the final response to the sender. James could > then use this store as its incoming e-mail queue, and remove e-mail from it > after they have been processed. If the computer crashes before the e-mail > is written to the store, the sender never gets a final response, and > (theoretically) holds the e-mail to try again later. If it crashes > afterwards but before processing is done, James rereads the e-mail from the > incoming queue when it restarts, and starts the processing again. > > Anyway, it's just a suggestion. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
