Ned,
thank you a lot for your clear and helpful answer.
You wrote:
not file name information. Clients that depend on file name information
for this are egregiously broken. Sadly, there are many such clients, and
they contribute substantially to ongoing security problems for email.
More sadly, in Italy, we have an e-mail service (it is based on technical rules
pubblished as law) where the server rely on such parameters (name or filename)
to recognizes an attachment in a multipart message.
Could you send me the name of the e-mail client that you are using ?
You can send it off-list, if you prefer.
Thank you !
Francesco
P.s.: technically speaking, I would avoid the name "attachment", because I
think that we should speak simply of MIME parts, but I noticed that some
RFC (after the MIME ones) refers to the word "attachment" to indicate a
message part.
I think that this can cause a bit of confusion.
Should be such RFC amended ? Should the RFC editors pay more attention
on such terminology ?
I have a question about the use of name parameter in MIME header
content-type.
Such parameter is optional in most of the media types,
It is deprecated, not optional. See RFC 2046 section 4.5.1. Software doesn't
have to generate this field to transfer filename information and must
certainly
should not be using this value to control any aspect of processing.
The correct place to put file name information is in the filename parameter
on the content-disposition line. But even this field is optional - you cannot
rely on it being there. In many cases including the filename is totally
inappropriate.
and
(correct me if I'm wrong) it's optional for application/msword,
application/pdf and similar media types.
It doesn't matter what the specific media type is: It is deprecated in all
cases.
Also if it is optional it seems that most of desktop e-mail clients
include it when generating one of such content-type.
Good ones will at most generqate this field in addition to putting the
filename
in the content-disposition line. And even that is probably no longer a very
good idea.
So I wonder if there is any client (desktop client for Windows, Mac, etc..)
that doesn't include the name parameter when creating a content-type.
Well, the client I'm using right now does. I wouldn't use a client that
includes file names by default, in any field whatsoever.
Could someone rely on the presence of such parameter to develop some
software ?
I think no, but your opinion is very much important for me.
Absolutely not. You cannot rely on ANY sort of filename information being
present in the header. MIME uses media type information to control processing,
not file name information. Clients that depend on file name information
for this are egregiously broken. Sadly, there are many such clients, and
they contribute substantially to ongoing security problems for email.
In the cases where the file name is useful it should be carried in the
content-disposition field as a filename parameter. Placing the information in
a
name parameter on the content-type is at best a sop to broken clients.
Ned