(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: e...@univie.ac.at 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to