Mime types and attached files

Mime types and attached files

[Fabrice Popineau]

I have send an email with an msword (sorry!) file attached. The file
name has non ascii chars and it was sent using these lines:

--=-=-=
Content-Type: application/msword
Content-Disposition: attachment;
 filename*=iso-8859-1''IIC%20p79%20%e0%2089%20-%202005.DOC
Content-Transfer-Encoding: base64

It seems to me that it is valid according to rfc 2183/2184. I just wonder
about the empty '' (could be 'fr' instead, but don't know where
to change that).

However, the file has been received on an xp box using outlook 2003 and
the filename has not been restored properly. It has been replaced by
ATT<some number>.DOC . 

Outlook maybe broken, but is there a way to get around the problem ?

Slightly related. I had to add these lines:

(add-to-list 'mailcap-mime-extensions
	     '(".doc" . "application/msword"))
(add-to-list 'mailcap-mime-extensions
	     '(".ppt" . "application/mspowerpoint"))

to be able to send msword/mspowerpoint files tagged with something else
than octet-stream ;-)

-- 
Fabrice

Re: Mime types and attached files

[Lars Magne Ingebrigtsen]

Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:

> I have send an email with an msword (sorry!) file attached. The file
> name has non ascii chars and it was sent using these lines:
>
> --=-=-=
> Content-Type: application/msword
> Content-Disposition: attachment;
>  filename*=iso-8859-1''IIC%20p79%20%e0%2089%20-%202005.DOC

Gnus uses RFC2231 encoding for non-ascii text in the MIME parameters,
which is, er, correct.  However, it's unusual.

I'm sort of leaning towards switching over to using quoted-printable
here instead of RFC2231 to get interoperability with...  a lot of the
world.

Does Thunderbird understand RFC2231, for instance?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Mime types and attached files

[Katsumi Yamaoka]

>>>>> In <m3bqv49thn.fsf@quimbies.gnus.org>
>>>>>	Lars Magne Ingebrigtsen wrote:

> Fabrice Popineau <Fabrice.Popineau@supelec.fr> writes:

>> I have send an email with an msword (sorry!) file attached. The file
>> name has non ascii chars and it was sent using these lines:
>>
>> --=-=-=
>> Content-Type: application/msword
>> Content-Disposition: attachment;
>>  filename*=iso-8859-1''IIC%20p79%20%e0%2089%20-%202005.DOC

> Gnus uses RFC2231 encoding for non-ascii text in the MIME parameters,
> which is, er, correct.  However, it's unusual.

> I'm sort of leaning towards switching over to using quoted-printable
> here instead of RFC2231 to get interoperability with...  a lot of the
> world.

Yes, most of Windoze mailers don't support RFC2231.  Instead,
they use the complacent RFC2047-like encoding.  Gnus can decode
both styles of encoded file names.  That's good.  However, I
must evaluate the form[1]

(defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)

when sending files with Japanese names in business.  That's very
annoying, though I never want to make it the default (so, I
restore it into `rfc2231-encode-string' after sending a mail).

> Does Thunderbird understand RFC2231, for instance?

Yes, it does.  However, the encoder has a bug[2] in the released
version.

[1] (info "(emacs-mime)rfc2047")
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=323318

Re: Mime types and attached files

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> However, I must evaluate the form[1]
>
> (defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)
>
> when sending files with Japanese names in business.  That's very
> annoying, though I never want to make it the default (so, I
> restore it into `rfc2231-encode-string' after sending a mail).

Well -- why not make it the default?  We know that a large number of
mail readers out there don't support RFC2231, and we know that most
mail readers support RFC2047 parameter decoding.  (Are there any that
don't?  I mean, that don't support RFC2047 parameter encoding, but do
support RFC2231?)

So to make life easier for everybody I propose making
`rfc2047-encode-parameter' the default.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Mime types and attached files

[Katsumi Yamaoka]

>>>>> In <m3vet8o9ms.fsf@quimbies.gnus.org>
>>>>>	Lars Magne Ingebrigtsen wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> However, I must evaluate the form[1]
>>
>> (defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)
>>
>> when sending files with Japanese names in business.  That's very
>> annoying, though I never want to make it the default (so, I
>> restore it into `rfc2231-encode-string' after sending a mail).

> Well -- why not make it the default?  We know that a large number of
> mail readers out there don't support RFC2231, and we know that most
> mail readers support RFC2047 parameter decoding.  (Are there any that
> don't?  I mean, that don't support RFC2047 parameter encoding, but do
> support RFC2231?)

The reasons I wouldn't like to make it the default are:

The RFC2047-like encoding has not been documented as a standard
as far as I know.  I don't know how it has been decided
reasonably and democratically.  The specification doesn't seem
to have been unified in mailers that use it.  For instance, I
heard that some mailer works with a parameter in which a long
encoded file name is folded but others don't.  Because of this,
I designed `rfc2047-encode-parameter' so as not to fold an
encoded file name no matter how it is long.  Therefore, it
potentially violates the rule that maximum length of lines is
restricted by some RFCs.

> So to make life easier for everybody I propose making
> `rfc2047-encode-parameter' the default.

I swim with the tide. ;-)  I wish it weren't an obstruction to
Thunderbird's lofty ambition, though.

Re: Mime types and attached files

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The RFC2047-like encoding has not been documented as a standard
> as far as I know.  I don't know how it has been decided
> reasonably and democratically.  The specification doesn't seem
> to have been unified in mailers that use it.

True.  It would be a shame to switch to RFC2047 parameter encoding if
all the other mailers are finally switching to RFC2231.

Has anybody here kept up with IETF discussions on this matter, if any?
What would be the most likely working group dealing with this?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Mime types and attached files

[gdt]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>> However, I must evaluate the form[1]
>>
>> (defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)
>>
>> when sending files with Japanese names in business.  That's very
>> annoying, though I never want to make it the default (so, I
>> restore it into `rfc2231-encode-string' after sending a mail).
>
> Well -- why not make it the default?  We know that a large number of
> mail readers out there don't support RFC2231, and we know that most
> mail readers support RFC2047 parameter decoding.  (Are there any that
> don't?  I mean, that don't support RFC2047 parameter encoding, but do
> support RFC2231?)
>
> So to make life easier for everybody I propose making
> `rfc2047-encode-parameter' the default.

It would be cool to have BBDB notice MUAs used by correspondents and
record them all, and have a function to choose an encoding based on
that.  That way the standards could still be followed by default, with
accomodation for lame/unstandard MUAs.  But not everyone uses BBDB.

-- 
	Greg Troxel <gdt@work.lexort.com>

Re: Mime types and attached files

[Lars Magne Ingebrigtsen]

gdt@work.lexort.com writes:

> It would be cool to have BBDB notice MUAs used by correspondents and
> record them all, and have a function to choose an encoding based on
> that.  That way the standards could still be followed by default, with
> accomodation for lame/unstandard MUAs.

It wouldn't solve the problem of sending to multiple recipients,
forwarding, mailing lists, newsgroups, etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen