Introduction

Einar A. Stefferud founded the original mailing list in the Internet, MsgGroup, in 1979. What Stefferud and many other of the Internet’s earliest pioneers recognized was that unlike the world of physical messaging, the originator is able to automate the sending process. This original mailing list, now termed a discussion group, was formed out of necessity: The researchers wishing to make extensive use of e-mail needed a forum in which to exchange ideas as to how the technology should be developed. Although MsgGroup was used to discuss all aspects of Internet messaging, at times it could be viewed as a discussion group to talk about the technology that made discussion groups possible.

For our purposes, the trick of it is primarily ease of use at the sending desktop. The actual Internet messaging infrastructure—the systems that relay messages between desktops—is blissfully unconcerned as to whether a given message is to be delivered to one recipient or to many. Because of its ubiquity, e-mail is by far the preferred “push” technology for the Internet.¹ However, publishing using messaging as the distribution mechanism is not without problems.

One lesson we shall learn is that list management is difficult for two reasons. First, interpreting error reports is hard to do. The second issue deals with the problem of address maintenance, in the absence of delivery errors. Surprisingly few people can accurately enter their e-mail address. There are perhaps several reasons for this, for example, difficult to spell or remember mailboxes, confusion between hyphens (“-”) and underscores (“_”) and so on. Furthermore, e-mail addresses change frequently; empirical evidence suggests that they change more frequently than any other addressing artifact, including physical delivery addresses, postal addresses, telephone numbers, and so on.

Address management for mailing lists is largely centralized. As a consequence, “subscription”—the ability to manage a database of addresses—is the hard part; in contrast, “publishing”—sending the actual messages—is largely a non-issue.

Of course, once you can publish via e-mail, why publish only text as your content? Why not publish other things via messaging? For now, we’ll consider things from a slightly different perspective—publishing to other applications. [Later in their book Rose & Strom discuss the use of hypertext markup language (HTML) and other formats for e-mail publication.]

From an architectural perspective, originators and recipients are simply “users.” A user might be a person or perhaps a program, such as a calendar or scheduling program. Historically, the term “mail-enabled applications” was used to refer to programs that received and processed mail.

As might be expected, because e-mail is a “best-effort” delivery service, the originating program must be aware of both error reports and silent drops. In the former case, it must be able to interpret the indicated cause of failure and act accordingly. In the latter case, it must contain some kind of algorithm to achieve reliability through retransmission. In practice, however, it is difficult to achieve optimal results without a long traffic history with which to make predictions. A momentary network failure might result in a message being queued for retry several hours later.

Furthermore, the lack of rigorous adherence to standards makes it difficult to write these programs. As a simple example, consider a scheduling program that mails several possibilities as to when a meeting might take place. In the usual case, a corresponding scheduling program would receive the message, consult its appointments database, perhaps consult the people involved and then send a reply indicating whether a meeting is scheduled or not. Now, suppose that a different process receives this message, for example an automated process that simply replies “I am out of the office until next week.” There is no information present in either the original message, or in the reply, to indicate to the Internet messaging infrastructure that there is a misconfiguration. Hopefully, on the theory that the originating scheduling program does extensive error checking, the ill-conceived reply will be detected.²

So, let us now consider these issues in greater detail along with aspects of the systems that cause them.

1 In addition to ubiquity, people’s desktops and enterprise security perimeters, by default, are programmed to receive incoming e-mail: In the former case, no new desktop software need be installed; and, in the latter case, no changes to firewall configurations are typically needed to accommodate messaging.

2 In practice, there is not much reason to be optimistic. Automated error recovery in many mail-enabled applications is quite poor. Current practice is perhaps best described as “bump anything you don’t understand to a person.” While not particularly scalable, it is somewhat better than “dump core on anything you don’t understand.” Of course, all points of this spectrum assume that the application is doing thorough checking of the incoming message before acting on it.