[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] whatnow: can't attach because no header field name was

From: Ronald F. Guilmette
Subject: Re: [Nmh-workers] whatnow: can't attach because no header field name was given.
Date: Thu, 15 Mar 2012 05:15:09 -0700

In message <address@hidden>, I wrote:

>So I just commented that out, and then made sure I had "-attach 
>set for both whatnow _and_ send (apparently it _does_ need to be set on both)
>and now I can do attachements.  Yep, it's working.
>Thanks a bunch!!
>I am a happy camper.

Hummm... it now appears that I may have broken out the champaign a wee bit

I sent an attachment which was a JPEG file (four-leaf.jpg).

Looking down into the actual message that was sent, I see:

      Content-Type: application/octet-stream; name="four-leaf.jpg";
      Content-ID: <address@hidden>
      Content-Description:   JPEG image data, JFIF standard 1.01 
      Content-Transfer-Encoding: base64

Ahem.  Shouldn't that really say this instead?

      Content-Type: image/jpeg; ...

Is the attach command of whatnow making no attempt whatsoever to try to
determine the correct MIME content type specification?  Is every attachment
just going to be sent as "application/octet-stream"?

I don't expect miracles or clairvoiance, but I _was_ sort-of hoping that
NMH's features for sending attachments would at least be astute enough to
recognise a few of the more common content types, for example:

... well, nevermind.   I'm not going to list them cuz I'm sure you all
can guess what they are.  I'm talking, you know, Postscript files, PDF files,
MSWord (.DOC) files, eXcell spreadsheet files, PowerPoint files, HTML
documents, XML documents, .RTF files, .tar files, gzipped tar files,
shockwave flash files, Nroff/Troff files, .WAV files, .WMA files,
.MP3 files, .AVI files, QuickTime files ... should I go on?

This looks like a pretty comprehensive list:



P.S.  It seems pretty apparent that NMH is at least running the UNIX file(1)
command against the file being attached, and that this is where the content
of the Content-Description: header is being generated from.  It seems to me
that it should not be exceptionally difficult to map the output of the
UNIX file(1) command (for the input file) to a suitable MIME content-type
(and then stick that into the Content-Type: header).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]