Subject: How to decipher mail headers from NIFTY with VM 5.35?

From: [email-masked] (Masahiro KITAGAWA)
Date: 13 Nov 93 08:48:59 GMT

NEmacs 3.3.2 + VM 5.35 でメールを読んでるのですが、NIFTYから来るメール
の From: とか Subject: を簡単に解読する方法が分からず、困っています。

この辺りに投稿された記事を見て、何も考えずに tiny-mime.el 2.2 を load 
して、mime/decode-message-header とか mime/decode-region とかやってみ
ましたが、

Buffer is read-only: #<buffer INBOX>

で、駄目でした。メールを一旦他のファイルにセーブしてmime/decode-region
すれば一応読めますが、こんなことを一々やっているわけには行かないので、
もっと自動的にやる方法を探しています。何か良い方法をご存知でしたら、教
えて下さい。

ここまでは質問です。本当に困っていますので、よろしくお願いします。

ここからは、この実験に対する率直な感想です。勘違いもあるかもしれません。

=?ISO-2022-JP?B?GyRAJFwkZCQtO08kYRsoSg==?=

NIFTYとメールがやり取りできるのは非常に便利だし、日本語のSubjectもあり
がたいのですが、何も受け入れ準備とか予備知識の無いところに突然、「従来
の方法では解読不可能な」Subject:とかFrom:を持ったメールを送りつけると
いうのは、かなり乱暴な実験ですね。こういう無神経なやり方には、MIMEの是
非とかいう以前に実験のやり方そのものに疑問を感じてしまいます。

NIFTY側では、現状では相手がSubject:もFrom:も読めない可能性が高いという
ことが十分に広報されているのでしょうか。

WIDE側では、少なくとも比較的良く使われているメールリーダでNIFTYからの
mail headerを「簡単に」解読するためのキットを準備してanonymous ftp等で
配布するとか、解読不可能なメールを受け取る可能性のある人たちの混乱や精
神的苦痛を避けるために実験中頻繁に広報を行うという必要性は認めておられ
ないのでしょうか。

そもそも、この実験に関する意見、質問、苦情等は何処で受け付けているので
しょうか。(もちろんfj.mailじゃないよね。) フィードバックや参加者からの
評価があった方が有意義な実験ができると思いますが。

どうも、不特定多数を巻き込んだ大がかりな実験にしては、広報が不足してい
るような気がするのは、私だけでしょうか。

私がこの実験に関する事情をよく知らないために見当違いな批判をしていると
したら、お許し下さい。もちろん、実験そのものに反対しているわけではあり
ません。

=?ISO-2022-JP?B?GyRAJFwkZCQtPSokahsoSg==?=
--
Masahiro Kitagawa <[email-masked]>     北川 勝浩
Electric Eng., Engineering Science, Osaka Univ.  阪大・基礎工・電気

---

From: [email-masked] (Masatoshi Watanabe)
Date: 14 Nov 1993 07:31:22 GMT

まず最初に知人の作品の宣伝をしておきます。addmail の Version 1.9.0 以
降は MIME ヘッダをサポートしています。最新版は 1.10.0 で、anonymous
ftp で goku.ecip.tohoku.ac.jp からで入手できます。

<[email-masked]>の記事において
[email-masked]。

| NIFTYとメールがやり取りできるのは非常に便利だし、日本語のSubjectもあり
| がたいのですが、何も受け入れ準備とか予備知識の無いところに突然、「従来
| の方法では解読不可能な」Subject:とかFrom:を持ったメールを送りつけると
| いうのは、かなり乱暴な実験ですね。こういう無神経なやり方には、MIMEの是
| 非とかいう以前に実験のやり方そのものに疑問を感じてしまいます。

NIFTY では以前から差し出し人名や題目に漢字の使用が認められていました。
インターネット上では From: や Subject: に漢字を使用してもそのまま届く
とは限らず、また届いたとしても読めるとは限らないので漢字の使用は好まし
くないと言われてきました。

このような状況で NIFTY とインターネット上での mail の相互交換の実験を
行なうとき、どのようにすれば無神経でも乱暴でもないと言えるでしょうか？
私が思いつく方法としては、

1. NIFTY からインターネットにヘッダーに漢字を含む mail を出そうとして
   も、システムから警告されて出せないようにする。

2. 化けようが読めなかろうがそんなことは気にせずヘッダに漢字コードを含
   んだまま送る。

