Client: Marc Andreessen
Topic: Internet Message Access Protocol (IMAP)
Content Types: Ghostwriting, Article, Interview
CLIENT NEEDS: Marc Andreessen, Internet browser pioneer and partner of the VC firm Andreessen Horowitz, needed a ghostwriter to produce articles and interviews with other pioneering technologists.
DELIVERED: I interviewed a number of technology pioneers, conducted general research, and produced a series of articles and interviews to be published under Andreessen’s byline. A sample interview, on IMAP, is below.
John Myers and IMAP (condensed)
By Marc Andreessen
Well-known and well-respected in the IETF, John has contributed to a number of Internet standards in addition to IMAP4. He wrote the experimental Internet Messaging Support Protocol (IMSP), which evolved into the Application Configuration Access Protocol (ACAP), cowritten with Chris Newman. IETF adopted ACAP in 1997 as an Internet protocol for accessing client program options, configurations, and preferences remotely. John also created a security framework, called the Simple Authentication and Security Layer (SASL), used by IMAP, ACAP, and other Internet protocols.
“I’ve known I was going to be in computers since I was in seventh grade, when my father got a TRS-80 in his office,” John says. Originally from Gainesville, Florida, he received his bachelor of science degree in math (computer science track) from Carnegie Mellon and went on to work at the university as a systems programmer from 1990 to 1996. It was during those years that he began his work on Internet email and security standards. In 1996 Portola Communications recruited John as director of engineering because the company had heard about his impressive work at Carnegie Mellon. At Portola, John worked on commercial IMAP4 server software that by the spring of 1997 literally screamed, getting in some areas ten times the performance of other servers. It’s no secret that we were delighted to grab John when Netscape acquired Portola Communications in June 1997, after its stellar start-up stage.
John’s a modest kind of guy, not much inclined to talk about himself or his work, but a not-so-closely-guarded secret about him is that he harbors a real passion for ballroom dancing. We have proof. Word is that he’s so good at it he even teaches it sometimes.
I recently had an opportunity to sit down with John and talk about IMAP.
Marc Andreessen: Give us the background on your work with IMAP.
John Myers: I got into it when I was a systems programmer at Carnegie Mellon and inherited a mail system they had developed in-house called the Andrew Messaging System (AMS), named after Andrew Carnegie and Andrew Mellon, the two founders of the university. It was enormously successful. The problem was that it was so successful, we soon became unable to support the number of users and the volume of traffic, as there were fundamental things about the design that kept it from scaling. It was compatible with the Internet, because it used Internet formats, but the actual mail-store and the mail server and clients weren’t open standard, because there were no open standards at that time, so you couldn’t mix and match clients and servers.
I did several things to improve the Andrew Messaging System’s scalability, to keep it from falling over, but it was clear that we had to replace it with something. Its strong point was that it stored all the mail on the server, so people could move from machine to machine. They could access their mail at work, or they could go from one lab to another, or they could go home and access their mail. There wasn’t anything comparable out there, and it’s very hard to take features away from users.
So I looked through the IETF Request for Comments (RFCs) that were available at the time, especially those for accessing stored mail, and I found, basically, only two possible protocols. One of them was Post Office Protocol (POP), which was far too simple, because it doesn’t allow multiple folders on the server; everything’s downloaded. The other was IMAP (version 2.0), written by Mark Crispin of the University of Washington, which was at least the start of something that we would need in this new system.
I got in touch with Crispin and started working with him and some other people at the University of Washington. Then we took IMAP into the IETF and came up with IMAP4, which was approved as a Proposed Standard in 1994. The initial RFC for IMAP4 was revised in 1996 and in 1998.
Concurrently with the IETF work, I wrote an IMAP4 server that was designed to be scalable. That was the Cyrus server. We named it after Cyrus the Great of Persia (599-530 BC), the Persian emperor who instituted the first scalable postal system – or so we thought. Later research showed that it was actually Darius, not Cyrus, who instituted the postal system. I believe Cyrus came later. It may have been Cyrus who first instituted secure messaging, sending spy reports inside dead rabbits—I’m not up on all the details.
In the summer of 1996, I got the offer to go to Portola. I had finally gotten the Cyrus server to the point where we were starting deployment, and the Portola offer was basically an opportunity that was too good to turn down. By the spring of 1997, Portola had an IMAP4 server that was far faster than anything else available. We were getting ten times the performance in some areas. That’s when Netscape bought Portola. So I came to Netscape in June 1997, when the merger was complete, to integrate the Portola codebase into Netscape’s next-generation messaging server. We introduced it at the Electronic Messaging Association conference in April 1998.
MA: What do you see as the key features of IMAP?
JM: There are two primary ones. The first is location independence, meaning the mail is stored on a server, so you can access it from home, from on the road, or from work. The other is the feature called disconnected use, which means that you can download a copy of your mail to your laptop and then disconnect from the network. You can then read your mail, reply to it, and make changes to the folders, all while on a plane or in some other place where you don’t have a network connection. When you reconnect to the network, your replies are sent out and the changes you made on the client are applied to the server.
MA: What other features make IMAP unique?
JM: The search capability is one standout. With IMAP you tend to leave your mail on the server, so the client only downloads what it needs, and doesn’t normally have enough of the mail to do searches locally. But the client can ask the server to perform a search in the headers or the bodies of messages, and the search happens on the server, which replies as to which messages match. So you can say, “I’m looking for messages from John Myers, after last Thursday, which came with the word ‘IMAP’ in the body.” You don’t have to pull 3000 messages down to the client to find the one you’re looking for.
IMAP is also great if you commonly find yourself in situations where you want to preview your incoming messages and selectively download them. And if you’ve got a message with a large attachment, you can even download the text portion of the message and leave the attachment alone.
IMAP is an enabling technology. New applications can be built using it. The fact that IMAP allows you to query the server in a very efficient way makes it possible for applications to check for messages and download them on demand. Additionally, IMAP servers handle concurrency so multiple applications can be operating simultaneously on the same files.