Programming Internet EMail

Programming Internet EMail

by David Wood

View All Available Formats & Editions

The Internet's "killer app" is not the World Wide Web or Push technologies: it is humble electronic mail. More people use email than any other Internet application. As the number of email users swells, and as email takes on an ever greater role in personal and business communication, Internet mail protocols have become not just an enabling technology for

…  See more details below


The Internet's "killer app" is not the World Wide Web or Push technologies: it is humble electronic mail. More people use email than any other Internet application. As the number of email users swells, and as email takes on an ever greater role in personal and business communication, Internet mail protocols have become not just an enabling technology for messaging, but a programming interface on top of which core applications are built.Programming Internet Email unmasks the Internet Mail System and shows how a loose federation of connected networks have combined to form the world's largest and most heavily trafficked message system.Programming Internet Email tames the Internet's most popular messaging service. For programmers building applications on top of email capabilities, and power users trying to get under the hood of their own email systems, Programming Internet Email stands out as an essential guide and reference book. In typical O'Reilly fashion,Programming Internet Email covers the topic with nineteen tightly written chapters and five useful appendixes.Following a thorough introduction to the Internet Mail System, the book is divided into five parts:

  • Part I covers email formats, from basic text messages to the guts of MIME. Secure email message formats (OpenPGP and S/MIME), mailbox formats and other commonly used formats are detailed in this reference section.
  • Part II describes Internet email protocols: SMTP and ESMTP, POP3 and IMAP4. Each protocol is covered in detail to expose the Internet Mail System's inner workings.
  • Part III provides a solid API reference for programmers working in Perl and Java. Class references are given for commonly used Perl modules that relate to email and the Java Mail API.
  • Part IV provides clear and concise examples of how to incorporate email capabilities into your applications. Examples are given in both Perl and Java.
  • Part V covers the future of email on the Internet. Means and methods for controlling spam email and newly proposed Internet mail protocols are discussed.
  • Appendixes to Programming Internet Email provide a host of explanatory information and useful references for the programmer and avid user alike, including a comprehensive list of Internet RFCs relating to email, MIME types and a list of email related URLs.
Programming Internet Email will answer all of your questions about mail and extend your abilities into this most popular messaging frontier.

Read More

Product Details

O'Reilly Media, Incorporated
Publication date:
Product dimensions:
7.10(w) x 9.18(h) x 0.90(d)

Read an Excerpt

Chapter 11: The Post Office Protocol (Version 3)

In this chapter

  • Using POP
  • POP Commands
  • POP Sessions

The Post Office Protocol (POP) is the older and simpler of the Internet's two mechanisms for retrieving electronic mail from a remote server. The other, the Internet Message Access Protocol (IMAP) is discussed in Chapter 12, The Internet Message Access Protocol (Version 4 Revision 1). POP and [MAP are both client/server systems that implement the concept of Mail Retrieval Agents, as described in Chapter 2, Electronic Mail on the Internet.

POP is the most mature of these two mechanisms. The current version of POP is version 3 (POP3), which is an Internet standard and has been assigned a designation of STD 53. IMAP, by comparison, is still a proposed standard.

This chapter describes POP3 in detail and provides information necessary to implement either POP servers or clients. There have been several enhancements proposed to extend POP's security options and these are also discussed.

Using POP

POP3 provides a standard mechanism for retrieving electronic mail from a remote server. The messages stored on the server may be deleted (as is usually the case), or retained. This allows many millions of home Internet users to have electronic mail sent to a mail server at their Internet service provider, then retrieve it when they are online. Small offices can use POP in the same manner to pull mail for many users from a mail server at a home office or an Internet service provider. These remote mail servers are known as maildrops. In short, any user that wishes to receive e-mail to their own machine or LAN but does not have a permanent Internet connection may use POP.

A maildrop host must provide several services. It must include an SMTP MTA, providing mail services for all local users (if any) as well as for users for which it acts as a maildrop. The MTA must have access to at least one MDA for local message delivery. Chapter 2 described the relationship of MTAs and MDAs. In order for this machine to provide services as a POP maildrop, it must also include an MRA for POP services. This MRA would consist of a POP server capable of answering POP requests from authorized remote clients.

A POP server is a TCP application daemon that listens for POP requests on TCP port 110. This is called a 'well-known port'. Any POP client wishing to request service from a known host would connect to this port. The server would respond by spawning a new POP server instance on a high port number, communicating that instance port number to the client and return to listening on the well known port to handle other requests. The client would then connect to the instance port and begin the POP3 session communication. The instance server would be destroyed when the session is complete. In this way, one server daemon can handle many nearly-simultaneous requests from multiple clients. The mundane task of port switching is handled automatically in most languages when a socket is opened.

