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

[Ralph Corderoy]

Hi Ken,

> > I agree the earliest git commit checks both, but the RFC says C-T-E
> > is optional.  I think the only mandatory MIME header is the version
> > so can't we ditch the other test?  Otherwise it just leads to calls
> > to extend the list.
...
> I find it odd that it bails out on a Mime-Version header AND a CTE,
> but it silently eats the Content-Type.
...
> I don't think mhbuild can just ignore existing MIME headers.  This is
> what we have now:
>
>     --------------------------+---------+--------
>     Header                    | -auto   | -noauto
>     --------------------------+---------+--------
>     Content-Transfer-Encoding | exit(0) | exit(1)
>     Mime-Version              | exit(0) | exit(1)
>     Content-Type              | Remove  | Remove

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

https://www.rfc-editor.org/rfc/rfc2045.html#section-3 shows Mime-Version
must be present.  These four may be present once.

    Content-Type
    Content-Transfer-Encoding
    Content-ID
    Content-Description

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

How much checking is mhbuild trying to do that the draft is valid,
e.g. there aren't two C-D when only one is allowed?

How about making the logic simple and seeing if that meets needs?
I don't think a table can state it unless the rows imply order.

    if -auto:
        if Mime-Version:
            return # trust user has done mhbuild's work correctly
            exit 0
        if Content-*:
            gripe MIME headers found: ...
            exit 1
        mhbuild
    else:
        if Mime-Version or Content-*:
            gripe MIME headers found: ...
            exit 1
        mhbuild

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

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.

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

-- 
Cheers, Ralph.