The PyMailCGI Website
In Chapter 14, we built a program called PyMailGUI that implements a complete
Python+tkinter email client GUI (if you didn’t read that chapter, you may want to take
a quick glance at it now). Here, we’re going to do something of the same, but on the
Web: the system presented in this section, PyMailCGI, is a collection of CGI scripts
that implement a simple web-based interface for sending and reading email in any
browser. In effect, it is a webmail system—though not as powerful as what may be
available from your Internet Service Provider (ISP), its scriptability gives you control
over its operation and future evolution.
Our goal in studying this system is partly to learn a few more CGI tricks, partly to learn
a bit about designing larger Python systems in general, and partly to underscore the
trade-offs between systems implemented for the Web (the PyMailCGI server) and sys-
tems written to run locally (the PyMailGUI client). This chapter hints at some of these
trade-offs along the way and returns to explore them in more depth after the presen-
tation of this system.
Implementation Overview
At the top level, PyMailCGI allows users to view incoming email with the Post Office
Protocol (POP) interface and to send new mail by Simple Mail Transfer Protocol
(SMTP). Users also have the option of replying to, forwarding, or deleting an incoming
email while viewing it. As implemented, anyone can send email from a PyMailCGI site,
but to view your email, you generally have to install PyMailCGI on your own computer
or web server account, with your own mail server information (due to security concerns
described later).
Viewing and sending email sounds simple enough, and we’ve already coded this a few
times in this book. But the required interaction involves a number of distinct web pages,
each requiring a CGI script or HTML file of its own. In fact, PyMailCGI is a fairly
linear system—in the most complex user interaction scenario, there are six states (and
hence six web pages) from start to finish. Because each page is usually generated by a
distinct file in the CGI world, that also implies six source files.
Technically, PyMailCGI could also be described as a state machine, though very little
state is transferred from state to state. Scripts pass user and message information to the
next script in hidden form fields and query parameters, but there are no client-side
cookies or server-side databases in the current version. Still, along the way we’ll en-
counter situations where more advanced state retention tools could be an advantage.
To help keep track of how all of PyMailCGI’s source files fit into the overall system, I
jotted down the file in Example 16-1 before starting any real programming. It informally
sketches the user’s flow through the system and the files invoked along the way. You
can certainly use more formal notations to describe the flow of control and information
1230 | Chapter 16: The PyMailCGI Server