Bugs item #975330, was opened at 2004-06-18 12:50 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975330&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anders Hammarquist (iko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Inconsistent newline handling in email module Initial Comment: text/* parts of email messages must use \r\n as the newline separator. For unencoded messages. smtplib and friends take care of the translation from \n to \r\n in the SMTP processing. Parts which are unencoded (i.e. 7bit character sets) MUST use \n line endings, or smtplib with translate to \r\r\n. Parts that get encoded using quoted-printable can use either, because the qp-encoder assumes input data is text and reencodes with \n. However, parts which get encoded using base64 are NOT translated, and so must use \r\n line endings. This means you have to guess whether your text is going to get encoded or not (admittedly, usually not that hard), and translate the line endings appropriately before generating a Message instance. I think the fix would be for Charset.encode_body() to alway force the encoder to text mode (i.e.binary=False), since it seems unlikely to have a Charset for something which is not text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975330&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
