Fail to encode attachement filenames properly.

Fail to encode attachement filenames properly.

[Jinhyok Heo]

If I send a non-latin filename attachment, Gnus seems to fail to
encode it properly.

For example, a correct attachement mime part would start like the
following.
,--------------------------------------------
|Content-Type: application/octet-stream;
|        name="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
|Content-Transfer-Encoding: base64
|Content-Disposition: attachment;
|        filename="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
`--------------------------------------------

But my Gnus which I got it from cvs recently makes mime parts like
,--------------------------------------------
|Content-Type: application/octet-stream
|Content-Disposition: attachment;
|  filename*=euc-kr''kin_%bc%b3%b9%ae%c1%f6.hwp
|Content-Transfer-Encoding: base64
`--------------------------------------------

Gnus seems to fail to encode filenames correctly.

-- 
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Fail to encode attachement filenames properly.

[Jesper Harder]

novembre+dated+1020567757.8c22a8@ournature.org (Jinhyok Heo) writes:

> If I send a non-latin filename attachment, Gnus seems to fail to
> encode it properly.
>
> For example, a correct attachement mime part would start like the
> following.
> ,--------------------------------------------
> |Content-Type: application/octet-stream;
> |        name="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
> |Content-Transfer-Encoding: base64
> |Content-Disposition: attachment;
> |        filename="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
> `--------------------------------------------

This is not standards compliant.  The filename parameter should be
encoded using RFC 2231, not an RFC 2047 encoding as in your example.

> But my Gnus which I got it from cvs recently makes mime parts like
> ,--------------------------------------------
> |Content-Type: application/octet-stream
> |Content-Disposition: attachment;
> |  filename*=euc-kr''kin_%bc%b3%b9%ae%c1%f6.hwp
> |Content-Transfer-Encoding: base64
> `--------------------------------------------

This looks correct to me.

Re: Fail to encode attachement filenames properly.

[Jinhyok Heo]

>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:

    JH> novembre+dated+1020567757.8c22a8@ournature.org (Jinhyok Heo) writes:
    >  If I send a non-latin filename attachment, Gnus seems to fail to
    >  encode it properly.
    > 
    >  For example, a correct attachement mime part would start like the
    >  following.
    >  ,--------------------------------------------
    > Content-Type: application/octet-stream;
    >         name="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
    > Content-Transfer-Encoding: base64
    > Content-Disposition: attachment;
    >         filename="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
    >  `--------------------------------------------

    JH> This is not standards compliant.  The filename parameter should be
    JH> encoded using RFC 2231, not an RFC 2047 encoding as in your example.

Well, I didn't know that which one is standard comliant. I appreciate
your information.

The above one was excerpted from a M$-outlook mail.

    >  But my Gnus which I got it from cvs recently makes mime parts like
    >  ,--------------------------------------------
    > Content-Type: application/octet-stream
    > Content-Disposition: attachment;
    >   filename*=euc-kr''kin_%bc%b3%b9%ae%c1%f6.hwp
    > Content-Transfer-Encoding: base64
    >  `--------------------------------------------

    JH> This looks correct to me.

But people who use M$-outlook or many webmails have trouble with
attachments I send to them.

I just have to wait and see for M$-outlook to be standard compliant in
the future?

-- 
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Fail to encode attachement filenames properly.

[Jesper Harder]

novembre+dated+1020732359.ff68e2@ournature.org (Jinhyok Heo) writes:

>>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
>
>     JH> This is not standards compliant.  The filename parameter should be
>     JH> encoded using RFC 2231, not an RFC 2047 encoding as in your example.
>
> Well, I didn't know that which one is standard comliant. I appreciate
> your information.
>
> The above one was excerpted from a M$-outlook mail.

Mozilla used to have the same bug, but I think it was fixed recently --
see <http://bugzilla.mozilla.org/show_bug.cgi?id=63656>

> But people who use M$-outlook or many webmails have trouble with
> attachments I send to them.
>
> I just have to wait and see for M$-outlook to be standard compliant in
> the future?

That could be a long wait :-)  In the mean time

     (defalias 'mail-header-encode-parameter 'rfc2045-encode-string)

should make Gnus use the "wrong" encoding, which Outlook can decode.

Re: Fail to encode attachment filenames properly.

[Jinhyok Heo]

>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:

    JH> That could be a long wait :-)  In the mean time
    JH> (defalias 'mail-header-encode-parameter 'rfc2045-encode-string)
    JH> should make Gnus use the "wrong" encoding, which Outlook can decode.

Your suggestion doesn't solve the problem.

For example, with the setting above. An attachment filename generated
the following.

|Content-Type: application/octet-stream
|Content-Disposition: attachment; filename=020415~~~.hwp
|Content-Transfer-Encoding: base64

Korean characters are not properly encoded. "~~~" part was Korean
letters.

-- 
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Fail to encode attachment filenames properly.

[Jesper Harder]

novembre+dated+1020762014.ee9fa2@ournature.org (Jinhyok Heo) writes:

>>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
>
>     JH> That could be a long wait :-) In the mean time (defalias
>     JH> 'mail-header-encode-parameter 'rfc2045-encode-string) should
>     JH> make Gnus use the "wrong" encoding, which Outlook can decode.
>
> Your suggestion doesn't solve the problem.
>
> For example, with the setting above. An attachment filename generated
> the following.
>
> |Content-Type: application/octet-stream
> |Content-Disposition: attachment; filename=020415~~~.hwp
> |Content-Transfer-Encoding: base64
>
> Korean characters are not properly encoded. "~~~" part was Korean
> letters.

Right, I only tested it with Latin-1 (where it does work).

Does this work for you?

(defun jh-broken-ms-encoding (param value)
  (concat param "=\"" (rfc2047-encode-string value) "\""))

(defalias 'mail-header-encode-parameter 'jh-broken-ms-encoding)

Re: Fail to encode attachment filenames properly.

[Jinhyok Heo]

>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:

    JH> Does this work for you?

    JH> (defun jh-broken-ms-encoding (param value)
    JH> (concat param "=\"" (rfc2047-encode-string value) "\""))

    JH> (defalias 'mail-header-encode-parameter 'jh-broken-ms-encoding)

Yes, it does! Thanks a lot.

Now ugly M$-outlook client(and some webmails) can recognizes my gnus
attachment filenames, though unix pine users come to have problems
with them.

-- 
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk