Re: name and filename parameters

Francesco Gennai <francesco.gennai@isti.cnr.it> Mon, 23 June 2008 12:35 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NCZ9Hx024286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 05:35:09 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m5NCZ9GC024285; Mon, 23 Jun 2008 05:35:09 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from ITANIUM.ISTI.CNR.IT (mx4.isti.cnr.it [194.119.192.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5NCZ7mg024278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-smtp@imc.org>; Mon, 23 Jun 2008 05:35:09 -0700 (MST) (envelope-from francesco.gennai@isti.cnr.it)
Received: from mx.isti.cnr.it by mx.isti.cnr.it (PMDF V6.4-beta #31598) id <01MWC0ZN5QDC8WWXI8@mx.isti.cnr.it> for ietf-smtp@imc.org; Mon, 23 Jun 2008 14:33:54 +0200
Date: Mon, 23 Jun 2008 14:25:05 +0200
From: Francesco Gennai <francesco.gennai@isti.cnr.it>
Subject: Re: name and filename parameters
In-reply-to: "Your message dated Sat, 21 Jun 2008 14:39:07 -0700 (PDT)" <01MWAH9OW9VO00007A@mauve.mrochek.com>
To: ietf-smtp@imc.org
Message-id: <01MWC1MTUKN88WWXI8@mx.isti.cnr.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Content-transfer-encoding: 7bit
References: <01MW9A0NEWP08WWGUF@mx.isti.cnr.it>
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

Thank you Ned and Keith for the clear description.

Francesco

> > Question about composing a MIME part where I would suggest
> > also the file name.

> > Question:
> > 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
> disposition value.

> 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
> >                          Message Specification):

> > .. ..... .
> > 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.

> 				Ned