ByteGenerator will assume that it can change any linesep characters to the linesep being used for the general message serialization, even if the content transfer encoding is 'binary'. This is incorrect, as existing \r and \n characters in binary parts must be retained exactly as is.

I have a fix for this. But before putting it forward, can you please tell me about the below

1. email.header.Header.encode() --method
   How different is it from str.encode()? Does [1] method also performs what str.encode() does internally?

Forget about my previous comment.
David Murray:

One possible way to fix this issue is to ignore email.header.Header.encode() on Message values in email._policybase_Compat32._fold() if they come from BytesGenerator and not Generator. We can do this by encoding the value to bytes in email.generator.BytesGenerator._write_headers()

Do you think its a fix? Or even values from ByteGenerators should be formatted using Header.encode()? In that case, I'd look into how it can be done.

cte binary has nothing to do with headers (other than appearing as the value of the content-transfer-encoding header). It is about how the body of the email is handled. ByteGenerator needs to be modified to not do anything with a payload whose cte is binary other than write it to the output stream as bytes. This of course means it is ignoring max_line_length...so it is an interesting question whether or not CTE binary should be supported if max_line_length is anything other than 0/None.

This is status:open but versions:3.3,3.4. Should 3.5 and 3.6 also be listed as being affected by this issue?

Also what's this bug's relationship to 19003?

Just 3.6 at this point, since really support for CTE binary is a new feature (there may even be a separate issue saying that, in which case this one should be closed as a duplicate). We don't auto-update the issue versions when a new release comes out.

bpo-19003 is a bug involving the handling of bytes payloads (but not binary CTE) and so is different.