last determined, or a broader policy, which sidesteps the issue completely. The next
three sections outline suggested improvements and potential exercises.
Alternative: Passing header text in hidden input fields (PyMailCGI_2.1)
Perhaps the simplest way to guarantee accurate deletions is to embed the displayed
message’s full header text in the message view page itself, as hidden form fields, using
the following scheme:
onViewListLink.py
Embed the header text in hidden form fields, escaped per HTML conventions with
cgi.escape (with its quote argument set to True to translate any nested quotes in
the header text).
onViewPageAction.py
Retrieve the embedded header text from the form’s input fields, and pass it along
to the safe deletion call in mailtools for header matching.
This would be a small code change, but it might require an extra headers fetch in the
first of these scripts (it currently loads the full mail text), and it would require building
a phony list to represent all mails’ headers (we would have headers for and delete only
one mail here). Alternatively, the header text could be extracted from the fetched full
mail text, by splitting on the blank line that separates headers and message body text.
Moreover, this would increase the size of the data transmitted both from client and
server—mail header text is commonly greater than 1 KB in size, and it may be larger.
This is a small amount of extra data in modern terms, but it’s possible that this may
run up against size limitations in some client or server systems.
And really, this scheme is incomplete. It addresses only deletion accuracy and does
nothing about other synchronization errors in general. For example, the system still
may fetch and display the wrong message from a message list page, after deletions of
mails earlier in the inbox performed elsewhere. In fact, this technique guarantees only
that the message displayed in a view window will be the one deleted for that view
window’s delete action. It does not ensure that the mail displayed or deleted in the view
window corresponds to the selection made by the user in the mail index list.
More specifically, because this scheme embeds headers in the HTML of view windows,
its header matching on deletion is useful only if messages earlier in the inbox are deleted
elsewhere after a mail has already been opened for viewing. If the inbox is changed
elsewhere before a mail is opened in a view window, the wrong mail may be fetched
from the index page. In that event, this scheme avoids deleting a mail other than the
one displayed in a view window, but it assumes the user will catch the mistake and
avoid deleting if the wrong mail is loaded from the index page. Though such cases are
rare, this behavior is less than user friendly.
Even though it is incomplete, this change does at least avoid deleting the wrong email
if the server’s inbox changes while a message is being viewed—the mail displayed will
Processing Fetched Mail| 1273