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.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my weekly webcomics

In reply to Re^9: Is ChatGPT like having a thousand monkeys? (Blank lines in emails) by cavac
in thread Is ChatGPT like having a thousand monkeys? by talexb

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.