On Tue, 8 Aug 2017 18:24:29 +0100, David W Noon wrote: > >Mutt has always been very RFC-compliant. > Meaning both that it obeys the rules in the RFCs and doesn't invent any of its own.
>Microsoft sets the standards. > I'm mad as hell, and I'm not going to take it anymore! >Another problem with a non-breaking blank is finding a MUA that >respects the non-breaking attribute. > Sigh. That might be more of the OS's text viewer than of the MUA itself. >RFC 822 has been doubly obsoleted, by RFC 2822 and RFC 5322. The latter >specifies 998 bytes as the line limit with a CR/LF pair added to make >1000. It also recommends a limit of 78 bytes, plus CR/LF. This is why >lines of more than 80 bytes in total can induce encoding. > That strikes me as a cowardly accommodation to broken MUAs such as VM's RSCS. But even that can be configured to deliver messages in NETDATA format rather than printer spool images. An overzealous application of Postel's Principle. >> And encoding might be needed to protect a "From" message separator. I >> recall one MUA that encoded every "F" anywhere in a message as hex 46. >> My first guess at its motivation was probably wrong. > >The "From" separator is peculiar to Berkeley/Eudora mbox mail storage, >although there are many recensions of this. Anything else should not >escape this as ">From", even though some MDAs and even some MTAs do >this, but the usual culprit seems to be mailing list forwarders. I see >lots of paragraphs that begin with "From" that have been decorated to >">From" even though no mbox storage has occurred along the way. > Heavy sigh. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