Networks services under Unix can either be run standalone, or arbitrated by the inet daemon. If a program is run continuously and listens for any incoming connections itself, it is a standalone service. The act of listening for incoming connections may be left to to the inet 'super-daemon', which will either start the necessary service or pass the request to a running service, thereby optimizing the use server resources.

Like other network services, POP3 daemons may be run either standalone or via the inet service.

MUAs that provide support for the POP3 protocol implement a POP3 client. A POP3 client may retrieve mail by initializing a connection to a POP server on the maildrop host. Figure 11-1 shows this behavior.

Figure 11-1. POP Usage for a Dial-in Host

The situation for a LAN that is intermittently connected to the Internet is slightly more complex. Instead of servicing a single user and thereby a single MUA, the machine that retrieves remote mail must serve many users on many machines.

An internal mailhost can use the POP3 protocol to retrieve mail from a maildrop on the Internet, as shown in Figure 11 -2. The Unix utility fetchmail is often used for this purpose, although there are other solutions. Fetchmail acts as a POP client, then remails each message to a local MTA, which delivers it to each user's mailbox. Of course, it is equally possible to write a utility that acts as a POP client and directly appends each message to each user's local mailbox.

Internal LAN users would then retrieve their mail in one of three ways; via an MUA on the local mailhost, via IMAP from an MUA on their own machine or again via POP from an MUA on their own machine.

Figure 11-2. POP Usage for a Dial-in LAN

Comparing POP and IMAP

The major difference between IMAP and POP is where mail is ultimately stored (and hence, how it is accessed). With POP, mail is transferred from a maildrop server to a local machine. IMAP, on the other hand, stores all messages on the maildrop. An IMAP-capable MUA passes messages back and forth to an IMAP maildrop to manipulate and view messages, but they are stored on the maildrop.

POP is therefore much more efficient in terms of network bandwidth. Since messages are transferred from a maildrop, there will seldom be a requirement to duplicate the message transfer. If a user wishes to see a stored message again, they may simply retrieve it from local storage. An IMAP user would be forced to retrieve the message over the network, at least once per session. Also for this reason, POP MUAs can be substantially faster than their IMAP counterparts.

Security and privacy aspects are often important when dealing with e-mail messages. Many people are not comfortable with folders of private messages being stored on an Internet-connected server not under their direct control. After all, what you keep may reveal more about you than what you receive.

IMAP has its advantages, too. It was developed to support roaming users who connect from many different client machines. Storing mail on the server means that, once a user is properly authenticated, that user can get full access to all of their mail, both new and saved, regardless of the client that they happen to be using. It is a panacea for those that travel frequently and wish to maintain mail access without having to synchronize mailboxes later.

POP Commands

POP clients initiate every POP session. POP Servers just wait for clients to connect. POP clients issue all of the POP commands and servers respond to those commands.

POP commands are case insensitive, although server responses are not.

When a client connects to a server, the server responds with a banner greeting. It looks like this:

Client: (Initiates socket connection) Server: +OK POP server ready

The first thing that a client must do upon connecting is to provide authentication for a particular user. That way, the server knows that it is safe to allow access to a given mailbox. This is known as the Authorization State. Commands that deal with user authentication are only valid in this state. The client can't do anything in this state except log in or quit.

User authentication commands and examples are shown in "The Authorization State.

Once a user is authenticated, the mailbox may be manipulated. This is known as the Transaction State. Commands that deal with a mailbox are only valid in this state, such as reading messages or moving them to other mailboxes. These commands and examples are shown in 'The Transaction State.

Once the client has issued a QUIT command (which tells the server that the client is finished with the session), a server enters the very brief Update State if any messages have been marked for deletion. At this time, any messages that were marked for deletion in the Transaction State are actually deleted. The server does not enter this state if no messages were marked for deletion.

Every command issued by a client yields a server response. Responses may be single line or multiline, but only as appropriate for the command given. Single line responses always consist of a status indicator ('+OK' or '-ERR') denoting a positive or negative response, an optional comment and a CRLF sequence. The status indicators must be given in upper case and the total line must not exceed 512 characters including the terminating CRLF.

The comments in the single line response are completely optional! Each POP server implementation may put in its own comments, so they cannot be relied upon when parsing server responses. The literal space that separates the status indicator from the comments is part of the comments, so it too may not be present. Some POP client implementations have relied on the space or specific comments, which is not portable.

Multiline responses are only appropriate if the command given demands a multiline response. Multiline responses consist of a single line response (status indicator, optional comment and CRLF), followed by the appropriate data in lines of no more than 512 total characters and ending with a '.' on a line by itself with a CRLF. That is, a sequence of CRLF.CRLF ends any multiline response. . . .

Read More

Meet the Author

David Wood architected the first large-scale RDF database, re-architected the Persistent URL service to support Linked Data, and co-founded the Callimachus Project. He is also the co-chair of the World Wide Web Consortium's RDF Working Group.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >