Having looked more carefully at the email4 (python2) code, I think I'm wrong.  The test I changed appears to codify the behavior expected when parsing a crlf file in binary mode.  This means that email4 code being ported to email5 may depend on that behavior.  So my initial statement was in fact correct: the email5 code as it stands is correct, it is the tests that are broken.

Fixing the tests so that they run on Windows may be hard enough that I end up just skipping that particular test class on Windows.  The difficulty arises from the fact that email uses '\n' when serializing headers, but the message bodies in binary mode will have the \r\n line endings if and only if the source used \r\n.  Since the source files for those tests are text, they have different line endings depending on the platform, and so the output of re-serializing the messages is different.  

Which means, in essence, that on Windows those test failures are correct failures:  binary parse/binary serialize are *not* inverses.  This is also, then, true for a binary parse of an RFC valid input stream, since the RFCs require \r\n line separators.  In Python2 this wasn't a problem because the file or data stream could be read as text using universal newline mode, thus obscuring the difference in the input line end discipline.  In Python3 this is not possible.

So, an alternative and perhaps better fix is to add a new feature to email5's BytesGenerator that allows the output line end character sequence to be specified.  This would have the additional advantage of closing issue 1349106, and would make it easier to interface with an as-yet-nonexistent binary input interface in smtplib.