3. せめてきちんと届き、手段さえあれば読めるように MIME 形式にエンコー
   ドしてから送る。

4. 漢字からローマ字に変換して (どうやって？) から送る。

まぁ、3 番目がいちばんマトモなような気がします。どんな方法をとっても、
なんらかの制限が生じるのはしかたない事ですが、そういった事をもっと広報
して欲しいという事なのでしょうね。

もっとも、あくまでも WIDE と NIFTY の間の実験であって、利用者に対する
サービスではないので、それを利用する人間が、「漢字のヘッダを簡単に解読
するためのキットくらい用意しろ。」なんてのは言いすぎのように思えます。

| そもそも、この実験に関する意見、質問、苦情等は何処で受け付けているので
| しょうか。(もちろんfj.mailじゃないよね。) フィードバックや参加者からの
| 評価があった方が有意義な実験ができると思いますが。

普通に考えると、メイルに関する連絡先はそのドメインの postmaster ですか
ら、[email-masked] や [email-masked] なのでは？

======================================================================
 Masatoshi        Chemical Metallurgy Lab., Department of Metallurgy,
      Watanabe    Faculty of Engineering, Tohoku Univ., Sendai, Japan
======================================================================

---

From: [email-masked] (Hironobu SUZUKI)
Date: 14 Nov 93 11:33:59 GMT

>>3. せめてきちんと届き、手段さえあれば読めるように MIME 形式にエンコー

ちょっと議論とは外れて申し訳ありません。

NIFTYのFrom行ではメールアドレスを改行して入れてあるので、From行から自
動的にメールを返送するアドレスを取るシステムは、たぶん殆どエラーになっ
ていると思います。

MIME形式に関してのコメントは何もありませんが、ただインプリメントの際に
後ろに追加する形でやれば何の問題もなかったのに！と思います。インプリメ
ンターの配慮が足りないのが残念です。

						ひろのぶ

---

From: [email-masked] (Masahiro KITAGAWA)
Date: 14 Nov 93 07:46:42 GMT

>>>>> "北川" == Masahiro KITAGAWA <[email-masked]> writes:
In article <[email-masked]>

    北川> NEmacs 3.3.2 + VM 5.35 でメールを読んでるのですが、NIFTYから
    北川> 来るメールの From: とか Subject: を簡単に解読する方法が分か
    北川> らず、困っています。

力武さんのVM 4.41用tiny-mimeパッチ等を参考にさせていただいて、何とか自
己解決できました。他にもっと良い方法があるかもしれませんが、一応御報告
しておきます。素人がにわかに考えたものなので、引続き正解募集中です。

基本的には、vm-page.elのvm-preview-current-messageの最後に
vm-preview-message-hookというhookを入れて置いて、‾/.emacs等で

;;; Automatic mime header decoding for VM 5.35 with tiny-mime.el
(setq vm-preview-message-hook
      '(lambda ()
	 (toggle-read-only)
	 (mime/decode-message-header)
	 (toggle-read-only)
	 ))

と指定するという方法です。toggle-read-onlyは

    北川> Buffer is read-only: #<buffer INBOX>

というエラーを避けるために必要でした。これで、一応NIFTYからのメールの
SubjectとFromが自動的に解読できるようになりました。

以下に、VM 5.35 に対する patch を付けます。vm-show-message-hook の方は
今の所使っていません。

*** vm-vars.el.orig	Sun Nov 14 16:10:09 1993
--- vm-vars.el	Sun Nov 14 15:43:10 1993
***************
*** 15,20 ****
--- 15,22 ----
  ;;; along with this program; if not, write to the Free Software
  ;;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  
+ (require 'tiny-mime)
+ 
  (defvar vm-primary-inbox "‾/INBOX"
    "*Mail is moved from the system mailbox to this file for reading.")
  
*** vm-page.el.orig	Mon Apr 12 12:04:50 1993
--- vm-page.el	Sun Nov 14 15:44:11 1993
***************
*** 185,191 ****
  	       (not (vm-new-flag (car vm-message-pointer)))
  	       (not (vm-unread-flag (car vm-message-pointer)))))
        (vm-show-current-message)
