PrologueI am an IT professional working for a large international IT integrator in Switzerland. As lots of other IT pros, I have quite an impressive home environment, including a full Active Directory, and I am hosting my own email domain and web site on a Linux box. I don’t like having my emails stored at an ISP’s datacenter. Not that I would have to hide something but you know, we ITs suffer from some kind of a security paranoia :-)
For years, I have used a combination of Sendmail and Open WebMail to manage my email communication. Emails were received by Sendmail and stored as standard Linux mbox emails. Open WebMail installed under my Apache was used to get Web-Access to my emails. This has been working fine and OpenWebmail is one of the best standalone Webmail GUIs I have seen so far. It has a lot of features including, calendar, webdisk etc. I was happy with it.
Why did you change, you may wonder? There were two main reasons:
- As an IT pro, I have the tendency to always use leading edge technology which means that I very often reinstall my Linux system when a new version hits the road.
- During the last years, the development by the OpenWebmail community slowed down to near still stand due to some personnel changes. I mean, if there is no official release for more than 18 months, I consider a project dead; even if there is still forum activity.
I have highly scripted backing up/saving configuration data and I use different partitions to separate OS data from user data such as Apache web-roots, MySQL DBs, Photo Gallery etc. I use rebind mounts (mount --bind ….) to easily link my data into the system.
So when I reinstall my Linux system with a new distribution (I use Fedora; currently FC7) I only reformat the partitions not containing data (/, /boot, /tmp, swap). After the system is up and running, a special restore script allows me to bring back most configuration data into the fresh installation and installs most applications from a repository, or directly by issuing yum statements.
Due to all the tests, especially with Open WebMail, it takes another two to three hours until I can say the system is running stable. And I was always happy to find that the latest official release of Open WebMail, dated May 2006, was still running on the newest Fedora release.
Due to uncertainty of the Open WebMail project and the amount of time it takes to post-configure Sendmail & Open WebMail, I decided it was time to move away from this configuration towards a more professional messaging solution. The primary driver had no costs, so I was willing to spend a limited amount of money for a good solution if I could not find a satisfying product in the OpenSource scene.
The following criteria were important for me. The product:
- must be easy to install without having to build from scratch. (no configure, make, make install games please);
- must seamlessly install on my current system without conflicting with existing components such as MySQL, Apache, LDAP, etc. as I need these services for other purposes (my website, photo gallery etc);
- must have a future (meaning commitment and ongoing development);
- must have a strong community or in case of a commercial product a good support channel and/or forum;
- must be easy to administer through a WebAdmin-Interface;
- must provide a professional WebMail-Interface;
- must provide POP3/IMAP4 access to mailboxes;
- should provide easy Backup/Restore facility of email & configuration data;
- must support multiple email domains (as I own two domains);
- must provide Mail-Relaying by DNS (MX record) and through an ISPs Smarthost. This must be configurable per domain;
- must support forward email addresses to external email recipients.
So I started Googling the Internet and quickly came across the "top dogs" in OpenSource messaging. These were: Scalix, Zimbra, Open-Xchange, TeamXchange, eGroupware etc.
First thing I had to learn is that most "providers" of these solutions interpret the word OpenSource in a different way. Most of them have a commercial product line with enhanced features or less/no limitations. Beside the commercial product, they all have what they call a "Community Version"; licensed under GPL. So far so good, but if you have a closer look at the comparison chart of their product lines (if one exists) you can quickly see that in most cases the "Community Version" lacks a lot of features compared with the commercial ones. The range of differences goes from minor limitations (number of mailboxes, groupware features etc.) to major ones, such as the total absence of the administrative Web-GUI or graphical installer found in the commercial version.
Some of the commercial products really made a good impression, but checking out the "Community Version" unveiled that the latter had been stripped down to an unusable cripple product.
Without telling some names, there was a product where the community version had to be downloaded as TAR-ball or from SVN repository and built from scratch. The README containing the installation instructions was around 5 A4 pages with compiling instructions and depending products which need to be installed first!
Another product was built on famous OpenSource products, such as MySQL, OpenLDAP, Apache, Tomcat etc., but pre-installation instructions mentioned from the start that the system could not coexist with services coming with the Linux distribution; current distribution versions were to be uninstalled and replaced with the product’s own compatible versions.
(!!!) HEY! I need my Apache and MySQL (!!!)
Even I am an IT pro I must say: NO! Not with me.
It seems to me that a lot of companies offer an OpenSource version of their product just because somebody told their sales department that it would be a good idea to have an OpenSource version as wells. "It’s trendy. But please, strip it down in a way that some essential features everyone needs are limited or missing and sooner or later the potential customer will jump on the commercial version." That is not my understanding of OpenSource!
A new Star
After testing the most promising candidates inside a RedHat Fedora virtual machine (VMWare), I came to the conclusion that all of them were useless because of the above mentioned reasons.
Frustration was big and for some weeks or even months I did not touch the topic. Then again I started Googling and, by accident, I came across AXIGEN.
I read through their online product description and within 10 minutes it was clear to me that AXIGEN was different. This product had a lot of advantages over the previous solutions, such as:
- The product is built on their own and very compact Core-Engine instead of a patchwork of existing OpenSource components;
- Installation seems to be super-easy;
- WebAdmin/WebMail interfaces existed;
- POP3/IMAP4 existed;
- Screenshots looked promising ☺ .
There were a lot of other points on the list which made my brain kick in. The only thing which was not covered: their "Community Version" did not support two email domains. For this, I would have to buy the Business Version. But this was not a killer criterion as the price for the Business Version (including 25 mailboxes/domains) is reasonable and the license is perpetual.
So I downloaded the product to my Fedora test system, extracted the GZIP file, typed
rpm -ivh axigen-4.0.1.gcc4-1.i386.rpm
and hit the ENTER key. 30 Seconds later, the product was installed and back on the command prompt telling me how to start the installation wizard. I did so and a nice text-based installer appeared immediately, asking me some basic questions about passwords, my primary email domain name, the services I wanted to use (pop, imap, webmail, webadmin) and their corresponding ports (25, 143, 8000, 9000).
I entered the requested information and accepted the defaults for most questions. After 2 minutes, I had already completed the wizard and was told that the AXIGEN Mail Server was running.
This can’t be true, I thought. From download, through installation to a fully ready mail server in 5 minutes! No error messages, no dependencies, just a straight forward installation.
I was in deep shock!
I launched a browser on my Windows system and typed:
BANG! There it was the login of the Web-Administration interface. WOW!
I started browsing through the screens and found it rather easy and straight forward for somebody familiar with configuring email related services.
So I decided to go for an in-depth evaluation of AXIGEN Mail Server as I would do it with a commercial product at my companies place. I did re-setup the system on my production email server and assigned the AXIGEN sendmail service port 2525 instead of 25 (SMTP). This way, my current Sendmail/Open WebMail solution could easily co-exist with my AXIGEN evaluation setup without interfering with each other. I set up a small test plan which summarized the coverage of the following areas:
- Core Engine: Domain/User Management, Sending/Receiving Emails, Forwarders;
- Relaying: by DNS (MX lookup), through ISP (Smarthost);
- WebMail/WebAdmin: Interface usability;
- Email Clients: POP3/IMAP4 clients (Outlook Express, MS Outlook 2003, Mozilla Thunderbird) & Microsoft Outlook Connector;
- Data Migration: Mail data migration from OpenWebmail to AXIGEN Mail server;
- AntiVirus/AntiSpam integration.
My ISP assigns me up to 4 dynamic IP addresses. To register Dynamic DNS (DDNS) records at www.no-ip.com, I use their dynamic update client running directly on my firewall. This way I always have a valid MX record for my domain.
mylastname.com MX preference = 5, mail exchanger = mail.mylastname.com mail.mylastname.com internet address = aaa.bbb.ccc.ddd
mail.mylastname.com is an A-record to the currently active DHCP address (aaa.bbb.ccc.ddd) on the public side of my firewall. The firewall listens on port 25 (SMTP) and the port forwards it to my Linux system at 192.168.1.3. This way, the AXIGEN server is running totally in private address space.
Domain Setup & Test
As mentioned earlier, I own two domains. One of them is very special as it matches my family name (lastname). So let’s call this domain mylastname.com for further reference. These domains are nice as they offer you some fancy email address combinations such as: firstname.lastname@example.org
So I tried to create mylastname.com under Domains in AXIGEN WebAdmin. Filling in the information was easy, but the system told me that the domain already existed. I was confused. I thought immediately of some DNS conflicts potentially caused by my configuration. I suspected a problem with the private IP address of the AXIGEN Mail Server (192.168.1.3) and the MX record pointing to a live IP address. I was wrong. It turned out that it was a mis-configuration in /etc/hosts.
As always, some Linux distributions compile an /etc/hosts upon system setup which looks as follows:
127.0.0.1 localhost localhost.localdomain posbis.mylastname.com posbis
This leads to problems for some applications. You should always separate localhost from real IP configuration
127.0.0.1 localhost localhost.localdomain
After this was sorted out I created the first user account/mailbox.
192.168.1.3 posbis.mylastname.com posbis
A really easy task in AXIGEN. Then I started with the first standard tests, verifying that AXIGEN accepts email.
telnet localhost smtp
220 posbis.mylastname.com Axigen ESMTP ready
Everything worked fine and the email showed up in AXIGEN Webmail within fractions of a second.
250-posbis.mylastname.com Axigen ESMTP hello
250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5 GSSAPI
250-AUTH=PLAIN LOGIN CRAM-MD5 DIGEST-MD5 GSSAPI
mail from: email@example.com
250 Sender accepted rcpt to: firstname.lastname@example.org
250 Recipient accepted
354 Ready to receive data; remember <CRLF>.<CRLF>
My first email through AXIGEN Mail Server.
250 Mail queued for delivery
221-posbis.mylastname.com Axigen ESMTP is closing connection
221 Good bye
When you own a domain such as mylastname.com, it is for sure that other family members would like to have such a cool email address as well but most of them already have their email address at an official ISP. That is where the forwarders kick in. By simply defining a forwarder in the form of
email@example.com / firstname.lastname@example.org
So AXIGEN should simply accept the email and relay it to the real address of this family member. Needless to say that it worked like a charm. In Sendmail/Open WebMail I used to do this with /etc/mail/virtusertable.
As I host my email server in a dynamic IP range of my ISP, lots of email hosting companies (such as gmx.de, gmx.net, … ) do not accept emails from "wild" email servers and refuse the connection with a nice notification about “RBL spamhouse.org”. The only solution is to relay these domains through my ISP’s official SMTP server which requires authentication.
With Sendmail/Open WebMail, I solved this by using the following files:
/etc/mail/mailertable (Exception route for each domain)
/etc/mail/access (AUTH information for my ISPs email account)
I only wanted to relay the domains which don’t work with normal DNS delivery (MX lookup) through my ISP. So I needed a way to build this in AXIGEN. I found it in AXIGEN’s filtering architecture
(var/opt/axigen/filters/smtpFilters.script) which provides a powerful scripting language to act upon events such as (onEHLO, onCONNECT, onRELAY etc).
Easily, I modified the existing (and commented) sample in the onRELAY section to forward specific email domains to my ISPs SMTP server.
Special Relay Implementation
Inspecting the log file /var/opt/axigen/log/everything.txt proved that the email was indeed relayed through my ISP and had arrived successfully. WOW! That was easy.
The AXIGEN WebMail interface is quite nice and looks clean and well organized. It covers most areas of an up-to-date groupware such as: email (Inbox, Outbox, Trash etc.); Calendar; Journal; Notes; Contacts; Public Folder; Tasks.
There were three things missing, as compared to my Open WebMail solution:
- WebDisk (Used to up/download files to a private area. This was cool in Open WebMail);
- FROM identity is not selectable if your email address has multiple “Aliases”;
- HTML Editor (WYSIWYG) for email writing. Only plain text is supported by the AXIGEN WebMail interface.
Especially the last two points gave me a headache as I very often send emails in HTML format (colors, bold etc.); I am a member of lots of mailing lists and for each of them I use a different identity (mail alias).
These are for sure points which must be fixed in the next versions of AXIGEN Webmail.
Same is true for only shopping. I create a separate email alias for each vendor I buy something from. For example: email@example.com
This way, If I get SPAM I can exactly see where it comes from and "ask" these companies how it comes that I get SPAM through an email address created/used only for them. Embarrassing for them to explain ☺ If nothing helps; I simply drop the alias. Done.
So I had to find a work-around for my HTML emails and the possibility to handle multiple identities. My first choice was MS Outlook Express as I knew that it can handle multiple identities. But I very fast had to learn that MS OE creates a profile for each identity and that you can have only one email address per profile. To change identity, you must switch it from File-Menu. Not practicable if you think that I have around 60-70 mail aliases for my real email address.
Next, there was Microsoft Outlook 2003 using the AXIGEN Outlook Connector.
The installation of the connector was easy and mailing worked fine. Only the calendar view did not look the same as it would normally look when connected to an MS Exchange server or when using local PST mode.
But again, handling multiple identities (FROM: field) was a little bit clumsy. So I decided to give an email client a chance, a thing for which up to now I haven’t spent a single minute.
It quickly turned out that Mozilla Thunderbird was exactly what I was looking for. It could handle multiple physical email boxes in one GUI and it was easily possible to add additional identities (aliases), selectable later, when sending by a drop down box. Really easy.
So I started sending emails with my test email clients (Axigen WebMail/MS Outlook Express/MS Outlook/Mozilla Thunderbird) to some test recipients such as my company account and another email account,from a different provider. It seemed to work fine and I wanted to move on when I could see that some of the emails had not arrived. I started investigating and I quickly realized that the non-delivered emails had all been sent through my ISP’s smarthost because they were exception domains.
I started analyzing the problem. First, I investigated my filter which separated normal from exception domains in /var/opt/axigen/filters/smtpFilters.script but it seemed okay to me.
Then I increased the log level for SMTP-Out traffic and investigated the log file.
PROCESSING:001F8F7F: [SMTP Filter Info] Set remote smtp ip address to aaa.bbb.ccc.ddd
Surprisingly the email had been successfully delivered to the ISP’s MTA but never arrived! As an IT pro, I love to analyze problems from bottom up. So I used Wireshark to peek into the conversation between AXIGEN Mail Server and my ISP’s SMTP server. In the end, it was all clear; the email was successfully delivered without an error! I didn’t know what to do so, I decided to open a support case with the AXIGEN helpdesk. On their homepage they say something about 24h support even for evaluation. It was worth trying it.
PROCESSING:001F8F7F: [SMTP Filter Info] Set AUTH user to <firstname.lastname@example.org>
PROCESSING:001F8F7F: [SMTP Filter Info] Set AUTH password to *****
PROCESSING:001F8F7F: [SMTP Filter Info] AUTH is Mandatory
PROCESSING:001F8F7F: Relay mail 1F8F7F using filter specified address aaa.bbb.ccc.ddd
SMTP-OUT:00000001: Connecting to aaa.bbb.ccc.ddd
SMTP-IN:0000003C: closing session from [192.168.1.129]
SMTP-OUT:00000001: Connected to aaa.bbb.ccc.ddd
SMTP-OUT:00000001: << 220 smtp.myisp.ch ESMTP server (InterMail vM.7.08.02.00 201-2186-121-20061213) ready Tue, 28 Aug 2007 01:13:30 +0200
SMTP-OUT:00000001: >> EHLO posbis.mylastname.com
posbis SMTP-OUT:00000001: << 250-smtp.myisp.ch
SMTP-OUT:00000001: << 250-HELP
SMTP-OUT:00000001: << 250-XREMOTEQUEUE
SMTP-OUT:00000001: << 250-ETRN
This was the first time when I came into contact with AXIGEN’s FIRsT support. It was 02:00 in the night when I hit the send button. I didn’t expect to get an answer before next day (AXIGEN’s headquarters is located in Bucharest/Romania, so one hour ahead). I was proven wrong!
The first answer arrived at 02:15. And no, it was not an auto-message telling me that my request had arrived and that it would be processed as soon as possible. It was a real answer from a human individual, giving me instructions on what to do next. It was immediately clear to me that this person had in-depth knowledge of the AXIGEN product. I did what I was told and sent back an answer with the result. Again! 15 minutes later another answer trying to narrow down the problem. I was really impressed. The conversation went on for the next 3 days and I exchanged at least 15 emails with the AXIGEN support. And with the exception of one email, all of them were answered within one hour. For the one which took longer, they apologized !
In the end, we have narrowed down the problem to the fact that emails got lost when sent through my ISP’s SMTP server and the emails contained HTML/MIME parts; so they were not plain ASCII/TEXT emails. That is why I didn’t detect the problem earlier, as I did lots of tests with the AXIGEN WebMail interface which only sends in plain text format.
After three days, we still hadn’t solved the problem when AXIGEN offered me a 10 day license to activate the product. They suspected the evaluation banner attached to each email in the trial version to be the problem. This banner was kind of a special HTML/MIME mix that may have not been understood by my ISP’s MTA. With the active license, this banner was not attached to outgoing emails.
And YES ! That solved the problem. And from this moment on, all email clients were able to relay plain text and HTML/MIME emails through my ISP’s SMTP server.
I must say, I was very impressed by the effort the AXIGEN support spent into solving my problem. Just to recall; I was a non-paying customer evaluating the product! This is a level of support you don’t see very often in the IT area.
After all the essential tests were done, I could say that I had nearly the same level of functionality as in my Sendmail/OpenWebmail solution. So far, so good. But there was one problem remaining: data migration.
There were over 1000 emails in my old email system. Stored in Linux mbox format. How could I transfer them to my new system? It was clear to me that the easiest way to access these mbox based email boxes was with an IMAP interface. I could use an email client such as MS Outlook Express or Mozilla Thunderbird to connect to both email systems using IMAP and move the emails. I started Googling (query: mbox IMAP Linux) the Internet for a solution, but only some links regarding conversion programs popped up. So, again, I asked AXIGEN support for help And again; after 1 hour they came up with an answer:
A POP3/IMAP server which understands mbox formatted mailboxes. I downloaded the tar-ball, extracted the files, compiled the sources and installed the product. You know the game (tar xvf, make, make install). It took me another 15 minutes to study the README and to configure dovecot to match my system. I put the dovecot IMAP listener to a higher port (10143; AXIGEN IMAP on 143) and started the daemon. No error messages. I then used my Outlook Express 6 from Windows XP and added an additional mail account to my profile. Outlook Express asked me for the password and after entering it I could access ALL my mbox based email folders used in OpenWebmail. The rest was easy; Drag & Drop.
Speaking about Linux, there exists only one well-known AntiVirus/AntiSpam solution, ClamAV, respectively SpamAssassin.
It was the first time I got in touch with both of them and it took me some time to get it running. Not because AXIGEN would miss the necessary implementation or interface to these products, but rather because of the way they are installed. Especially ClamAV is not an out of the box product which installs itself smoothly. You must write a wrapper init script (/etc/init.d/clamd.axigen) and edit some configuration files before the product does its job. Another hindering factor was that the ClamAV package in the Fedora 7 YUM repository was very outdated and did not play well with AXIGEN; so I had to download a source RPM of the most actual version, build the package and install it manually. It worked better but still not perfectly. It was by accident that I checked YUM again for the ClamAV packages some days later and all of a sudden all the actual packages where there. So I uninstalled my "Do it yourself" package and installed the official ones.
I can’t tell much about their performance or if they work correctly. I sent some test samples through both of them and I see that the mail headers get correct Spam-/Antivirus-Rating tags.
X-Antivirus: avast! (VPS 000775-0, 16.09.2007), Outbound message
And /var/opt/axigen/log/everything.txt shows me entries such as the one shown below.
X-Antivirus: avast! (VPS 000775-0, 16.09.2007), Inbound message
PROCESSING:000301DE: << SPAMD/1.1 0 EX_OK
At the moment, I see two weak points in the AXIGEN AntiVirus/AntiSpam chain:
PROCESSING:000301DE: << Spam: True ; 1001.5 / 5.0
PROCESSING:000301DE: Filter SpamAssassin:[MATCH(P)]: Spam: True ; 1001.5 / 5.0
PROCESSING:000301DE: Finished filtering mail object 0301DE with filter: spamassassin of type socket filter from server
PROCESSING:000301DE: Start filter clamav of type socket filter from server
PROCESSING:000301DE: >> SCAN
PROCESSING:000301DE: >> /var/opt/axigen/queue/03/D01DE.00
IMAP:000001D1: [192.168.1.3:143] connection accepted from [192.168.1.129]
PROCESSING:000301DE: << /var/opt/axigen/queue/03/D01DE.00: OK
PROCESSING:000301DE: Filter ClamAV:[PASS]: OK
PROCESSING:000301DE: Finished filtering mail object 0301DE with filter: clamav of type socket filter from server
- Emails coming in through RPOP are not filtered; and in my case, most of them come in by RPOP, so it is on Thunderbird to catch them;
- When using the SpamAssassin active filter; emails are only tagged, but no action is taken such as moving emails to a specific JUNK folder or modifying the subject with a [SPAM] tag. You must write your own Sieve filters.
I hope this gets addressed in version 5.0 of AXIGEN Mail Server.
Within 10 days, I evaluated the AXIGEN Mail Server, sorted out all the show stoppers with the help of the superb AXIGEN FIRsT support and put AXIGEN Mail Server in production, replacing my current Sendmail/Open WebMail solution. Needless to say that I immediately ordered my 25 mailbox/domain AXIGEN Business license and activated it. Great work must be honored ☺ Since then my new AXIGEN Mail Server runs like a charm and does its job. I have found some minor issues, but the AXIGEN technical support could either solve them or they are currently investigating them.
AXIGEN Mail Server is a great product. It is, super-easy to handle and fits seamlessly into any existing LINUX system without messing up the current system. Their OpenSource version is exactly the same as the commercial one, only with some limitations to the number of mailboxes/domains. But the greatest value of the product is the superb 24h support AXIGEN provides. This is something not seen very often in today’s IT market.
I can really recommend AXIGEN Mail Server to anybody looking to evaluate a professional Linux based mail server. The product is extremely powerful, scalable and gives you a lot of options not found in other products, while also not loosing sight of user/admin-friendly handling.
The ISP version they sell goes even further by separating the product into back-end (mail server/storage) and front-end (IMAP, SMTP proxies) components. This way, proxies can be installed on a DMZ front-end server for increased security.
I am looking forward with eagerness to their upcoming version 5.0.
Oliver Rehmann, Switzerland