was the original requirement of email standards in principlewe could try to search for encoding information in message headers if it' presentby parsing mails partially ourselves we might then take per-message instead of per-session approach to decoding full textand associate an encoding type with each mail for later processing such as savesthough this raises further complicationsas save file can have just one (compatibleencodingnot one per message moreovercharacter sets in email headers may refer to individual componentsnot the entire email' text since most mails will conform to or -bit standardsand since future email release will likely address this issueextra 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 server reallythis is just one part of the email encoding story in the unicode-aware world of today in additionpayloads of parsed message parts may still be returned as bytes and require special handling or further unicode decoding (see the parser module aheadtext parts and attachments in composed mails impose encoding choices as well (see the sender module earliermessage headers have their own encoding conventionsand may be both mime and unicode encoded if internationalized (see both the parser and sender modulesinbox synchronization tools when you start studying this exampleyou'll also notice that example - devotes substantial code to detecting synchronization errors between an email list held by client and the current state of the inbox at the pop email server normallypop assigns relative message numbers to email in the inboxand only adds newly arrived emails to the end of the inbox as resultrelative message numbers from an earlier fetch may usually be used to delete and fetch in the future howeveralthough rareit is not impossible for the server' inbox to change in ways that invalidate previously fetched message numbers for instanceemails may be deleted in another clientand the server itself may move mails from the inbox to an undeliverable state on download errors (this may vary per ispin both casesemail may be removed from the middle of the inboxthrowing some prior relative message numbers out of sync with the server this situation can result in fetching the wrong message in an email client--users receive different message than the one they thought they had selected worsethis can make deletions inaccurate--if mail client uses relative message number in delete requestthe wrong mail may be deleted if the inbox has changed since the index was fetched client-side scripting