On 2012-09-11, at 7:59 AM, [email protected] wrote: > I guess I kinda believe the opposite. For example send won't send a message > if it > doesn't understand any of the addressees. I think that's a good thing. The > general philosophy of mh was (contrary to the UNIX philosophy) that if > anything > is wrong do nothing.
Not knowing a file's MIME type is not an error. It can't be, since not every type of data has a specific MIME type. E.g., what is foo.dot? foo.xyz? cat.8? These are all files that exist on my systems. foo.dot and foo.xyz are text files. The suffixes are local differentiators with meaning only to me. Adding the dot and xyz suffixes to mimetypes with a text/plain attribute is wrong, since another .xyz file might contain, say, sample raw data from a random number generator. I.e. there is no recognized conventional type for .xyz files. This is why MIME has fallback rules: text/plain for printable ASCII text content, and application/octet-stream for everything else. What about cat.8? On my UNIX systems, that's a pre-formatted man page (text/plain). On my Plan 9 systems, it's object code from the 80386 compilers. (Ditto for cat.2, which could be a pre-formatted man page for a system call, or object code from the 68020 compilers.) This is why deriving the MIME type from the file name is fatally flawed. It's not MIME's job to fix your typing mistakes. --lyndon _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
