This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sophonet
Recipients barry, r.david.murray, sophonet
Date 2021-12-22.16:36:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1640191016.18.0.569343304951.issue46154@roundup.psfhosted.org>
In-reply-to
Content
For an activity with fastapi, I am preparing a Response object with the content of a email.mime.multipart MIMEMultipart object. Adhering to the standards (RFC), a MIMEMultipart response uses CRLF line endings (policy=HTTP). However, the binary attachment I am adding with MIMEApplication() and multipart.attach() in that case gets corrupted since all bytes corresponding to newlines (LF) are replaces with CRLF.

Am I doing something wrong or is this a bug that needs to be fixed?

What I would like to achieve is building a RFC-compliant MIMEMultipart payload in which the subparts do not get altered (in case of application/octet-stream).

Thanks, Sophonet
History
Date User Action Args
2021-12-22 16:36:56sophonetsetrecipients: + sophonet, barry, r.david.murray
2021-12-22 16:36:56sophonetsetmessageid: <1640191016.18.0.569343304951.issue46154@roundup.psfhosted.org>
2021-12-22 16:36:56sophonetlinkissue46154 messages
2021-12-22 16:36:56sophonetcreate