[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] I need to learn more about MIME
From: |
norm |
Subject: |
Re: [Nmh-workers] I need to learn more about MIME |
Date: |
Sat, 13 Sep 2014 08:54:55 -0700 |
Ken Hornstein <address@hidden> writes:
>>The above referenced file, Chart.pj, contains only ASCII characters,
>>and has no line longer than 63 characters. Why did nmh use a
>>Content-Transfer-Encoding of quoted-printable instead of text/plain?
>
>That decision is made in scan_content() in uip/mhbuildsbr.c. Well, let
>me rephrase that. For MIME _bodies_, that's where the decision is made.
>For headers that happens in sbr/encode_rfc2047.c.
>
>The exact decision is here:
>
>int wants_q_p = (containsnul || linelen || linespace || checksw);
>
>containsnul means the content contains at least one byte of '0x00'.
>linelen means 'longer than maxunencoded', which defaults to 78.
>linespace means blanks at the end of the line.
>checksw means you're generating an MD5 checksum (which honestly,
>we should get rid of that code).
>
>I suspect you're running afowl of the 'linespace' test.
The problem was that, for reasons I do not remember, Chart.pj had Microsoft
line endings and your "blanks", above includes '\r', and probably other white
space. Confession: It took me an hour to figure that out.
In the unlikely event, that you care, norms-cool-editor, will, by default,
never write a file with lines ending with white space, except that by default,
if a file had any Microsoft line endings it will write it with all Microsoft
line endings. There are interactive options to override both of those
defaults.
Norman Shapiro