Re: content-type and name parameter

[Francesco Gennai <francesco.gennai@xxxxxxxxxxx>]

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