!     (vm-update-summary-and-mode-line)))
  
  (defun vm-show-current-message ()
    (setq vm-system-state 'showing)
--- 185,192 ----
  	       (not (vm-new-flag (car vm-message-pointer)))
  	       (not (vm-unread-flag (car vm-message-pointer)))))
        (vm-show-current-message)
!     (vm-update-summary-and-mode-line))
!   (run-hooks 'vm-preview-message-hook))
  
  (defun vm-show-current-message ()
    (setq vm-system-state 'showing)
***************
*** 205,211 ****
  	 (vm-set-new-flag (car vm-message-pointer) nil))
  	((vm-unread-flag (car vm-message-pointer))
  	 (vm-set-unread-flag (car vm-message-pointer) nil)))
!   (vm-update-summary-and-mode-line))
  
  (defun vm-expose-hidden-headers ()
    "Toggle exposing and hiding message headers that are normally not visible."
--- 206,213 ----
  	 (vm-set-new-flag (car vm-message-pointer) nil))
  	((vm-unread-flag (car vm-message-pointer))
  	 (vm-set-unread-flag (car vm-message-pointer) nil)))
!   (vm-update-summary-and-mode-line)
!   (run-hooks 'vm-show-message-hook))
  
  (defun vm-expose-hidden-headers ()
    "Toggle exposing and hiding message headers that are normally not visible."

---

From: [email-masked] (Masahiro KITAGAWA)
Date: 14 Nov 93 13:18:02 GMT

メールで色々教えていただき、fj.sourcesに投稿された

| From: [email-masked] (Kenji WAKAMIYA)
| Subject: VM-5.35W: MIME and POP supporting patch for VM-5.35
| Date: 5 Oct 93 12:04:37 GMT

というのを送っていただきました。どうもありがとうございました。こちらは、
本格的でmetamailとかmime.elを使うもののようです。ちょっと、「簡単に」
という私の当初の目的からは外れるのですが、実は mime header の surprise
attack を受けた時に、わけ分からずmetamailもmime.elもinstallしてしまっ
たので、ついでに試してみました。

前の記事のtiny-mimeを使った方も、このVM-5.35Wも decodeに関してはあまり
問題は無いようでした。しかし、送信の方はどちらも encode 時に勝手に改行
してしまって失敗することがありました。手で編集して改行を除けば、一応
localには問題なく送信できました。

-------------------------------------------------
encode時の改行を禁止する方法があれば良いのですが。
-------------------------------------------------

もうひとつencodeで気になるのは、日本語とalphabetとの間に空白が挿入され
るということです。しかも、それがmime.elとtiny-mime.elで異なります。例
えば、tiny-mimeを使って、

Subject: (日a本5)

をencodeすると

Subject: ( =?ISO-2022-JP?B?GyRARnwbKEo=?= a =?ISO-2022-JP?B?GyRAS1wbKEo=?= 5)

となり、この時点で日本語の前後に空白が挿入されます。同じtiny-mimeで
decodeしても

Subject: ( 日 a 本 5)

となって、元の文字列には戻りません。これは問題ないのでしょうか。

元のheaderを、mime.elのmime-modeで M-x mime-translate-headerした場合は、

Subject: (=?ISO-2022-JP?B?GyRARnwbKEo=?= a=?ISO-2022-JP?B?GyRAS1wbKEo=?= 5)

となり、今度は日本語の後だけに空白が入ります。tiny-mime.elでdecodeすると

Subject: (日 a本 5)

となります。どれが正しい動作なのでしょうか。頭が混乱してしまった。
--
Masahiro Kitagawa <[email-masked]>     北川 勝浩
Electric Eng., Engineering Science, Osaka Univ.  阪大・基礎工・電気

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Mon, 15 Nov 1993 08:11:15 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Masahiro KITAGAWA) 氏曰く、

北川> 前の記事のtiny-mimeを使った方も、このVM-5.35Wも decodeに関してはあまり
北川> 問題は無いようでした。しかし、送信の方はどちらも encode 時に勝手に改行
北川> してしまって失敗することがありました。手で編集して改行を除けば、一応
北川> localには問題なく送信できました。

  RFC 1522 では、各行は 76 桁以内、encoded-word の長さは 75 文字以内で
あることが求められています。

  RFC 822 では、空白を折り返しで自由に置き換えられるはずですから、正し
く作られた tool ならば、大丈夫なはずで、折り返しを受理しない tool には
改善が求められます。

----------------------------------------------------------------------
* RFC 822 より

3.1.1.  Long Header Fields

  各 header field は、field-name と field-body からなる、1 つの、論理
的な ASCII 文字の列として現される。便宜上、field-body は、この概念上の
存在に分けられ、それは、複数行の表現に分割することができる；これは、
``folding'' と呼ばれる。linear-white-space（単なる LWSP-chars ではない）
は、少なくとも一つの LWSP-char が直後に続く CRLF の挿入によって代用さ
れる、一般的な規則が存在する。このような、単一行は、

            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN

次のように表すことができる：

            To:  "Joe & J. Harvey" <ddd @ Org>,
                    JJV@BBN
----------------------------------------------------------------------

北川> もうひとつencodeで気になるのは、日本語とalphabetとの間に空白が挿入され
北川> るということです。しかも、それがmime.elとtiny-mime.elで異なります。
（略）
北川> となって、元の文字列には戻りません。これは問題ないのでしょうか。
（略）
北川> となります。どれが正しい動作なのでしょうか。頭が混乱してしまった。

  metamail は RFC 1432 という古い MIME の規格にしたがっています。

  MIME header では、ASCII からなる word と encoded-word の間には空白が
必要です。RFC 1342 では encoded-word の後にのみ linear-white-space 
（空白、または、改行＋空白）が必要でした。よって、RFC 1432 に従えば、

北川> Subject: (日a本5)

を encode すると、

北川> Subject: (=?ISO-2022-JP?B?GyRARnwbKEo=?= a=?ISO-2022-JP?B?GyRAS1wbKEo=?= 5)

となり、encoded-word の後だけに空白が入ります。そして、

  しかし、RFC 1522 では、encoded-word の前後に必要になりました。よって、

北川> Subject: ( =?ISO-2022-JP?B?GyRARnwbKEo=?= a =?ISO-2022-JP?B?GyRAS1wbKEo=?= 5)

となり、encoded-word の前後に空白が挿入されます。

  また、RFC 1342 では、decode する時、encoded-word の直後の 
linear-white-space は表示されませんでしたが、RFC 1522 では、表示します。
よって、

北川> Subject: ( =?ISO-2022-JP?B?GyRARnwbKEo=?= a =?ISO-2022-JP?B?GyRAS1wbKEo=?= 5)

を decode すると、

北川> Subject: ( 日 a 本 5)

となります。

  RFC 1522 では encoded-word は word とおんなじだと思えば良いです。

  それから、このことから、comment の ``('' の後、``)'' の前の 
encoded-word との間の空白は必要無いことになります。

  また、空白がないということを伝えることができなくなります。このための
良い方法（できたら、encoder/decoder が構文解析せずに済む楽な方法）が欲
しいところです。

┏『健康と美容のために食後に一杯の紅茶』━━━━━━━━━━━━━━┓
┃                    守岡 知彦 (MORIOKA Tomohiko)                  ┃
┃　                                    Email: <[email-masked]>┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

---

From: [email-masked] (Kim Tong Ho)
Date: Sun, 14 Nov 1993 03:05:07 GMT

>の From: とか Subject: を簡単に解読する方法が分からず、困っています。

NIFTYのユーザに、

	文字化けして :-) 読めないから、
	Subject: はローマ字で書いてちょ

