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

Joaquin Cuenca Abela 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 Conten

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

Joaquin Cuenca Abela 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 in _bdecode that An

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

Joaquin Cuenca Abela 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: +Python 2.5

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

Joaquin Cuenca Abela 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 their attachments and they are

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

Joaquin Cuenca Abela 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, --