- Top 10 Recession-Proof IT Jobs
- 7 Hot IT Jobs That Will Land You a Higher Salary
- Link Building Strategies and Tips for 2014
- Top 10 Accessories for Your iPad Air
Page 2 of 7
Our goal was to install, configure and test each of the products using the vendor-supplied documentation and other freely available web sources. We achieved successful installations and mail delivery with all the products tested, albeit not without some challenges. Two products, which we decided not to identify, performed so poorly or were so difficult to install or configure that we dropped them from the test altogether.
While the vendor documentation was adequate for the most part, it sometimes left out important details. None of the Linux products use a graphical user interface to install, and therefore require commands to be issued at a prompt. Fine for Linux admins, not so much for a Linux novice. The install for Zarafa did not succeed until we used a root account, which requires super user privileges that a casual tester may not have access to.
We did not perform stress tests, as sending out tens of thousands of emails more or less simultaneously tends to attract the wrong kind of attention and would most certainly lead to immediate grey listing followed by black listing and a peremptory end to the test.
We tested with numerous local email accounts (in the hundreds), using a variety of different email clients (POP, IMAIL, Web and mobile devices). We did not encounter any significant performance issues except the usual latency with the mobile satellite providers. On the other hand, great performance mostly over a local LAN under ideal conditions with no competing network traffic can't be compared to "real world" email delivery, so our best advice is to perform your own tests under conditions that more closely resemble your real network architecture.
Installation can be a challenge
The first question to ask if someone is touting the benefits of a particular email solution is "Have you installed it?" Open source products in particular are notorious for packaging elements of other open source products as building blocks and then presenting the bundled components as a complete solution.
While there isn't anything fundamentally wrong with this approach, installing these bundles can prove to be quite challenging. If the provided install file or process doesn't find the requisite dependencies or you accidentally use the wrong shell program or install packages in the wrong order, you may end up with nothing more to show for your efforts than jumbled bits and pieces of non-working code strewn around your server. Thankfully we maintained pre-mailserver-install images of our servers, which we freely admit were well-worn by the time all the tests were completed.
Which brings up the point that unless you pay for vendor support, a partially installed mail server is pretty much worthless. Without expertise in all the underlying technologies, the steps to troubleshoot a failed installation can range from difficult to impossible. We crashed one install by using the "wrong" version of a shell (not clarified by the vendor's own installation instructions) and another simply by supplying a MySQL root password too early in the process. You may be wondering, what's MySQL got to do with it, and that's exactly the point about dependencies - required third-party products may or may not be properly installed and configured, or might simply be the wrong versions of the correct product, which can still have a significant, usually negative, impact on the prospects of getting the solution up and running.