On Tue, 8 Aug 2017 09:16:18 -0500, Paul Gilmartin (Paul Gilmartin) wrote
about Curse you, L-Soft!:

[snip]
> 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

Mutt has always been very RFC-compliant.

> 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!?

Microsoft sets the standards.

> 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.

Another problem with a non-breaking blank is finding a MUA that
respects the non-breaking attribute.

> 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.

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.

> 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.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

----------------------------------------------------------------------
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