Items are usually added to mappings using statements something like
"mapping[key] = value", but because Mailbox users wouldn't choose message keys
(instead the Mailbox would assign them), an alternative would be needed. I have
in mind add(), which takes a Message as it's parameter, adds it to the mapping,
and returns a key. For consistency, remove() and discard(), which each take a
key as their parameter, would also be provided (reminiscent of the set API).

Proper file locking for mailboxes is notoriously tedious. The module would be
written to follow all of the locking conventions appropriate for each format
insofar as the host platform allowed. This would be, I think, one of the most
appreciated features of the module: all of the ad hoc mailbox-writing
implementations[1-3] I've seen do not even attempt proper file locking.

The mailbox formats based on monolithic files (mbox, MMDF, and Babyl) do not
lend themselves to the random-access-mutability semantics of mappings as well
as do the directory-based formats (Maildir and MH) because modifying a message
in the middle of a single-file mailbox involves rewriting the entire mailbox.
To accommodate this, modified messages would be temporarily appended in their
new form to the end of the mailbox. A rewrite would not take place until
flush() were called, at which time the new form would be written to the new
file in the position previously held by the old one.

[1] http://groups-beta.google.com/group/comp.mail.pine/msg/8ec75aec68d22f4b
[2] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/157437
[3] http://groups-beta.google.com/group/comp.lang.python/msg/0deb8a620b597a6b