(as we do for received mails in the mail fetcher ahead)but sending an invalid attachment is much more grievous than displaying one insteadthe send request fails entirely on errors finallythere is also new support for encoding non-ascii headers (both full headers and names of email addressesper client-selectable encoding that defaults to utf- and the sent message save file is opened in the same mailconfig unicode encoding mode used to decode messages when they are fetched the latter policy for sent mail saves is used because the sent file may be opened to fetch full mail text in this encoding later by clients which apply this encoding scheme this is intended to mirror the way that clients such as pymailgui save full message text in local files to be opened and parsed later it might fail if the mail fetcher resorted to guessing different and incompatible encodingand it assumes that no message gives rise to incompatibly encoded data in the file across multiple sessions we could instead keep one save file per encodingbut encodings for full message text probably will not varyascii was the original standard for full mail textso or -bit text is likely example - pp \internet\email\mailtools\mailsender py ""##############################################################################send messagesadd attachments (see __init__ for docstest##############################################################################""import mailconfig import smtplibosmimetypes import email utilsemail encoders from mailtool import mailtoolsilentmailtool client' mailconfig mimename to type date stringbase epackage-relative from email message import message from email mime multipart import mimemultipart from email mime audio import mimeaudio from email mime image import mimeimage from email mime text import mimetext from email mime base import mimebase from email mime application import mimeapplication general messageobj->text type-specific messages format/encode attachments euse new app class def fix_encode_base (msgobj)"" eworkaround for genuine bug in python email package that prevents mail text generation for binary parts encoded with base or other email encodingsthe normal email encoder run by the constructor leaves payload as byteseven though it' encoded to base text formthis breaks email text generation which assumes this is text and requires it to be strnet effect is that only simple text part emails can be composed in py email package as is any mime-encoded binary part cause mail text generation to failthis bug seems likely to go away in future python and email packagein which case this should become no-opsee for more details client-side scripting