Re: name and filename parameters
ned+ietf-smtp@mrochek.com Sun, 22 June 2008 18:40 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 m5MIe0f4048528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 11:40:00 -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 m5MIe08h048525; Sun, 22 Jun 2008 11:40:00 -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 mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m5MIdwCi048508 for <ietf-smtp@imc.org>; Sun, 22 Jun 2008 11:39:58 -0700 (MST) (envelope-from ned+ietf-smtp@mrochek.com)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MWAH9R4XPS00BFB7@mauve.mrochek.com> for ietf-smtp@imc.org; Sun, 22 Jun 2008 11:39:56 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MW8083QKZ400007A@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-smtp@imc.org; Sun, 22 Jun 2008 11:39:51 -0700 (PDT)
Date: Sat, 21 Jun 2008 14:39:07 -0700
From: ned+ietf-smtp@mrochek.com
Subject: Re: name and filename parameters
In-reply-to: "Your message dated Sat, 21 Jun 2008 14:52:38 +0200" <01MW9A0NEWP08WWGUF@mx.isti.cnr.it>
To: Francesco Gennai <francesco.gennai@isti.cnr.it>
Cc: ietf-smtp@imc.org
Message-id: <01MWAH9OW9VO00007A@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
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>
> 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
- Re: name and filename parameters Francesco Gennai
- Re: name and filename parameters ned+ietf-smtp
- Re: name and filename parameters Keith Moore
- name and filename parameters Francesco Gennai