とお願いする。また、From: についても

	FROM: YAMADA TAROU

という行を本文中に埋め込めば変更することができます。ただし、この機能は会
員情報を公開にセットしてるユーザのみ利用可能です。

>NIFTY側では、現状では相手がSubject:もFrom:も読めない可能性が高いという

私の知る限り、ほとんど広報されていないように見受けられます。

>神的苦痛を避けるために実験中頻繁に広報を行うという必要性は認めておられ

別にNIFTYじゃなくても、Subject: に日本語書いて送ってよこす人はたくさんい
ますよ。無事に届くのもあるし、エスケープ落ちてるのもあるし、グシャグシャ
になってるのもあるし。精神的苦痛うんぬんという問題ではないと思います。

>評価があった方が有意義な実験ができると思いますが。

NIFTY側の利用者に対しては、無作為抽出(?)でアンケートを実施しているようで
す。

>どうも、不特定多数を巻き込んだ大がかりな実験にしては、広報が不足してい

それも実験の一部だったりして。

--
金 東虎

---

From: [email-masked] (Masataka Ohta)
Date: 17 Nov 93 03:07:10 GMT

>3. せめてきちんと届き、手段さえあれば読めるように MIME 形式にエンコー

　いまだにＭＩＭＥじゃないときちんと届かないと思ってる馬鹿がいるのか、、、

