Hi, two weeks ago I've subscribed to a service that sends an e-mail atNothing will be lost, they'll be resent. The SMTP protocol is designed to handle breaks in communication between the sender and the receiver. If a SMTP connection is lost in the middle of a transaction, the sender is required by the RFC to requeue the mail to be sent later. Now if the service does not resend a message that fails to complete then you have to talk to them about their bug in their service.2 a.m. The default exit / restart also happens to be at 2 a.m. It
turns out that when exit / restart happens it doesn't wait for
everything to be idle, but instead just does its thing, and anything in
progress will be lost. I know that since I have POPFile and all the
service e-mails got as far as POPFile, but not into Mercury. I've now
moved the reload time to 2:15 and they're now progressing all the way
to the client. But what might be lost at 2:15?
<blockquote>Hi, two weeks ago I've subscribed to a service that sends an e-mail at
2 a.m.&nbsp;&nbsp; The default exit / restart also happens to be at 2 a.m.&nbsp; It
turns out that when exit / restart happens it doesn't wait for
everything to be idle, but instead just does its thing, and anything in
progress will be lost.&nbsp; I know that since I have POPFile and all the
service e-mails got as far as POPFile, but not into Mercury.&nbsp; I've now
moved the reload time to 2:15 and they're now progressing all the way
to the client.&nbsp; But what might be lost at 2:15?</blockquote>Nothing will be lost, they'll be resent.&nbsp; The SMTP protocol is designed to handle breaks in communication between the sender and the receiver. &nbsp; If a SMTP connection is lost in the middle of a transaction, the sender is required by the RFC to requeue the mail to be sent later.&nbsp; Now if the service does not resend a message&nbsp; that fails to complete then you have to talk to them about their bug in their service.