[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nmh-workers] (no subject)
[Nmh-workers] (no subject)
Thu, 06 Jul 2006 11:49:44 -0700
djh <address@hidden> wrote:
> [K o works, but K a doesn't.]
> (1) One is that using
> (filename with an * appended causes output to not use the given
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)! 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 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
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
> Wrote /tmp/FuncTechSpec_I0007-00_Delivery data
> 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.
> address@hidden: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
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).
Bill Wohler <address@hidden> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
- [Nmh-workers] (no subject),
Bill Wohler <=