Managing IMAP

Why Follow the Internet Mail Model?

Unlike closed commercial mail systems, Internet messaging is defined by a series of specifications that are free and open for all. Consequently, an Internet messaging system can be built using a variety of products from several vendors, with assuring that each product will interoperate with all the other products. This is especially important because the open standards defining the Internet itself make for a highly complex environment in which each component of a messaging model must know what to expect of the others. Communication standardization is the soul of the Internet.

The Internet repeatedly proves the fact that there is no problem so large that it cannot be solved by the principle of “divide and conquer.” A browse through some of the messaging-related RFCs from the early 1970s shows how early ARPAnet^[1] engineers struggled to send email back and forth. Early on, they relied on the weak model embraced by many modern-day closed-source solutions: email as a file-copying program. RFC 469 (circa 1973) kicks around the idea of an email infrastructure based on passing files around using FTP. Even in those early discussions, innovative ideas were alluded to, such as active links to other documents, redirection to central document repositories,^[2] permanent email archives, and content from arbitrary non-textual sources. Those ideas suggested the need for a hierarchy of standards and protocols.

Before too long, however, the problem of how to best implement email was divided and conquered. As we’ve seen, a special-purpose protocol (SMTP) was developed exclusively for transport of the messages from one place to another. Other protocols were developed for accessing the mail once it arrived at the destination mailstore (IMAP and POP). Standards were developed for the format of messages themselves and for encapsulating the payload of those messages (MIME). With the standards in hand, it was an entirely manageable task for the various parts that make up Internet email to interoperate, because the means of doing so was a widely discussed and published set of industry standards. System administrators no longer needed to worry about whether or not the sendmail, QMail, and Postfix MTAs would talk to each other. Nor did they need to concern themselves with whether any IMAP-compliant client would be able to retrieve mail from their UW IMAP, Cyrus, or proprietary IMAP server.

Now that we have a fair idea of what are the major components of Internet email and why we have that model in the first place, let’s look a bit closer at some real-world email transactions.

---

^[1] Advanced Research Projects Agency network (R.I.P. 1970–1990).

^[2] Sixteen years before the Web and 18 years before Gopher!