I ran into this while translating a test, but it turns out it is a long standing problem.  I presume it has not been an issue because in general in Python2 email messages are read as text with universal newline support, and thus the linesep characters get translated on *read*, and the problem in Generator never shows up.  In python3, however, we will often read messages as binary, which will preserve the existing linesep characters, and expose the Generator bug.  

This isn't a critical bug for Python3 only because if a message is read in binary it will likely be written in binary using \r\n linesep, in which case the right thing will be happening.  Likewise most messages read from disk will be written to disk.  But it should be fixed so that the cases where a message is read in binary and written to disk in text and vice versa are correctly formatted.  (In particular, uses of the new smtplib.send_message could theoretically run in to this, though I haven't tested to see if that is really a problem.)

To reproduce, read data/msg_26.txt from the email test suite in binary mode (or text mode using "linesep='\n'", which will preserve the crlf in that file), and run str on the resulting message.  You'll see that the MIME preamble and the base64 part both have \r\n linesep, instead of the default '\n' linesep used for the rest of the message.