A few years ago, I abandoned the simple folksy comfort of shared virtual web hosting in favor of VPS technology. A Virtual Private Server affords all of the luxuries of having one’s own linux box, with (nearly) the same low low cost of shared hosting. You get full root access, with the ability to compile and install whatever software you like, and you usually only pay thirty or forty bucks a month for it.

Ingenious.

When I signed up for my VPS account, I happily installed the latest versions of Apache, PHP, MySQL, Subversion, Perl, Python, Java, and so on. I’m a seasoned techie, and the whole thing was as smooth as butta. I was loving it.

Until the time came to set up my email.

And then I was sad. Very sad.

You’d think setting up email would be simple and straightforward these days. After all, email has been around for more than forty years now, so we’ve had lots of time to figure out the problem.

And there are plenty of unix-y severs that are straightforward (if not simple) to configure. Apache, for example, is a massively complex piece of software. But most of the default configuration options work, right out of the box. And most of the time, it’s pretty easy to customize it to your personal tastes. The documentation is good. And the config files are well commented. Within twenty minutes of installing Apache, most competent linux dudes can have it up and running, serving all sorts of dynamic content.

But configuring sendmail is an entirely different story.

Bear in mind, my server has only ever had to handle email for five different domains, and never more then nine different email addresses.

Yet, somehow, my sendmail configuration file is 2047 lines long, and contains treasures like this:

     # externalize local domain info
     R$* < $+ > $*           $1 $2 $3                        defocus
     R@ $+ : @ $+ : $+       @ $1 , @ $2 : $3                <route-addr> canonical
     R@ $*                   $@ @ $1                         ... and exit

There is not a single human being in the entire world who knows what that means.

In fact, configuring sendmail is so difficult that the fine folks who make SuSE linux have developed their own software to author sendmail configuration files, by parsing data from an entirely different set of config files and then munging all of that data to produce the sendmail config. Yes, you heard that right: config files to configure the creation of other config files.

See, with sendmail, everything is completely configurable. You want to change the format of your SMTP headers? Sendmail will let you.

But that’s dumb. I don’t want to change the format of my SMTP headers. The defaults are a-okay by me.

After much pain and suffering, when my sendmail config was finally correct and I finally thought I was ready to re-join the world of electronic mail, I learned that sendmail actually only sends mail.

Go figure.

To receive mail, I needed an entirely different set of programs.

To make a long story short, I had to compile gnu pop3d and imap4d from source (configure, make, make install). But first I had to get an updated version of libtool. And an updated autoconf. And then I had to install xinetd and set up protocol handlers on the appropriate ports. Then I needed to update the startup scripts in /etc/init.d. Then I had to figure out how to create mail accounts for my users (and let them create their own passwords) without actually granting them shell accounts.

And then I went on a murderous rampage and slaughtered an entire village of Sand People.

Seriously. I’m a clever guy. It should not be that hard.

“But Benji,” I can hear you saying, “What about qmail? What about postfix? Hasn’t the free software world already provided a simpler email solution?”

Ha!! Take a look at this and tell me if you still think qmail is simple.

Sure, it’s simpler than sendmail. But that’s not exactly saying much. And even with qmail, I still need to set up pop3 and imap servers. And I shouldn’t have to install three different pieces of software just for email.

What I’m talking about is a single piece of software that could handle all email-related tasks. It should provide pop3 and imap functionality, right out of the box. It should be possible to perform most admin tasks through a browser interface. And it should take less than twenty minutes install and configure.

I wasted nearly a week of my free time learning how to install and configure sendmail, pop3d, imap4d, and xinetd. Just so that I could send and receive email. In my book, that’s ridiculous, and I would have gladly paid cash money for a piece of software that could have made the whole process seamless.

Developing a Modular Solution

If I were going to develop a mail server, I’d make it as modular as possible. Even basic functionality like SMTP protocol handling would be provided by a plug-in. Additional plug-ins would be responsible for providing protocol handlers for pop3 and imap connectivity. Future plug-in development could support features like MS Outlook connectivity, calendaring, address books, spam filtering, etc.

It would also be interesting to provide a few scripting hooks, so that administrator-defined scripts (in Python?) could be triggered by events in the mail server. (For example, upon receipt of a message to the ’support’ account, the server could add a new record to a customer service database.)

I’d develop the server with a few basic assumptions in mind:

1. There is no association between unix shell accounts and email accounts. Chances are, the email users will never be required (let alone permitted) to access a shell.
2. Users will always access their email accounts via a remote protocol. Local access, through a local MUA or through fetchmail, would not be supported.
3. A well-formed email address must take the form ‘name@domain.tld’. Although sendmail considers something like ‘m’ to be a valid email address, I would disallow it. Even users on the same server should be required to fully-specify all email addresses.

Of course, the RFCs for SMTP and MIME encoding are very complex, and I’d almost certainly have to be willing to deviate from the spec in a few places. After all, protocol complexity is one of the reasons sendmail is so complex. I’m assuming that much of the complexity is due to anachronisms in the spec (like overly permissive treatment of email addresses), but I could be wrong about that.

As far as I can tell, there’s only one significant competitor: Zimbra. But the Zimbra product looks very very good. The feature list is impressive (even for the free version). The Small Business edition (which includes Outlook-compatible functionality) costs a minimum of $1450, though, and I think I could beat that price by a significant margin. On the other hand, Zimbra also includes a really slick AJAX mail client (check out their hosted demo) and I really don’t think I could top it.

If I decide to compete with Zimbra, I have to compete based on server features (which means I would need Outlook connectivity, out of the box) rather than on the features in their webapp.

Pros:

1. Every business needs email. Small businesses are less likely to have dedicated IT staff who can waste lots of time configuring the email server.
2. Small businesses are more likely to use a Linux server than a Windows server. There are already plenty of easy-to-configure email servers for Windows, but most small businesses can’t use that software, because it won’t run on Linux.
3. A modular architecture could facilitate some very cool plug-ins, like Python scripting. This could be a major differentiating factor.
4. I could probably compete with Zimbra (Small Business edition) on price, while still generating a reasonable amount of revenue per license. With a $250 price tag, I’d have to sell about 20 licenses per week to generate $250,000 in annual revenue.

Cons:

1. The SMTP and MIME specifications are very complex. If I can’t find a good library to handle parsing and networking, I’ll be in for a long and error-prone development process. Even if I can find good libraries, it would take a long time to develop a full-featured mail server. I don’t know if I want to spend that much time getting a product to market.
2. Although sendmail, qmail, etc are complex, they are already well-known quantities. They’ve demonstrated that they’re secure and robust. Hard-core industry professionals are unlikely to abandon them, even for a simpler product.
3. Zimbra would be a very attractive alternative. Even their free product seems very feature-rich. I’d have to offer a more compelling server product, specifically targeting the features in their Small Business edition, because I probably wouldn’t be able to develop a better mail client than the AJAX web client they’ve developed.

…

This is the third of 30 business ideas that I’ll be writing about over the course of 30 days. Some of the ideas are simple and elegant. Some of them are so complex, I’m likely to lose what little remains of my sanity just contemplating them. One of them will become a product over the next six months, and the foundation of my new software business.

This entry was posted on Monday, June 12th, 2006 at 11:14 pm and is filed under biz. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.