Re: [Nmh-workers] My .mh_profile

[Ken Hornstein]

>when you attached your .mh_profile, thanks to an underlying
>"file --mime-type" invocation, it gained a content-type of
>"message/news".
>[...]

Wow, I didn't really think about all of that.  So yeah, a number of
bad decisions all added up there.  The profile format _does_ look like
a RFC-822 message (not a coincidence), so it's not surprising that file
ends up doing that.

>so i tried to save it, using mhstore, and mhstore helpfully stuck
>your .mhprofile into my current folder as a new message of very
>questionable validity.  (i'm not sure when i'd ever want an attached
>message part of type news saved to my current folder, but i'll allow
>it.)

Hm, looks like this comment is wrong (from mhstoresbr.c):

    /*
     * Check if the content specifies a filename.
     * Don't bother with this for type "message"
     * (only "message/rfc822" will use store_generic).
     */

The reality is:

        case CT_MESSAGE:
            switch (ct->c_subtype) {
                case MESSAGE_PARTIAL:
                    return store_partial (ct, info);

                case MESSAGE_EXTERNAL:
                    return store_external (ct, info);

                case MESSAGE_RFC822:
                default:
                    return store_generic (ct, info);
            }

>then, running show or mhshow on that invalid message results not in an
>error, but rather no output at all (apart from a part separator).

Yeah, because mhl isn't matching on any headers, and there's no body.

>it's a home run!

A home run in sucking, definitely :-/

Seems like we should do something different in store_generic() (or really,
store_content()).  We should restrict that automatic handling to only
message/rfc822.  Right now the assumption is there are no other message
parts other than rfc822, external, and partial.

--Ken