Somehow, email survives despite spam, instant messaging, Twitter, Facebook and LinkedIn. Heck, if it wasn’t for the email notifications I would never check my Facebook page. But what drives email these days?
A look at MailRadar.com shows that Sendmail is still the #1 MTA (mail transfer agent) in use today, followed by Postfix, while Qmail is a distant third. And my God, someone is still using MMDF. Surprisingly, Microsoft Exchange isn’t even in the mix, which casts doubt on the validity of those numbers, but it’s probably safe to say that Sendmail is still the best MTA.
[ Sendmail is one of InfoWorld’s Top 10 Open Source Hall of Famers. Read the full story in “The greatest open source software of all time.” ]
The rallying cry behind most non-Sendmail MTAs is that they are not Sendmail. Sendmail is widely maligned for being a security risk, but my experience running hundreds of Sendmail-based mail servers and mail relays doesn’t confirm that. In the past 15 years, I have yet to see Sendmail used as an attack vector.
Example: I recently helped a friend set up MailMan on a hosted Linux VPS server. The VPS was running Plesk and Qmail. Sounds simple enough, except that in this particular case, the domain’s email was hosted elsewhere, so a subdomain was needed to push email traffic to that specific server. Still, it’s a very minor configuration issue, or so I thought. After several hours of diagnosing perplexing Qmail errors, I switched the whole server over to Sendmail and everything was running within minutes. Indeed, my familiarity with Sendmail helped me here, but I’m not a Qmail newbie either – there are significant Qmail and Plesk issues in this case, and I just wasn’t willing to fall all the way down that particular rabbit hole.
Another stick pushed to Sendmail is that it suffers from the Byzantine configuration. As someone who has written custom rulesets for a horribly complex Sendmail structure, I can verify that when you start digging into the innards of Sendmail, it gets crazy real quick. But the thing is, you can really dig into the guts. Like many things in computing, with great configurability comes great complexity. The reality is that 99% of Sendmail setups are extremely simple — a few lines in a sendmail.mc and a make and you’re fine.
But what about complexity in other popular MTAs? Take a quick look at how you set up virtual email domains and aliases with Qmail and tell me Sendmail is more complex. In fact, don’t. Qmail is incredibly simple for some simple things, but unnecessarily complex for others. If I ever have to write another script to spit out .qmail-xxx files, it will be too soon.
Postfix is a viable alternative, marrying some of Sendmail’s best concepts with a simpler (and less malleable) setup. In my mind, it’s the only real competitor to Sendmail in terms of features and overall ease of use. One of the main reasons I didn’t care about Postfix in the past was the lack of milter support. This meant that using milters such as MIMEDefang, milter-greylist and others was not possible. However, Postfix finally added this support in version 2.3.
And then there’s the gorilla called Exchange. For anyone who grew up with Sendmail or Postfix, Exchange is an administrative abomination. It’s gotten a little better over the years, but I still moan every time I have to deal with it. It’s slow and clunky, and the GUI handling makes setting up Sendmail look like child’s play. Say what you want about non-Microsoft MTAs, but one thing they all have in common is that there’s usually only one or two places to look up the entire MTA configuration. With Exchange, it’s everywhere, but somehow in a single MMC tool. Exchange is more than an MTA, sure, but that’s no excuse for the hurdles administrators have to jump through to perform what should be relatively simple tasks, like migrating to a new server.
Another example: a Sendmail-based server with dovecot IMAP and POP services running needs to be migrated to new hardware or a virtual machine. This task requires creating the new server; copy the contents of /etc/mail, /etc/passwd, /etc/group and etc/shadow; and running rsync on the mailbox folder. If there is centralized authentication, it is even simpler. In total, this represents approximately one hour of work between starting the installation of the operating system and setting up the new server. With large mailboxes, rsync may take a bit longer. If it’s a Cyrus-based IMAP/POP server, a few more tweaks will be needed, but overall it’s a very simple and straightforward situation.
On Exchange, this is hardly the case. Just migrating a relatively small email store from the old to the new can take hours and hours. During a recent Exchange migration, the GUI progress counter for the move mailbox operation ran at 100% for mail migration in 5 minutes, which was confusing. A few checks showed that the migration was far from 100%, but it was still in progress. The progress meter then had a seizure of the clock face freezing and flickering for the better part of six hours before the 15GB of mail was finally moved. For those scoring at home, that’s around 4.5 Mbit, or 600 Kbps – and that was between two dual-processor servers with gigabit interfaces and six-pin RAID5 arrays.
If there’s one thing I can’t stand when doing risky migrations, it’s the fact that these time-consuming and overly expensive processes are a one-way ticket. If at the end of those six hours there were issues with the migration, the only plan to roll back is to try and roll back to the original server, as the maintenance window is cancelled. Also, I don’t like it at all when the progress bars lie to me from the start. Limbo is not a comfortable place for an administrator performing an overnight migration.
I also remember that many Exchange implementations don’t deal directly with the Internet – there’s usually a mail relay that filters emails before they get to Exchange. Personally, I would never install Exchange as a front-end MTA. I prefer to use Linux prophylaxis running Sendmail, MIMEDefang and antivirus.
But without Exchange, we wouldn’t have Outlook, and without Outlook, I imagine people would just be withering at their desks, completely confused as to where their meeting was and who was attending. It is true that most organizations need the functionality provided by Exchange, and while there are open source products that provide this functionality, they are not as streamlined and integrated as the Exchange/Outlook combination. I’ve often thought that if a company wanted to make serious inroads into Microsoft’s understanding of the business world, this is the place to start.
If you build a better mail server, they will come. Perhaps that is why the ancestor of all mail servers is still the most widely used.
This story, “Your mail server sucks!”, originally appeared on InfoWorld.com. Follow the latest developments in apps at InfoWorld.com.
Copyright © 2009 IDG Communications, Inc.