Hi everyone. I hope you all don't mind my keeping this thread alive... it could be considered off-topic, but since it deals with a specific product that is a direct "add-on" of sorts for iMail servers, it's seems relevant enough. If you're tired of it, just delete my message please.
I've been following this thread for some time now, and I think I can provide a relatively unbiased opinion, since I work neither for Sandy nor for Scott (Declude), nor for David Gregg (mxGuard). Dmitri, the "crux of the biscuit" -- the reason why the very nature of your product has fallen into question, lies with the very philosophy that has been followed to develop the product... a philosophy mirrored, overall, by a disturbing trend in software development nowadays. That trend is, "it's okay to live with preventable software failure". Or, "people/society should accept a product that's flawed, even when we could prevent it." While I have always tried to distance myself from the "Microsoft vs. Whomever" battlegrounds, I do tend to believe that Microsoft is the biggest offender when it comes to allowing this philosophy to develop full-bore and permeate the computing society as it has. In some ways, even with all the really cool things they've done, I honestly do feel that they've held back the computing world, compared to where we'd be had other technologies flourished as their has. Especially in the area of reliability -- which is what we're discussing here. It's a whole other battle, but applicable here observationally. Your software claims to do a certain task, but it does so with certain risks and abberant behavior (like pushing a lock error into the iMail logs). Risks that, as you should have discovered by now, nearly all of the professional mail administrators on this list consider unacceptable. Your product functions out-of-process. Period. It "prevents" delivery of risky messages, but NOT ALL THE TIME -- a situation exists, no matter how rare you think it is, where messages might not be processed on arrival. At the very least, you must accept this, and there should be a statement to that effect on the product's website, iMailZip.com. There is no such statement. Now, prevention of spam delivery is one thing; the user's world does not come to an end if a spam message slips by this "not-so-middleware". However, should a known (and preventable) virus slip through, simply because this software is by nature out-of-process, that Very Much affects the user's world - especially if it compromises their machine in any way whatsoever. And especially if they (or their mail server admin) has paid "the big bucks" to own this product (addressed below). But this product makes a decision for it's buyers -- that "this risk SHOULD be acceptable", and so then it becomes as such to those buyers. The user/admin is sold on the way this software works, only to discover later that their investment still could cost them much more when a known, scannable, preventable virus makes its way into an inbox of some poor soul who doesn't know any better than to click on the attachment. This is not a matter of allowing competing technologies to "live and let live" -- it's the difference between good software implementation and bad, and what is considered "acceptable" in the software industry as a whole. Both implementations work, but at some point the critical flaw in the bad implementation is going to rear its ugly head. If you are asking the admins on THIS list to "live and let live", you're barking up the wrong tree. Because not only does your software pose an unnecessary risk to the end user, it advocates the trend with which many of us are already well disgusted -- that "it's okay to live with preventable software failure". Nobody can claim to stop 100% of the viruses that are out now, or could be in the future. Nobody IS making that claim. But your "competitors" (read "superiors", in this person's view) CAN all claim that they scan 100% of the incoming messages, all of the time -- a verifiable, reasonable, technologically more-advanced concept than the imailzip product appears to posess (please correct me if I am wrong -- but so far, the flaws identified by other members of this list appear to be valid). Because the technology is available NOW to act upon 100% of the incoming messages in some way, allowing anything less with regards to such a critical topic as virus scannning is an absurd step backwards. Which highlights my position with regards to the Microsoft debate as well... technology has existed for a very long time, and is still available NOW, which allows an admin to set up a server and rarely if EVER have to reboot it, except for hardware replacements, occassional upgrades and the like. In other words, server implementations are available that are proven to do their job all the time, without "Locking Up" at all. Once, our company built a Novell server for a dental office that, at the time it was replaced, had not been rebooted in over THREE YEARS. I have yet to see a Microsoft server run quite that long... even the fine-tuned, well functioning ones. But people get sold on Microsoft, and they've been the winner for so long, so "they win", while we all lose a little bit each time. I'm sure they're trying to get better, but they are still not there yet. The shame is that stable implementations exist and could have been used by the computing industry as a whole for many years now, but we've had this one idea shoved down our throats so long, more and more people seem to be "okay with the idea" of having to reboot their server, reboot their workstation... whatever. We don't like it, and we grumble and occassionally curse out loud at Microsoft, but we "live with it" (or we start from scratch, cash-flow-be-damned, and read a bunch of stuff, become newbies all over again for a while, learn and then implement some other platform). In THIS case, with regards to the imailzip product, we see no point in "living with it" -- no point in accepting a so blatantly flawed implementation of a virus scanner for a mail server. Thus, you are being told so, and you don't like it. But you'll need to learn to "live with it", because like your implementation, and your opinion of it, our position is unlikely to change. We would much rather see, use, and recommend mature products that absolutely process EVERY incoming message without potential for otherwise. My final point is with regards to cost, compared to what we should be asked to "live with"... Per the website: ================================= One year anti-virus subscription: Users - Cost 1-25 - $195 26-250 - $795 251-1000 - $1995 Unlimited - $3495 For next and further years subscription 30% discount. ================================ Given it's flawed concept of scanning messages after they are already in the user's mailbox, I expected to see this product positioned almost as a client-side virus/spam scanner, for around $100. Instead, it is positioned even HIGHER than its competitors, which have a superior product. Certainly THAT does not justify the risk, when I can get a multiple-scanner-capable license of mxGuard, unlimited users, for $99 for our small-to-medium traffic servers -- a product which ABSOLUTELY addresses 100% of incoming messages... OR I can get a license of the very mature Declude for $800 to $1300 for our higher-traffic servers, which also addresses EVERY incoming message AND has other proven, reliable features as well... Both products beat the cost of the "unlimited" imailzip version by a wide margin. In closing, you may continue to defend this product all you want, I'd recommend that you not bother doing it here unless the fundamental flaws, highest of which is the fact that it could allow messages to slip by, are all addressed. > -----Original Message----- > From: Dmitri Elgin [mailto:[EMAIL PROTECTED] > Sent: Monday, March 22, 2004 2:23 AM > To: [EMAIL PROTECTED] > Subject: Re: Re[4]: [IMail Forum] Another Virus scanner > > > > > > I am not sure that any developer can provide such > functionality to > > > > check hundred of mails per minutes. > > > > > > Well, get sure. We have servers virus-checking a million > messages per > > > day (700/minute). You chose the least scalable scanning > mechanism and > > > (apparently) have never run any benchmarks that would > allow you to act > > > in good faith to your customers. You know, you could > say "it topped > > > out at 100,000 messages per day using the following > hardware" and seem > > > a heckuva lot more honest, and attractive for > that trait, than > > > pretending that no one can do it better. > > Sandy, i have never run any benchmarks with such insane > traffic, you right, > but > the companies different. How many clients with such > characteristic you have? > Apparently, you can count them by fingers. Most companies never plans > to have this network structure, even in near future. > > The only thing i want to say is - if you have a working > software, which > can bring the benefit to other people, so let them choose > what they like. > Your software have your advantages and i have mine. So let they live > together > by their different lives. My eyes tired to see ["some > software" the most > powerfull in the world!] > everywere. > > > > But what you _should_ be able to tell people is > "My software > > > guarantees that 100% of your e-mail will be scanned > using the latest > > > virus signatures available to the scanning engine. If > it cannot be > > > scanned, the e-mail may or may not be made available for > delivery, at > > > the admin's discretion." > > > > > > Unfortunately, you can't make the latter guarantee > because yours is > > > not a true server-integrated anti-virus product: you > can't be fully > > > aware if scanning errors have occurred because your > actions occur > > > outside of the SMTP process flow. > > > > > > --Sandy > > Sure, i can't. But i can do some other things better ;) > > > 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/ 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/
