nmh-workers
[Top] [All Lists]

[Nmh-workers] (no subject)

2006-07-06 11:50:06
djh <henman@it.to-be.co.jp> wrote:

[K o works, but K a doesn't.]

  (1) One is that using 
                filename*=   
      (filename with an * appended causes output to not use the given
      filename.

I wasn't familiar with this syntax, so I looked and found it is
described in RFC 2231. Please create a feature request for this in GNU
mailutils. The nmh version I have (1.1) doesn't even support
Content-Disposition (RFC 2183[2])! I'll post a feature request there.

  (2) When filename=".......japanese characters in it like ..."
        (double quoates)  filename="=?ISO-2022-JP........  "
        is used the name isn't converted back to a natual iso-2022
        string, before creating and writing the file.

Interestingly, RFC 2231 emphasizes that RFC 2047[3] encodings are NOT
allowed here, so whatever MUA generated these parameters is in err. That
Gnus (K o) handled it means that they took the "be liberal in what you
receive" philosophy to heart (unless someone can cite an RFC that allows
RFC 2047 encodings in parameters. It would be prudent for nmh to do the
same thing.

This problem seems to be related to the RFC 2047 encoding problem you
reported earlier. I had responded with (before I realized that RFC 2047
encodings were not allowed in MIME parameters, or at least, they aren't
meant to be interpreted there):

mhn: Cannot open output stream (file
/cygdrive/c/tmp/FuncTechSpec_I0007-00_Delivery data
=?ISO-2022-JP?B?ZG93bmxvYWQbJEIhShsoQndlYhskQiFLGyhCXw==?=
=?ISO-2022-JP?B?cjMuMl8wNTExMjhwbV9FbmcuZG9j?=): No such file or
directory

Interesting, I don't see any characters in there that would be illegal
filename characters in Windows. Do you?

I created an attachment with the same filename. When I used "K o", then
the RFC 2047 encodings were decoded by MH-E/Gnus before creating the
filename.

    Wrote /tmp/FuncTechSpec_I0007-00_Delivery data
    download(web)_r3.2_051128pm_Eng.doc

When I used "K a", mhstore saved the file with the RFC 2047 encodings.
It seems to me that nmh and mailutils should be decoding the RFC 2047
encodings in the Content-Type and Content-Disposition header fields
before attempting to save the file.

    [wohler@olgas:946]$ mhstore -auto 13749 +outbox
    storing message 13749 part 1 as file Photo_062306_001.jpg
    storing message 13749 part 2 as file FuncTechSpec_I0007-00_Delivery data 
=?ISO-2022-JP?B?ZG93bmxvYWQbJEIhShsoQndlYhskQiFLGyhCXw==?= 
=?ISO-2022-JP?B?cjMuMl8wNTExMjhwbV9FbmcuZG9j?=

Thoughts?

At any rate, there doesn't appear to be any problems in MH-E. These are
caused by deficiencies in nmh and mailutils (and another naughty MUA out
there inserting RFC 2047 encodings in parameters).

1. ftp://ftp.rfc-editor.org/in-notes/rfc2231.txt
2. ftp://ftp.rfc-editor.org/in-notes/rfc2183.txt
3. ftp://ftp.rfc-editor.org/in-notes/rfc2047.txt

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD


_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>