In contrast, PyMailCGI runs on the web server machine and simply displays mail text
on the client’s browser—mail is downloaded from the POP server machine to the web
server, where CGI scripts are run. Due to the autonomous nature of CGI scripts,
PyMailCGI by itself has no automatic memory that spans pages and may need to reload
headers and already viewed messages during a single session. These architecture dif-
ferences have some important ramifications, which we’ll discuss later in this chapter.
Security Protocols
In onViewPswdSubmit’s source code (Example 16-7), notice that password inputs are
passed to an encode function as they are added to the parameters dictionary; this causes
them to show up encrypted or otherwise obfuscated in hyperlinked URLs. They are
also URL encoded for transmission (with % escapes if needed) and are later decoded
and decrypted within other scripts as needed to access the POP account. The password
encryption step, encode, is at the heart of PyMailCGI’s security policy.
In Python today, the standard library’s ssl module supports Secure Sockets Layer
(SSL) with its socket wrapper call, if the required library is built into your Python. SSL
automatically encrypts transmitted data to make it safe to pass over the Net. Unfortu-
nately, for reasons we’ll discuss when we reach the secret.py module later in this
chapter (see Example 16-13), this wasn’t a universal solution for PyMailCGI’s password
data. In short, the Python-coded web server we’re using doesn’t directly support its end
of a secure HTTP encrypted dialog, HTTPS. Because of that, an alternative scheme was
Figure 16-11. PyMailGUI displaying the same view list
Reading POP Email| 1257