|
in reply to Re^5: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)
in thread Is ChatGPT like having a thousand monkeys?
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. ;-)
|
Re^7: Is ChatGPT like having a thousand monkeys? (Blank lines in emails)
by LanX (Saint) on Apr 01, 2025 at 16:40 UTC
|
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] |
|
|
Back in the days of NT4 I was accused of surfing the internet for fun during office hours.
My "Temporary Internet Files" folder was filled with pictures of cartoons and memes.
I was flabbergasted, and only after a wile I realized what happened.
Some of the secretaries of the department constantly kept forwarding me and others "funny" emails.
And my Outlook, which was set on preview mode, was storing them there. Probably because of using the IE to render them.
| [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] |
|
|
Just last week, we had an issue with a contractor's mail client. The contractor implements the server-side of $project, we implement the device side, which is essentially a microcontroller talking to an ESP32 to exchange data with the server. We suspected a communication error, so I asked for the debug log output from the device. And what I saw looked like a huge stupid error on the contractor's side. We all know clever people trying to use Word as a code editor, getting StupidQuotes (” “ „ ⹂) instead of straight quotes (") in the way, and confusing the crap out of compilers, interpreters, and parsers. And the debug log looked just like that: StupidQuotes everywhere, breaking any attempt to parse the messages coming from the server. But strangely, also straight quotes emitted by code on the device had mutated to StupidQuotes. And surely, the Mail headers were full of Microsoft fingerprints, his stupid mail client had auto-"corrected" the quotes found in debug log text he copied into the mail.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l] |
|
|
|
|
For the record: the safe solution is to send an attachment.
But I agree with you that it's wrong.
Regarding this company, I'm confident they have an option hidden in the settings to not DWIM HTML snippets.
(They probably think it's more efficient to piss off some experts than to bother millions of amateurs)
This reminds me when I spent days debugging a web app which didn't work for 1% if the users in IE.
After tracking down one of them we found out that he was told to run IE in a compatibility mode with a >10 year old version, because another legacy web app didn't work otherwise, and the maintainer was long lost...
Technology is full of workarounds to fix older workarounds.
Like parsing user agent strings which all claim to be the dominant standard browser from 30 years ago...
| [reply] |
|
|
Whether it is by design or accident it is just wrong.
Email, in all its glory and protocols, is full of stupid workarounds for stupid workarounds for errors in the design.
Try to write an IMAP server (or client), for example. You basically have to take a good guess at what software in what version you are talking to on the other end, so you know with errors you have to make in order for the workarounds of the other program to not mess up the communication.
It might have gotten a lot better since i last did this over 15 years ago, but i haven't checked.
I mostly do HTTP these days, and there are a few hidden gems/least used features in there, too that are still client dependent. Status code 100 is such an oddball. The client can send an "Expect: 100-continue", and the server has to send an intermediate response of "100 Continue" before the client proceeds to send the request body.
Nobody does this anymore, with the notable exception of "curl" on PUT requests. It waits patiently for 10 seconds, and without any response from the server it then proceeds to send the content anyway. So, in order to speed up a specific use case by a client, i had to implement the whole rigmarole of handling partial requests to speed up a sync script from hours to seconds. And now i have another piece of barely maintained, seldomly tested piece of code. That may or may not aggregate some workarounds over time for specific badly implemented useragents, that, for example send the Expect header, but fail when getting the correct response (either "100 Continue" or one of a number of valid error codes).
As soon as your software, or protocol, or markup language parser has to support a couple of decades of backwards compatibility, it starts to get really weird. SMTP (Simple Mail Transfer Protocol) was implemented in 1983, HTML in 1993. MIME (Multipurpose Internet Mail Extensions) was only first standardized in 1996 (around the same time that Microsoft first released Outlook). So it's fair to assume that at least some of the weird features with Microfts mail software is due to backwards compatibility. And with 3-4 decades of people trying (and failing) to fix email standards.
| [reply] |
|
|
