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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers