For years, Imail's raison d'�tre was their simple 10-minute install that would simply work out of the box with minimal effort.
People here have correctly noted that if you try to blindly piggyback webmail onto an existing and already configured webserver, the Imail install risks accidentally hosing existing sites with potential catastrophic results. So how many ways are there to prevent that and still guarantee that webmail will work out of the box? An open-source-based webserver for Imail's exclusive use could and should be maintained primarily by regular Ipswitch patches and upgrades. Hypothetical: If a vulnerability is announced in Apache or PHP, Ipswitch should quickly release a patch for its webserver. If they don't, users know that Ipswitch has reverted back to its bad old ways. And users would STILL be able to update the vulnerable code. It keeps Ipswitch honest and responsive, and protects users against egregious unpatched security vulnerabilities. Sounds like a win/win to me. It's a darn sight better than what they have now--ancient obsolete code with unknown vulnerabilities, and no way for customers to do anything about it. We'll have to see what Ipswitch decides. Regardless of the direction they decide to pursue, I'm heartened that Ipswitch is at least asking the question and soliciting our feedback FIRST. It seems to me they have learned the important lesson from the ICS debacle. :-) Dev Monday, April 25, 2005, 11:46:33 AM, you wrote: M> Dev wrote: >>Ipswitch installer could setup a customized >>pre-configured open-source webserver INSIDE the IMAIL >>installation directory. This config would have no >>effect on any existing webserver installations. (Other >>than to make sure they are not listening on the same >>port.) >> M> It's thinking like this that got us to where we are now. M> Matt 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/
