[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela e98cu...@gmail.com added the comment: Thanks David and Barry! As much as it flatters my ego to be in the first place is MISC/ACK, I have to confess that my family name is Cuenca Abela, Cuenca is not a middle name. Cheers

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela e98cu...@gmail.com added the comment: Unfortunately the only way that I can see to reliably work around this is to bypass entirely get_payload, in this case fixing this bug will not affect people that do that negatively. Some people may have more control over

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela e98cu...@gmail.com added the comment: Hi, I've never before made a patch to Python, so take it with care. A couple of comments, I reused a test where all the attachments contained an ending newline, except for the base64 one (conveniently...) I think the comment

[issue7143] get_payload(decode=True) eats last newline in base64 encoded payload

Joaquin Cuenca Abela e98cu...@gmail.com added the comment: I added a new subpart to msg_10.txt, that keeps the previous test and also tests the new behavior. Let me know if it's ok like this or if you still prefer to create a different msg file for testing this. Thanks, -- versions

[issue7143] get_payload(decode=True) eats last newline

Joaquin Cuenca Abela e98cu...@gmail.com added the comment: Hi, RFC 2046, 5.1.1 refers to the CRLF that happens just before the boundary. It says nothing about an encoded CRLF. From Andreas example, if you have: Content-Type: text/plain; name=test.txt Content-Transfer-Encoding: base64 Content