>まず最初に知人の作品の宣伝をしておきます。

　それとも、知ってて宣伝のために嘘書いてるのか、、、

					太田　昌孝
					[email-masked]

---

From: [email-masked] (ITO Takayuki)
Date: Wed, 17 Nov 1993 07:28:55 GMT

>しておきます。素人がにわかに考えたものなので、引続き正解募集中です。

  参考になるかわかりませんが、私はVM 4.41で

(setq vm-mode-hooks
	(list '(lambda ()
		(mime/decode-region (point-min) (point-max)))))

としています。パッチはあてていません。

--
				東京大学 理学部 情報科学科 ４年
				伊藤隆幸 <[email-masked]>

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Wed, 17 Nov 1993 09:32:52 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (ITO Takayuki) 氏曰く、

伊藤> In article <[email-masked]> 

>しておきます。素人がにわかに考えたものなので、引続き正解募集中です。

伊藤>   参考になるかわかりませんが、私はVM 4.41で

伊藤> (setq vm-mode-hooks
伊藤> 	(list '(lambda ()
伊藤> 		(mime/decode-region (point-min) (point-max)))))

伊藤> としています。パッチはあてていません。

  mime/decode-region より mime/decode-message-header を使うことをお勧
めします。（確かに、こうすると本文中に残った encoded-word も decode さ
れるから良いのかも知れないけど）

  mime-kit の場合は、(mime/decode-message-header t t) とかして下さい。

---

From: [email-masked] (Masahiro KITAGAWA)
Date: 18 Nov 93 04:46:34 GMT

メール、ニュースでのフォローをありがとうございました。

>>>>> "MW" == Masatoshi Watanabe <[email-masked]> writes:

  MW> どんな方法をとっても、なんらかの制限が生じるのはしかたない事ですが、
  MW> そういった事をもっと広報して欲しいという事なのでしょうね。

はい、その通りです。私は時々fjも読んでいるおかげで、このヘッダが何であ
るのか分かりましたし、時間も手間も頭も使いましたが、結局ニュース上の情
報のおかげで自分で解決することができました。しかし、ニュースを読んでい
なければ、

>>>>> "Kim" == Kim Tong Ho <[email-masked]> writes:
In article <[email-masked]>

  Kim> NIFTYのユーザに、
  Kim> 	文字化けして :-) 読めないから、	Subject: はローマ字で書いてちょ
  Kim> とお願いする。

しか無かったと思います。他の人、特にニュースを読まない人がどうやって情
報を手に入れ、どうやって解決しているのか興味がありますね。例えニュース
から情報を手に入れたとしても、まだ解決できずに苦労している人も沢山いる
でしょうし、ユーザにつきあげられて困っている管理者もいるかもしれません。
もちろん、別に苦労して読めるようにする必要はないという立場もあるでしょ
うけど。

  MW> もっとも、あくまでも WIDE と NIFTY の間の実験であって、利用者に
  MW> 対するサービスではないので、それを利用する人間が、「漢字のヘッダ
  MW> を簡単に解読するためのキットくらい用意しろ。」なんてのは言いすぎ
  MW> のように思えます。

「用意しろ」とまでは言ってませんが、ここはちょっと異論があります。この
場合、利用者＝被験者であって、実験の重要な構成要素のはずです。実験に参
加するのに必要な情報やノウハウを被験者に提供することが過剰であるとは思
いません。例え、情報やノウハウ（キット、パッチ等）を提供しても、それを
実際にインストールするという作業を行うのは被験者なのですから。

少なくとも、Niftyから来るメールの何処かに、「この実験について詳しく知
りたければ、どこそこへメールを出せば、自動応答が得られる。」くらいの最
小限のポインタを入れておいて、自動応答ではヘッダのdecode方法について言
及すべきだと思います。

おそらく、このくらいのことは当然考えていたけどリソースが足りないからで
きない、広報についても同じ、ということなんでしょうね。

結果的には、「これは実験であって、Internet側では何も情報を提供しなくて
もヘッダの文字列がMIMEであることが分かりdecodeできる専門家だけを対象と
している。その他大勢は、シャドウ・ユーザであって、ヘッダが何だか分から
なくても、使いたければ黙って使えばよろしい。」という感じにに見えますね。

  Kim> それも実験の一部だったりして。

