file _test-decoding.py in the examples package for a test of this logic). In practice, an 8-
bit Unicode encoding such as Latin-1 will probably suffice in most cases, because ASCII
was the original requirement of email standards.
In principle, we could try to search for encoding information in message headers if it’s
present, by parsing mails partially ourselves. We might then take a per-message instead
of per-session approach to decoding full text, and associate an encoding type with each
mail for later processing such as saves, though this raises further complications, as a
save file can have just one (compatible) encoding, not one per message. Moreover,
character sets in email headers may refer to individual components, not the entire
email’s text. Since most mails will conform to 7- or 8-bit standards, and since a future
email release will likely address this issue, extra complexity is probably not warranted
for this case in this book.
Also keep in mind that the Unicode decoding performed here is for the entire mail text
fetched from a server. Really, this is just one part of the email encoding story in the
Unicode-aware world of today. In addition:
- Payloads of parsed message parts may still be returned as bytes and require special
handling or further Unicode decoding (see the parser module ahead). - Text parts and attachments in composed mails impose encoding choices as well
(see the sender module earlier). - Message headers have their own encoding conventions, and may be both MIME
and Unicode encoded if Internationalized (see both the parser and sender
modules).
Inbox synchronization tools
When you start studying this example, you’ll also notice that Example 13-24 devotes
substantial code to detecting synchronization errors between an email list held by a
client and the current state of the inbox at the POP email server. Normally, POP assigns
relative message numbers to email in the inbox, and only adds newly arrived emails to
the end of the inbox. As a result, relative message numbers from an earlier fetch may
usually be used to delete and fetch in the future.
However, although rare, it is not impossible for the server’s inbox to change in ways
that invalidate previously fetched message numbers. For instance, emails may be de-
leted in another client, and the server itself may move mails from the inbox to an un-
deliverable state on download errors (this may vary per ISP). In both cases, email may
be removed from the middle of the inbox, throwing some prior relative message num-
bers out of sync with the server.
This situation can result in fetching the wrong message in an email client—users receive
a different message than the one they thought they had selected. Worse, this can make
deletions inaccurate—if a mail client uses a relative message number in a delete request,
the wrong mail may be deleted if the inbox has changed since the index was fetched.
968 | Chapter 13: Client-Side Scripting