classification
Title: BytesGenerator does not handle 'binary' CTE correctly
Type: enhancement Stage: needs patch
Components: email Versions: Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Nathaniel Manista, barry, r.david.murray, suryak
Priority: normal Keywords:

Created on 2013-08-30 20:37 by r.david.murray, last changed 2015-10-15 01:01 by r.david.murray.

Messages (7)
msg196572 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-30 20:37
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.
msg212697 - (view) Author: Surya K (suryak) Date: 2014-03-04 09:20
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?
msg212717 - (view) Author: Surya K (suryak) Date: 2014-03-04 11:28
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.
msg212724 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-04 15:48
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.
msg253021 - (view) Author: Nathaniel Manista (Nathaniel Manista) Date: 2015-10-14 23:14
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?
msg253022 - (view) Author: Nathaniel Manista (Nathaniel Manista) Date: 2015-10-14 23:59
Also what's this bug's relationship to 19003?
msg253024 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-10-15 01:01
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.

Issue 19003 is a bug involving the handling of bytes payloads (but not binary CTE) and so is different.
History
Date User Action Args
2015-10-15 01:01:03r.david.murraysettype: behavior -> enhancement
messages: + msg253024
versions: + Python 3.6, - Python 3.3, Python 3.4
2015-10-14 23:59:39Nathaniel Manistasetmessages: + msg253022
2015-10-14 23:14:24Nathaniel Manistasetnosy: + Nathaniel Manista
messages: + msg253021
2014-03-04 15:48:50r.david.murraysetmessages: + msg212724
2014-03-04 11:28:57suryaksetmessages: + msg212717
2014-03-04 09:20:50suryaksetnosy: + suryak
messages: + msg212697
2013-08-30 20:37:30r.david.murraycreate