Postini: New Email Infrastructure For ISVs And VARS.

How long has it been since you heard the term "killer app?" Once this grail of computing was all the rage among hopeful software developers and venture capitalists. Now, especially in the aftermath of the dot-com die off, only tone-deaf flacks or the truly clueless seem to use it anymore. And indeed, how much room is there for a killer app in a world shattered into countless niche opportunities by the centripetal forces of the Internet? Is anyone ever likely to stumble on something as big as, say, the browser again?

Perhaps not, but there is more room than ever for innovation, especially when that innovation is based on a killer app that came and went almost unnoticed. That killer app is email, and its size is mind-boggling. Each year hundreds of billions of email messages are exchanged via the Internet. Never mind that no one's making a killing selling email software or that it seems almost like an ostensive definition of a commodity application. It's still big; really big. It is the basis of most of the "collaborative" computing taking place today. And its full implications--technologically, politically, socially--have yet to be fully worked out. Email is a work in progress.

Which means it was only a matter of time until someone noticed an opportunity--perhaps only one of many--to decommoditize it. After all, what is email, really? From the user's point of view, it's the inbox. Everything else is just behind-the-scenes processing. Which, as proponents of the Application Service Provider (ASP) model of computing are quick to point out, can be done anywhere. It seems strange that no one noticed this sooner. Or rather, that no one noticed sooner how nicely the basic structure of the Simple Mail Transfer Protocol (SMTP) and the Domain Name Service (DNS) could mesh to provide a killer added-value play in the email space.

But that oversight is good news for Postini Corp. (Redwood City, CA), which has done just that. In effect, Postini is an email ASP that has created an SMTP "bus" for the delivery of value-added email services, and done so in a way that is completely transparent not only to end-users, but their service providers--Postini's customers--as well. It looks very much like a win-win situation, and quite applicable to VARs and integrators alike. But to understand why, it's useful to look at how Internet email works and why that poses a problem for Email Service Providers (ESPs, which include ISPs) and others who would like to make email something other than a commodity.

You Have Mail (Yeah, So What?)

Internet email is based on SMTP, which describes the interaction between Mail Transfer Agents (MTAs), which are responsible for carrying messages to and from hosts on the networks, and Mail User Agents (MUAs), which are simply the email clients, such as Eudora or Outlook, that people use to compose and send email. In pure Internet email systems, the MTA works in conjunction with delivery agents such as a Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) servers. In systems such as Microsoft Exchange, the MTA is integrated with a proprietary delivery agent.

In practice, after you use your MUA to compose your message and hit send, it establishes a connection with its assigned MTA and sends a sequence of commands as specified by SMTP or ESMTP (Extended SMTP, which has a mechanism for adding capabilities, such as MIME). These commands handle, among other things, the task of actually transferring the body of the email. If the address of the message is in the system controlled by the MTA (for instance, served by the same ISP), it stores it in a delivery agent, which waits for the MUA of the user for whom it's intended to retrieve it. If not, it hands the message off to another MTA: either the destination MTA if it knows where that is, or to another MTA closer to the destination. This part is handled by Mail Exchange (MX) records in the associated DNS servers.

There's much more to it than that of course, but that skeletal outline of the process is enough to understand why it's so hard to add value to email. The problem is that, given the open nature of SMTP, literally anyone can supply email services. The basic SMTP software is widely available as open source, in fact, the Internet runs largely on Sendmail, which is also available as a commercial product. Just set up a Linux box with Sendmail and a connection to the Internet, and you're in business. With an email service just like anyone else's.

Of course, you can add some value if you want to. You can install anti-virus software, or spam filters, or anything else you can think of. But that requires modifying your MTA in some way--the MTA is where any additional mail processing is best handled. Adding commercial software modules to your mail server risks bringing it down due to unforeseen software interaction, and adds to the load your email server must handle. And you probably don't have the resources to develop new applications or write a new MTA to meet user demands. That's how AOL does it. But how will you keep up with the big dogs?

Neither Rain, Nor Snow...

That's where Postini comes in. They've done all the hard work of creating an MTA that serves as a kind of bus that they can plug new applications into. These currently include spam filtering, anti-virus processing (based on a partnership with Trend Micro), and intelligent wireless mail forwarding. Or ISVs can write new applications to their API. In either case, the applications run on Postini's cluster of Sun Netra servers.

Here's where it gets clever. Because it's DNS that identifies the appropriate MTA to receive a message, the only thing an email service provider has to do to start using the Postini services is change one record in their DNS server. Once that change propagates throughout the Internet, all mail bound for the users of that ESP will go to the Postini servers instead, to be transparently forwarded on to the user after processing. The user never knows that XYZ Internet handed off the email to Postini to be virus scrubbed or despammed. The ESP doesn't have to change their software, their hardware, or the email addresses of their users. The figure shows the basic structure of the Postini system.

In addition, the users have control over the various processing parameters of the Postini service through a simple web browser interface; though, again, it looks like a service of the ESP. They control what Postini rejects as spam in their emails and the parameters for wireless email forwarding.

So it appears to be a win-win situation all around. Users get better email service, with a great deal more control over it, and ESPs get even more. Since some 30% of email these days is spam, by filtering it out before it gets to the ESP's network, they get better utilization of their bandwidth, and thus lower bandwidth costs. They save CPU cycles, improve their server uptime, and lower operation support costs because all the email processing is being handled by Postini. Since the email services are still branded by the ESP, it improves brand loyalty and yields better marketing leverage. Best of all, the services may serve to generate incremental revenue.

ISVs benefit because, by writing an application once to Postini's APIs, they get access to millions of downstream users--Postini already has over a million users--without any further integration effort. And, although right now Postini has no reseller program for VARs and other integrators, they are looking to develop one so that integrators will be able to offer extensive email capabilities to their customers without the integration effort and support costs this would normally entail. This should leave them free to concentrate on their unique or vertical value add without losing out because of lack of email expertise.