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 (PDT)
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