in reply to Re^2: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)
in thread Is ChatGPT like having a thousand monkeys?

IMHO, only unless the OP used an empty boundary in multipart message.

https://en.wikipedia.org/wiki/MIME#Multipart_messages

It would be easier to tell if we saw an SSCCE of the problematic email

Outlook is not the only client to ignore standards, Thunderbird is mentioned in the WP article.¹

My approach was to go for an as simple as possible "standard" which tested well with all main mail clients. (My paying clients insisted on freely composing HTML emails in TinyMCE with embedded images and send them to hundreds of recipients in a group of companies with > 300K employees in total)

Multipart in combination with base 64 worked very well. And of course a unique boundary (very similar to here-docs)

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

¹) And to be fair, old RFCs are prone to ambiguities. Sometimes clients established new "standards" for extensions which were only codified later. While MS was notorious for this, it's not the only player in this game.

  • Comment on Re^3: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)

Replies are listed 'Best First'.
Re^4: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)
by afoken (Chancellor) on Mar 23, 2025 at 13:15 UTC

    IMHO, only unless the OP used an empty boundary in multipart message.

    https://en.wikipedia.org/wiki/MIME#Multipart_messages

    Even with an empty boundary, message parts are separated by lines composed of --, followed by the (empty) boundary, followed by CR/LF. So an empty line never separates MIME message parts, it must at least begin with --. The end of all mime parts is indicated by appending another -- to the boundary.

    Copying the example from Wikipedia:

    MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=frontier This is a message with multiple parts in MIME format. --frontier Content-Type: text/plain This is the body of the message. --frontier Content-Type: application/octet-stream Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aG +Ug Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--

    Changed to an empty boundary:

    MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= This is a message with multiple parts in MIME format. -- Content-Type: text/plain This is the body of the message. -- Content-Type: application/octet-stream Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aG +Ug Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== ----

    (I'm not sure if the empty boundary needs to be quoted. Nobody does that, anyway. The boundary should be a string that does not appear anywhere in the messages. In practice, you stuff in some random data, perhaps user agent, perhaps a timestamp. Maybe hash it. Just get a good chunk of line noise. See Re^5: Using Net::SMTP to send email attachments for more details.)

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      Thanks, yes you are of course right.

      Shortly after writing I noticed my blunder, but each time I tried fixing it the monastery was unreachable for me.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

Re^4: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)
by talexb (Chancellor) on Mar 23, 2025 at 20:38 UTC

    I haven't posted a good example because I'm protecting my client's information, but here's a taste of what I was seeing. This is one of the parts of the page that was causing breakage:

    <!DOCTYPE html> <html> <head> <title>Daily Sage Issues</title> <style> body { font-family: sans-serif; } table { border: 1px solid black; border-spacing: 0px; border-collap +se: separate } td { border: 1px solid black; padding: 5px; } td.right { text-align: right; } td.left { text-align: left; } td.center { text-align: center; } td.bold { text-align: right; font-weight: bold; } div.head { text-align: center; font-size: 24px; } </style> </head> <body> ...
    and here's the repaired section that worked fine:
    <!DOCTYPE html> <html> <head> <title>Daily Sage Issues</title> <style> body { font-family: sans-serif; } table { border: 1px solid black; border-collapse: collapse } td { border: 1px solid black; padding: 5px; } td.right { text-align: right; } td.left { text-align: left; } td.center { text-align: center; } td.bold { text-align: right; font-weight: bold; } div.head { text-align: center; font-size: 24px; } </style> </head> <body> ...
    It really was as simple as removing all of the blank lines in the HTML page.

    Alex / talexb / Toronto

    For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.

      Sorry, maybe I should have been more explicit about the SSCCE we need.

      Not just the embedded HTML, the whole surrounding email.

      If you use gmail for instance, you can click on "Show Original" to see what was exchanged. (I forgot how to get there in Outlook)

      Here a"censored" SSCCE I've send this Sunday.

      MIME-Version: 1.0 Date: Sun, 23 Mar 2025 15:22:37 +0100 Message-ID: <5i96M49FeA+kFy8n2BdseXUtqAHQ_CAAJWxWVzdM@mail.SOME_PROVID +ER.com> Subject: Klappt morgen??? From: rolf lanx <rolf.lanx@SOME_PROVIDER.com> To: "Joky Bäcker" <j.Baecker@SOME_OTHER_PROVIDER.de> Content-Type: multipart/alternative; boundary="0000000000003918c406310 +338d2" --0000000000003918c406310338d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ich wei=C3=9F du hast es in deinem Kalender stehen, aber sicher ist si +cher.= .. LG Rolf --0000000000003918c406310338d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi<div dir=3D"auto"><br></div><div dir=3D"auto">Ich +wei= =C3=9F du hast es in deinem Kalender stehen, aber sicher ist sicher... +</div= ><div dir=3D"auto"><br></div><div dir=3D"auto">LG=C2=A0</div><div dir= +3D"au= to">=C2=A0 Rolf</div></div> --0000000000003918c406310338d2--

      I have no Outlook configured to test ATM, But as I said already, even if that failed with empty lines, a base64 encoding should IMHO work.

      PS: I doubt we need the message ID, I think this is added anyway by the outbound mail server, not the client. (But I may be wrong and might be corrected soon ;)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

        I have this part ..

        --17410280190.8F1407fC3.912618 Date: Mon, 3 Mar 2025 13:53:38 -0500 Content-Type: text/plain <html> <head> <title>Daily Sage Issues</title> <style> body { font-family: sans-serif; } table { border: 1px solid black; border-spacing: 0px; border-collap +se: separate } td { border: 1px solid black; padding: 5px; } td.right { text-align: right; } td.left { text-align: left; } td.center { text-align: center; } td.bold { text-align: right; font-weight: bold; } div.head { text-align: center; font-size: 24px; } </style> </head> <body> <h2>Sage IC Issues - SG1</h2> ...
        And I'm intrigued to see that the content type is labelled as text/plain (probably the default that Email::Simple::Markdown creates). I wonder if I switch that to text/html if the blank line problem would go away. It could be that the message arrives as text/plain, but Outlook checks it out and says, "Hey, this is HTML! I can render this!", then sees a blank line, goes back to displaying regular text until the "HTML!" code pops back into gear and it goes back to rendering.

        Alex / talexb / Toronto

        For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.