(sent via web interface) On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht wrote:
>David W Noon wrote: > >>Sometimes Base64 or other binary-safe encoding is required by RFC. > >So I see. Thanks. Wish Shmuel is here, he certainly has something to say about >all these RFC requirements... > According to various experiments and headers of off-list messages: MacOS Mail.app sends utf-8 as quoted-printable but deals corectly with incoming 8-bit/ From one set of mail headers: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From another sent from Outlook/Windoze: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WTF!? Why encode us-ascii? 7bit should suffice. But every blank was encoded as hex 20!? A message I sent with mutt to IBM-MAIN; Cc: [email protected] was reflected by echo with an 8bit header so I assume that's what mutt uses. But IBM-MAIN REPROed it as quoted-printable. Still phobic of 8bit. A "non-blank blank" might be either a nonbreaking space or an en-space. 8bit utf-8 should suffice for those; no need for base64. RFC 822 limits records to 999 bytes, give or take a <CR><LF>. Longer records require some encoding. But some MUAs, phobically, encode any message containing records longer than 80 bytes. I blame a desire to accommodate antediluvian IBM conventions for this compulsion. 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. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
