quoted printable line continuation bug?

Question

I'm writing code to generate a report and send it via email. In this case, I'm trying to embed the report as html the body, but outlook is not rendering parts of the report correctly. In particular it appears to be artifacts from the quoted printable encoding. I can't see anything wrong with my encoded text.

I have narrowed the problem down to the following example:

Content-Type: multipart/mixed; boundary="===============0525238969=="
MIME-Version: 1.0
Subject: Your Message(s) from 11/15/2018 04:48:45 PM to 11/01/2019 04:48:45 PM
From: [email protected]
To: [email protected],[email protected]
Date: Fri, 01 Nov 2019 16:48:46 -0500
Content-Disposition: inline

--===============0525238969==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

<br/>
Your report:<br/>
<br/>
<table border=3D1>
<tr><td colspan=3D"11">Found 1 record(s) between 11/15/2018 04:48:45 PM and=
 11/01/2019 04:48:45 PM<br/></td></tr>
</table><br/>
=09=09=09
--===============0525238969==--

Saving this as a *.eml file and opening it in outlook, I notice two problems:

1) The text inside the table cell has an equal sign instead of a space right before the 2nd date:

Found 1 record(s) between 11/15/2018 04:48:45 PM and=11/01/2019 04:48:45 PM
                                                    ^

it should look like this:

Found 1 record(s) between 11/15/2018 04:48:45 PM and 11/01/2019 04:48:45 PM
                                                    ^

2) There's a "=0" at the end, presumably an artifact from the tab characters that got encoded as =09. Automatically stripping out those tabs is problematic because the report is getting generated from a user edited template. It's hard to know if the tab character could be relevant in some situations.

I can actually fix the 2nd issue by forcing an additional \n at the end of the html content, but I'm including it here in case it's relevant to understanding issue #1 above.

P.S. I loaded up the file in "eM Client" and it does not experience either of these glitches. I'm inclined to think it may be a bug in Outlook, but it would be much simpler (and more likely) if it's my bug.

Answer 1

The problem turned out to be that the email content used LF for line feeds instead of CRLF which is required by RFC. Outlook apparently tries to work with the LF content but has some bugs.

If you're generating email from Python and experiencing this problem, remember you need to convert it's output from LF to CRLF before saving it to an .eml file or transmitting the message via SMTP. This is true even on Linux because the specification requires CRLF.

Answer 2

Here is way how SMTP.send_message proceed EmailMessage.

import io
from email.generator import BytesGenerator


#  msg is EmailMessage
def convert(msg):
    with io.BytesIO() as bytesmsg:
        # Use BytesGenerator
        g = BytesGenerator(bytesmsg)

        # or If From, To, CC, BCC has non ascii symbols
        g = BytesGenerator(bytesmsg, policy=msg.policy.clone(utf8=True))

        g.flatten(msg, linesep='\r\n')
        return bytesmsg.getvalue()