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

[Ken Hornstein]

>Is this just in the email headers, not the part headers?

Stepping back a bit ...

As I see it, the job of mhbuild is to take a "draft message" and turn
it into a valid MIME message; it's job is NOT to verify an existing MIME
message.  When invoked in send with the -auto flag, it needs to decide
if the draft file is already a MIME message
>https://www.rfc-editor.org/rfc/rfc2045.html#section-3 shows Mime-Version
>must be present.

Geez Ralph, didn't I quote that already once in this thread? :-)

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

   optional-field  =   field-name ":" unstructured CRLF

   field-name      =   1*ftext

   ftext           =   %d33-57 /          ; Printable US-ASCII
                       %d59-126           ;  characters not including
                                          ;  ":".

Sure seems like "Content-:" is valid.  Hell, even "-:" is valid.

>How much checking is mhbuild trying to do that the draft is valid,
>I think that can become
>
>    if -auto:
>        if Mime-Version:
>            # trust user has done mhbuild's work correctly
>            exit 0
>
>    if Mime-Version or Content-*:
>        gripe MIME headers found: ...
>        exit 1
>
>    mhbuild

Seems reasonable to me.

>The idea is nmh is either in complete control of putting MIME headers
>in, or not at all.  It doesn't remove any that are there as that
>suggests the user has done something wrong.

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
behavior).  But I can't come up with anything.  The behavior you describe
would at least solve the problem here where the user wasn't notified that
the Content-Type header was being eaten, and my reading of RFC 2045
matches yours; we're allowed to match on "Content-.*".  So I'll make that
change.

>BTW, mhbuild(1) doesn't have -auto's default in DEFAULTS.

And I guess that should be fixed as well.

--Ken