Hi,
On Thu, Mar 09 2000 10:10:13 +0000 wrote Edmund GRIMLEY EVANS
with subject "Re: attachments appear as NoName":
> Here you're comparing a text/plain attachment produced by mutt with an
> application/msword attachment produced by some by some other MUA.
I didn't pay attention to the different content types and took the
first attachment I found where I recognized the difference. But to be
sure I tested it sending some mails to myself, e.g. with jpeg
attachments:
with mutt:
[-- Type: image/jpeg, Encoding: base64, Size: 231K --]
Content-Type: image/jpeg
Content-Disposition: attachment; filename="ctrl-alt-del.jpeg"
Content-Transfer-Encoding: base64
and with kmail:
[-- Type: image/jpeg, Encoding: base64, Size: 230K --]
Content-Type: image/jpeg;
name="ctrl-alt-del.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ctrl-alt-del.jpeg"
I got jpeg attachments from a MS Outlook client which also have the
`name' parameter.
> Could you show us the headers of a text/plain attachment produced by
> the other MUA?
Unfortunately not but I sent a message to me with same attachment I
showed in my last messages using kmail and here it is with a `name'
parameter for a text/plain attachment:
[-- Type: text/plain, Encoding: 8bit, Size: 3.2K --]
Content-Type: text/plain;
name="send.c.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="send.c.diff"
Anyway it was more a guess than something...
Kmail does not seem to have that problem with mutt's attachments
anyway, so I start to believe that this is only a dtmail problem.
> I've never seen a "name" parameter with Content-Type text/plain; the
> RFCs don't seem to mention such a thing. I assume MicroSoft are
> entitled to invent any parameters they want for Content-Type
> application/msword. "The set of meaningful parameters depends on the
> media type and subtype", says RFC 2045.
I was trying to find something useful about these parameters but the
rfc's don't mention a `name' parameter explicitely. Instead they say
"MIME implementations must ignore any parameters whose names they do
not recognize." I think this is the case when mutt sees these
unrecognized(?) `name' parameters.
And in rfc 2183 (about the content-disposition header) I found: "The
`filename' parameter can be used to suggest a filename for storing the
bodypart, if the user wishes to store it in an external file."
I don't know how dtmail behaves but maybe you can check if it
creates a `name' parameter or not on it's attachments and if it has a
`content-disposition' header field with `filename' parameter or not.
I think if it does not create these fields by itself, it is likely
that it ignores them too.
Regards, Stefan.
--
Every solution breeds new problems.
