On Wed, Jan 03, 2007 at 02:10:24PM +0100, Tom Kistner wrote:
> Alexander Shikoff wrote:
>
> > Content-Disposition: attachment; filename*=koi8-u''%D4%C5%D3%D4%2Epps
>
> The problem is the asterisk after the 'filename' tag.
>
> This is defined in RFC 2231 "MIME Parameter Value and Encoded Word
> Extensions" as a mechanism to specify character set information. Exim
> does not currently support the MIME extensions of this RFC.
>
> Exim does support decoding RFC 2047 encoded MIME words via the ${rfc2047
> expansion operator, however.
>
> I just went to read RFC 2231 and it says:
>
> IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when
> they actually are used. As such, these mechanisms should not be used
> lightly; they should be reserved for situations where a real need for
> them exists.
>
> However I don't see the need for this mechanism when RFC 2047 exists ...
>
> Is it just mutt producing such headers?
Thanks for a detailed explanation!
It looks like that not only mutt can produce such headers. Now I'm trying
to obtain more examples with other MUAs.
Unfortunately it seems that mutt cannot produce RFC 2047 headers at all.
It uses RFC 2231 encoding by default:
from man muttrc:
rfc2047_parameters
Type: boolean
Default: no
When this variable is set, Mutt will decode RFC-2047-encoded
MIME parameters. You want to set this variable when mutt sug-
gests you to save attachments to files named like this:
=?iso-8859-1?Q?file=5F=E4=5F991116=2Ezip?=
[...]
Also note that setting this parameter will not have the effect
that mutt generates this kind of encoding. Instead, mutt will
unconditionally use the encoding specified in RFC 2231.
[...]
--
Kind Regards, Alexander Shikoff
minotaur@???
Mob.: +380 67 946 31 49
