[Top][All Lists]

[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: Fri, 12 Sep 2014 10:50:07 -0700

Ken Hornstein <address@hidden> writes:
>And of course feel free to ask questions if you're confused!

I have scanned all of and have read and understood much of RFC 2045 and RFC
2046; though how much I will retain is problematic. The going was slow because
of a character flaw that limits the amount of pain I can endure each day.
Also, I took two days off to write a program to decode quoted-printable, as a
form of occupational therapy (Yeah, I know, Perl's MIME::QuotedPrint does

I did not find the example in RFC 2049 particularly helpful. But I have
composed and sent a variety of test messages to myself, and looked at how they
came back to me. I have a slew of questions. I hope that they don't abuse your
patience. Here is the first installment.

RFC 2045 seems to require that mail lines have Microsoft line endings, but
fetchmail delivers mail with UNIX line endings. Did they arrive here with
Microsoft line endings?

The remainder of the questions in this Email apply to nmh outgoing mail.

Is it true that, that possibly apart from mhbuild, the nmh user does not have
explicit control of the content type of a message? Based on my
experimentation, nmh must have a fairly complex heuristic for determining
content type. For example, I attached a file named "Chart.pj", That is, a file
whose suffix was not .java. But human intelligence reveals it to be a Java
source file. But nmh knew it was a java file; nmh set:

        Content-Type: text/x-java; charset="us-ascii"; name="Chart.pj"

Is there any documentation of that heuristic, maybe in source code comments?

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?

When I send a test message with non-ASCII characters sometimes nmh uses a
Content-Transfer-Encoding of quoted-printable and sometimes base64. I can't
predict which it will use.

More generally, is there any documentation of how the
Content-Transfer-Encoding is determined? maybe in source code comments?

Is it correct that nmh does not support the partial subtype, described in RFC
2045 Section 5.2.2.

Norman Shapiro

reply via email to

[Prev in Thread] Current Thread [Next in Thread]