Your "blunder" is easy to forgive. You are not the one running a billion dollar company who has promised (and failed) for the last 30+ years to finally fix the most obvious bugs in their expensive email client. ;-)
| [reply] |
I'm still not convinced that Outlook is the problem here, I'd say the OP used the wrong module.
Outlook saw HTML inside a text and not HTML section, nevertheless tried to render it and failed after a line break.
You can call this autocorrection/ DWIM a bug, I call it undefined behavior.
Edit
Well yes, strictly speaking the HTML should have been rendered as text.
Anyway I remember the days when Outlook used the Word HTML renderer in the background ... (Shudder)
| [reply] |
I remember the days when Outlook used the Word HTML renderer in the background
And why? Because Outlook used to use the IE HTML renderer, which could not be sufficiently restricted. So more often than not, an unwanted feature of IE was also available in Outlook, even when it should have been blocked. Plus, Outlook also suffered from most of the bugs in IE. So switching to probably the only other usable HTML renderer that had intentional limits was actually not the worst idea.
Yes, the HTML and CSS subsets understood by the Word renderer was very different from the IE renderer, and it had its own set of quirks. Oh well. HTML never promised pixel-perfect, identical rendering on all browsers and all devices. Even less so inside the (hopefully) restricted environment of a mail viewer.
IMHO, a mail viewer must not load external resources, no images, no scripts, no stylesheets. It must not support any kind of code execution for the HTML mail (e.g. Javascript, VBScript, ActiveX controls). And it should prevent misleading styling of texts, images, links, and buttons. It also should not support HTML forms. Yes, that limits what can be styled in HTML mails. It makes all kind of colorful, animated spam look boring. But it also prevents spying on mail recipients, automatic actions on the behalf of the mail recipient, and a lot of trickery to fool the user into clicking on malicious links.
Perhaps it would also be a good idea to clearly display at least the domain of all links in the HTML right next to the link. Yes, that would make HTML mails even uglier. But hopefully, it would make people think twice before clicking on a link that pretends to be the link to your online banking or your parcel service.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
You can call this autocorrection/ DWIM a bug
Whether it is by design or accident it is just wrong. If the MIME type is text/plain then the MUA should render it as text/plain and nothing else.
I've had similar problems in the past when sending plain text emails to colleagues at other orgs where the messages contained inline snippets of XML which we were discussing. The colleagues could not see the XML because their MS Outlook oh-so-helpfully rendered it into invisibility instead of just displaying the source XML. No idea how they got around that in the end because I didn't care to ask after a dozen back-and-forth emails of "You didn't send any XML", "Yes, I did.", etc.
| [reply] |