format an edit page, which ultimately sends a message to the SMTP server; no POP
information is needed or passed.
But at this point in the interaction, the POP password has racked up more than a few
frequent flyer miles. In fact, it may have crossed phone lines, satellite links, and conti-
nents on its journey from machine to machine. Let’s trace through the voyage:
- Input (client): The password starts life by being typed into the login page on the
client (or being embedded in an explicit URL), unencrypted. If typed into the input
form in a web browser, each character is displayed as a star (*). - Fetch index (client to CGI server to POP server): It is next passed from the client
to the CGI script on the server, which sends it on to your POP server in order to
load a mail index. The client sends only the password, unencrypted. - List page URLs (CGI server to client): To direct the next script’s behavior, the
password is embedded in the mail selection list web page itself as hyperlink URL
query parameters, encrypted (or otherwise obfuscated) and URL encoded. - Fetch message (client to CGI server to POP server): When an email is selected from
the list, the password is sent to the next script named within the link’s URL; the
CGI script decodes it and passes it on to the POP server to fetch the selected
message.
Figure 16-18. Image attachment part selected in PyMailCGI
1270 | Chapter 16: The PyMailCGI Server