Re: [Nmh-workers] When send does not recognize a mime type

[norm]

Ken Hornstein <address@hidden> writes:
>>Could send have an option that makes an unrecognized mime type an error?
>
>I assume you mean an unrecognized file extension, because the MIME types
>are kinda arbitrary and new ones are being added all of the time.
>
>Do you really want that?  If a file is "unknown", the RFCs say that
>the MIME type should fall back to application/octet-stream, andwe do that.
>I'm on the fence about the behavior where it attempts to auto-detect text,
>but I see the utility there.  I'm just trying to understand why this would
>be a good thing; I think send should generally try really hard to work
>unless there are errors in the transport system.

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. For various reasons some commands (for example, sortm --
with good reason) ,violate that rule, but at least it's a goal.

In this instance, consider the following, not all that unlikely scenario:

  I intend to type

     cp secretName.jpg name.jpg

  But actually type

      cp secretName.jpg name.jqg

  Later I do

        ls ~/Graphs/name*

  to get

        /home/norm/Graphs/name.jqg

  which I pick up with my mouse to insert into the what now attach command. The
  file exists, so attach doesn't complain. I send the message. It is received by
  a Microsoft user. Neither Microsoft nor the user no what to do with the file.

    Norman Shapiro