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

It's been a wile since I worked with the email format, but I seem to remember empty lines¹ have syntactic meaning to separate header and different "paragraph portions" (like content and attachments) of the email. (I'm too tired to look up the correct terminology)

Only the first empty line has that special meaning, it separates the message headers from the message body. The message body can literally be everything for a basic RFC822-style mail. For multi-part MIME messages (e.g. HTML with plain text alternative, or HTML with images), the message header specifies a boundary that marks the end of a MIME message part, after that, you are back to parsing headers, and another empty line separates that from the next message body. See MIME in the Wikipedia for a nice short example, and for links to the RFCs.

Outlook should have absolutely no problems with empty lines in the message body. That said, Outlook has a very long and very ugly history of ignoring established standards, so I would not bet a penny on Outlook behaving properly.

I would have a look at the mails in another mail client, like Thunderbird. Also, I would have a look at the raw mail format, as received from the mail server. Again, Thunderbird could help with that, it does not mess with the message source.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
  • Comment on Re^2: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)

Replies are listed 'Best First'.
Re^3: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)
by LanX (Saint) on Mar 22, 2025 at 22:57 UTC
    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.

[reply]

      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--

      [download]

      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==
----

      [download]

      (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". ;-)
[reply]
[d/l]
[select]
        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

[reply]

      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>
...

      [download]
      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>
...

      [download]
      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.

[reply]
[d/l]
[select]
        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--

        [download]

        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

[reply]
[d/l]

In Section Meditations