Somehow e-mail lives on despite spam, instant messaging, Twitter, Facebook, and LinkedIn. Heck, if it weren't for e-mail notifications, I'd never check my Facebook page. But what's driving e-mail these days?

A look at MailRadar.com shows that Sendmail is still the No. 1 MTA (mail transfer agent) in use today, followeded by Postfix, while Qmail is a distant third. And dear 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 remains the top 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're, well, not Sendmail. Sendmail is much maligned for being a security risk, but my experience of running hundreds of Sendmail-based mail servers and mail relays does not bear that out. Over the past 15 years, I've yet to see Sendmail used as an attack vector.

Case in point: I recently helped a friend set up MailMan on a hosted Linux VPS server. The VPS ran Plesk and Qmail. Seems simple enough, except that in this particular case, e-mail for the domain was hosted elsewhere, so a subdomain was required to push e-mail traffic to that specific server. Still, that'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 had everything running in a matter of a few minutes. Indeed, my familiarity with Sendmail assisted here, but I'm not a Qmail newbie either -- there are some significant problems related to Qmail and Plesk in this instance, and I simply wasn't willing to fall all the way down that particular rabbit hole.

Another stick poked at Sendmail is that it suffers from Byzantine configuration. Speaking as someone who's written custom rulesets for a hideously complex Sendmail structure, I can verify that when you start digging into the guts of Sendmail, it gets crazy real fast. But the point is that you really can dig into the guts. Like many things in computing, high configurability comes with high complexity. The reality is that 99 percent of Sendmail configurations are extremely simple -- a few lines in a sendmail.mc and a make and all is well.

But what of complexity in other popular MTAs? Take a brief look at how you configure virtual e-mail domains and aliases with Qmail and tell me that Sendmail is more complex. In fact, don't. Qmail is fantastically simple at some simple things, yet needlessly complex with others. If I never have to write another script to spit out .qmail-xxx files, it will be too soon.

Postfix is a viable alternative, marrying some of the better concepts of Sendmail to a simpler (and less malleable) configuration. In my mind, it's the only real competition to Sendmail in terms of features and overall ease of operation. One of the main reasons I haven't bothered with Postfix in the past was the lack of milter support. This meant that using milters such as MIMEDefang, milter-greylist, and others wasn't possible. However, Postfix finally added this support in version 2.3.

And then there's the gorilla called Exchange. To anyone who grew up with Sendmail or Postfix, Exchange is an abomination from an administration standpoint. It's gotten slightly better over the years, but I still groan every time I have to deal with it. It's slow and cranky, and the GUI management makes Sendmail's configuration seem like child's play. Say what you want about non-Microsoft MTAs, but one thing they all have in common is that there's generally only one or two places to look for the entirety of the MTA configuration. With Exchange, it's all over the place, yet somehow all within one MMC tool. Exchange is more than an MTA, granted, but that's no excuse for the hoops that admins must jump through to do what should be relatively simple tasks, like migrating to a new server.

Another case in point: A Sendmail-based server with the dovecot IMAP and POP service running needs to be migrated to new hardware or a VM. This task requires building the new server; copying over the contents of /etc/mail, /etc/passwd, /etc/group, and etc/shadow; and running rsync on the mailbox folder. If there's centralized authentication, it's even simpler. All told, that's about an hour's work from starting the OS installation to having the new server up and running. With large mailboxes, rsync might 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, straightforward situation.

On Exchange, that's hardly the case. Just the act of migrating a relatively small mailstore from old to new can take hours and hours. One recent Exchange migration had the GUI progress meter for the Move Mailbox operation run to 100 percent for the mail migration within 5 minutes, which was puzzling. A few checks showed that the migration was nowhere near 100 percent, but was still running. The progress meter then proceeded to have an epileptic fit of blocking and clock face jitters for the better part of six hours before the 15GB of mail was finally moved. For those scoring at home, that's roughly 4.5Mbit, or 600KBps -- and this was between two dual-CPU servers with gigabit interfaces and six-spindle RAID5 arrays.

If there's one thing I can't stand when doing dicey migrations, it's the fact that these long, overly onerous processes are a one-way trip. If at the end of that six hours there were problems with the migration, the only backout plan is to try to roll back to the original server, since the maintenance window is shot. Also, I intensely dislike it when progress bars lie to me right out of the gate. Limbo is not a comfortable place for an admin doing an overnight migration.

It's also not lost on me that many Exchange implementations don't deal directly with the Internet -- there's generally a mail relay filtering e-mail before it ever gets to Exchange. Personally, I would never install Exchange as a front-end MTA. I prefer using a Linux prophylactic running Sendmail, MIMEDefang, and a virus scanner.

But without Exchange, we wouldn't have Outlook, and without Outlook, I imagine people would simply wither at their desks, completely confused as to where their meeting was located and who was in it. It's true that most organizations need the features provided by Exchange, and while there are open source products that provide those features, they're not as streamlined and integrated as the Exchange/Outlook combination. I've often thought that if a company wanted to make serious inroads on Microsoft's grasp of the business world, that's where to start.

If you build a better mailserver, they will come. Maybe that's why the grandaddy of all mailservers is still the most widely used.

This story, "Your mail server sucks!," was originally published at InfoWorld.com. Follow the latest developments in applications at InfoWorld.com.