On 21/03/2004 at 01:11:46, Dmitri Elgin wrote: >> "And if the ImailZip service stops for some reason, >> infected mail will be silently delivered intact instead of being held in >> the queue until the problem is fixed."
> - by default "yes", but the service restart automatically each 15 sec if it is > failed. How can you guarantee that the service will be restarted? By another process which is also subject to failure? What if your service dies almost immediately once it's loaded? It might be getting restarted every 15 seconds, but if it's only lasting 5 seconds that's still 66% of the time the server is unprotected. > If you talk about 100 and more messages this is not a good practice to collect it > all in queue Last week I managed to break our Declude installation (by dropping an incomplete download of declude.exe in the IMail directory). The queue backed up over 300 messages in the hour before my users complained about not receiving email and I fixed it, at which point those messages were steadily processed and delivered. If I'd broken ImailZip in the same way, the failure would have been effectively silent, and I wouldn't have noticed until the desktop virus scanners started going off. >> "analysing incoming messages through the normal hook (like Declude and >> mxGuard). There has to be - nobody would even dream of such inefficient" > - all product do the same job by absolutely different ways, so the end user may > expect > more quality new advantages, (indivisual box scanning, compressing etc) ;) Except the Declude/mxGuard way guarantees that all mail will be processed, because IMail calls the add-in before making the message available for download. Your way creates a race condition that potentially allows unfiltered mail through -- it's possible for the following sequence of events to occur, and you cannot prevent it: - User initiates POP3 check of mailbox - SMTP process delivers message to .mbx file - ImailZip process notices change in .mbx file - POP3 process locks .mbx file and user downloads message - POP3 process unlocks .mbx file - ImailZip process locks and scans now-empty .mbx file You cannot eliminate that possibility, because once the SMTP process unlocks the .mbx file it's available to whichever other process grabs it first. Most of the time that'll be ImailZip, but it can't be guaranteed. Cheers, Evan To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
