Re: [nmh-workers] Can't forward MIME-encoded message

[Valdis Klētnieks]

On Fri, 10 May 2019 12:58:22 -0400, Ken Hornstein said:

> >And many MIME-extension-fields may be present.
> >https://www.rfc-editor.org/rfc/rfc2045.html#section-9 suggests that's a
> >header matching /^content-/i, including `Content-: foo', I presume,
> >unless some RFC says a header can't end in a `-'.
>
> Huh, that's a new one for me.  RFC 5322 says:

Section 9 is essentially reserving a namespace for MIME-specific
headers.

9.  Additional MIME Header Fields

   Future documents may elect to define additional MIME header fields
   for various purposes.  Any new header field that further describes
   the content of a message should begin with the string "Content-" to
   allow such fields which appear in a message header to be
   distinguished from ordinary RFC 822 message header fields.

     MIME-extension-field := <Any RFC 822 header field which
                              begins with the string
                              "Content-">

So the two of you are in what's often referred to as "violently in agreement" :)

> Yeah, I am TRYING to understand the reasoning for the deletion of the
> Content-Type header; it was clearly deliberate and existed way back in
> MH 6.8.3 (and earlier; the earliest version I can find of mhn.c had that

My under-caffeinated mind is whispering about a myth regarding ancient software
on SunOS that stuck in things like 'Content-Type: uuencode' when using its
pre-MIME scheme for sending non-text data.  Of course, that was before recorded
history^W^WGoogle, so records are sketchy, incomplete, and contradictory.
There is even rumor that that some machines stored 6 6-bit or 5 7-bit bytes in
one memory location, and as a result special incantations were needed if you
wished to converse with a font of knowledge known as "simtel20".

pgpY20A_JiuAK.pgp
Description: PGP signature