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

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.

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". ;-)

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.