これは私も考えました。そういえば、ネットワークを使ってそういうのを研究
している心理学者もいるし、研究されてしまったこともあったな。

  Kim> NIFTY側の利用者に対しては、無作為抽出(?)でアンケートを実施して
  Kim> いるようです。

おや、Nifty側には余裕があったのか。

私の意見は十分述べましたし、NiftyからのメールヘッダをVMで簡単に解読し
たいという初期の目的も達成できましたので、Niftyの話しはこれで終りにし
ます。

まぁ、Internet側で日本語のSubject:についての扱いが遅れていたのは事実で
すから、Niftyからのメールが黒船になって、この辺りの技術が進歩すれば、
望ましい展開と言えるのかもしれません。やはり fj.mail.mime が要るかな。
--
Masahiro Kitagawa <[email-masked]>     北川 勝浩
Electric Eng., Engineering Science, Osaka Univ.  阪大・基礎工・電気

---

From: [email-masked] (Masahiro KITAGAWA)
Date: 18 Nov 93 06:07:06 GMT

# 守岡さんのドキュメントは、VM5.35 と tiny-mime を組み合わせる時に
# 参考になりました。read-onlyのbuffer上でdecodeできず悩みましたが:-)

>>>>> "TM" == 守岡 知彦 (MORIOKA Tomohiko) <[email-masked]> writes:
In article <[email-masked]>

  TM>   RFC 1522 では、各行は 76 桁以内、encoded-word の長さは 75 文字
  TM> 以内であることが求められています。

ということは、やはり encoder が改行していたわけですね。

  TM>   RFC 822 では、空白を折り返しで自由に置き換えられるはずですから、
  TM> 正しく作られた tool ならば、大丈夫なはずで、折り返しを受理しない 
  TM> tool には改善が求められます。

そうだとしても、単なるユーザは改善されるのを待つしかないわけですね。取
り敢えず、改行を消せばうまく届くことが分かっていても、RFC1522 に反する
からやってはいけないということになるのでしょうか？

私は Internet experimenter でも network engineer でも無いので、もはや
RFC を読む気はないのですが、RFC1522 の status は required なんでしょう
か。RFC を引く場合は、status を明示していただければ幸いです。

  北川> もうひとつencodeで気になるのは、日本語とalphabetとの間に空白が
  北川> 挿入されるということです。

詳しい説明をありがとうございました。結局、RFC1522 では encoded-word の
前後に空白を挿入してしまうので、"日本語とalphabetが混在している文字列"
を表現する方法がないということですか。だとしたら、表現力に問題ありとい
うことになりますね。早く解決されることを望みます。
--
Masahiro Kitagawa <[email-masked]>     北川 勝浩
Electric Eng., Engineering Science, Osaka Univ.  阪大・基礎工・電気

---

From: [email-masked] (Kaz Sasayama/ 笹山和宏)
Date: 27 Nov 93 03:40:26 GMT

>>>>> "Masahiro" == Masahiro KITAGAWA <[email-masked]> writes:

    Masahiro> 詳しい説明をありがとうございました。結局、RFC1522 では 
    Masahiro> encoded-word の前後に空白を挿入してしまうので、"日本語と
    Masahiro> alphabetが混在している文字列"を表現する方法がないという
    Masahiro> ことですか。だとしたら、表現力に問題ありということになり
    Masahiro> ますね。早く解決されることを望みます。

ASCIIと漢字をまとめてencodeしてしまえばいいのではないでしょうか?

--
Kaz Sasayama (笹山和宏 in Japanese) at OTSL.

---

From: [email-masked] (ITO Takayuki)
Date: 29 Nov 93 13:11:46

In article <[email-masked]> 
	[email-masked] (守岡 知彦 (MORIOKA Tomohiko)) writes:

>めします。

  mime/decode-message-headerはunfoldしてくれるからですね。

>（確かに、こうすると本文中に残った encoded-word も decode さ
>れるから良いのかも知れないけど）

  そうなんです。
  では、

(setq vm-mode-hooks (list
	'mime/decode-message-header
	'(lambda ()
		(mime/decode-region (point-min) (point-max)))))

これではいかがでしょうか :-)