Question about composing a MIME part where I would suggest
also the file name.
In the case that I would suggest a file name to the remote
MIME client could I use only the name parameter of the content-type
or MUST I add the content-disposition header with the filename parameter?
The situation is as follows. The original MIME specifications only provided a
means to associated filenames with application/octet-stream parts. This was
done through the use of a name= parameter on the content-type. The theory here
was that filenames were mostly used for type information and therefore did not
need to be present in most cases.
This was a mistake on our part. It seems a lot of people really like to
associate file *names* with parts. So, when we didn't initially provide a
standard means to do this, people just started using name= parameters for all
sorts of different types.
Even worse was the presence of some agents that, in flagrant defiance of
MIME requirements, looked at file names for type information and ignored
the media type completely.
The specification of content-disposition attempted to provide a more general
means of providing file name information by defining a filename parameter as
part of the content-disposition field. Unfortunately in the process another
mistake was made: No name was defined for the nominal "default" disposition
that corresponds to no content-disosition being present. The result is that the
now-standardized mechanism for associating a filename with a part cannot be
used without in some cases change the part semantics, since no
content-disposition isn't equivalent to inline , attachment or any other
So what are the operational implications of all this? There are several. One is
that there are agents that only look at the name= parameter for filenames, and
other agents that only look at filename=. This in turn has led in some cases to
attempts to bridge the gap by in effect copying the name= parameter value to
the filename= parameter value, either implicitly or explicitly. And that
behavior has the side effect that now the presence of a name= parameter can
effectively force a content-disposition setting onto a part.
So what should a generating agent do? The first thing to note is that
attempting to cater to any remaining agents that preferentially or exclusively
look to filenames for type information is an exercise in futility: Such agents
are deeply broken along several axes, the most important of which is security.
"Shoot on sight" is the only realistic answer here.
Beyond that I advocate restraint: If there's a way in your application to only
include filename information when it is absolutely necessary, use it. At a
minimum it will save embarassment when that proposal you just sent out doesn't
retain the filename "boondoggle.doc".
Finally, if you have to include filename information, either put it in a
filename= parameter or both a filename= and name= parameter. Never ever use
just a name= parameter because that opens you up to gratuitous interpretation
of the part using some disposition value you didn't intend. (I note in passing
that this is what Thunderbird now dows, with the added nuance of using
nonstandard RFC 2047 encoding for the name= paramter and standard RFC 2231
encoding for the filename= parameter.)
My doubt come also from the following sentence in RFC3851
(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
.. ..... .
3.2.1. The name and filename Parameters
For the application/pkcs7-mime, sending agents SHOULD emit the
optional "name" parameter to the Content-Type field for compatibility
with older systems. Sending agents SHOULD also emit the optional
Content-Disposition field [CONTDISP] with the "filename" parameter.
If a sending agent emits the above parameters, the value of the
parameters SHOULD be a file name with the appropriate extension:
.... ..... ...
where a system using only the name parameter is considered an "old system".
So, I don't understand if "old system" is related to some old S/MIME
system, or to a generic old MIME system....
Unfortunately, given operational realities I would have to characterize this as
somewhere between suboptimal and broken.