[ python-Bugs-950747 ] email: mishandles Content-Transfer-Enc. for text/* messages

SourceForge.net noreply at sourceforge.net
Mon May 10 10:09:42 EDT 2004


Bugs item #950747, was opened at 2004-05-09 06:19
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=950747&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email: mishandles Content-Transfer-Enc. for text/* messages

Initial Comment:
[forwarded from http://bugs.debian.org/247792]

Normally when creating MIME attachements with the email
module, the user must explicitly encode (base64 or
quoted-printable) the message using encode_base64() or
encode_quopri(), for example.  That sets the
Content-Transfer-Encoding header, and replaces the
payload with an encoded version which is then emitted
verbatim by the Generator. 
 
However, for text/ objects, the
Content-Transfer-Encoding header is set when the
payload is attached, according to the character set. 
The payload is not encoded at that point, but is
instead encoded according to the charset's default body
encoding by the Generator at flatten() time.  This
means in particular that using encode_*() on a text/*
message with a non-None charset will result in a
malformed message: it will have multiple
Content-Transfer-Encoding headers, and multiply encoded
body. For added confusion the multiple body encodings
won't even be applied in the same order as the
duplicate headers appear (as they would if multiple
encode_*() functions were applied in sequence). 
 
It also means it is impossible to override a charset's
default encoding. For example utf-8 text will always be
base64 encoded, even though utf-8 text in western
languages is likely to be almost entirely 7bit, so
quoted-printable or even 8bit encoding would be more
appropriate. 
 
The payload data of the Message object should
consistently hold either encoded or unencoded data.  If
the latter, the Generator should take its cue from the
Content-Transfer-Encoding header, not from the charset. If 
the former, the encode_* functions should recognize an
already encoded message and recode it, or at least
throw an exception rather than generating a malformed
MIME message. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=950747&group_id=5470



More information about the Python-bugs-list mailing list