新しい MH-E を MH-JP とともに使う

未だに MH-JP 上で MH-E を使って 電子メールを読み書きしている人は少数派なのでしょうが、私は昔からずっとこ れ一本です。※ さすがに、最近は表題が ISO-2022-JP でなく UTF-8 で encode されていることが多く summary バッファで読めないことが多いので、辛くなっ てきています…。[2017, 4/30] 大木さんが公 開されてる nmh 修正版と併用するとうまく行くようです。 だいたい使えるようになりました

最近の MH-E は、 表示がカラーになって きれいになったり、MIME の添付ファイルの扱いが可能になっていたり、キー 割り当てが再編されて系統的になったり、宛て先入力時に alias の補完が可能 になったり、と以前に比べて使いやすくなっているのですが、日本ではあまり知 られていないようです。

現状、emacs 25 に付属している MH-E 8.6 を日本で使うためのノウハウを多 少公開してみようと思います。

注意

昔の mh-e(バージョン 5 の頃)の使用法には慣れているものとします。こ こでは、その説明はいちいちしません。

私はあまり高度な機能は使っていません。speedbar, PGP, anti-spam software の併用、thread 表示などに関する情報はほとんど扱っていませんので あしからず。

また、Emacs のバージョンは 25.1 以降とします。XEmacs には手を出 していませんので、ここで書いてあることがそのまま当てはまるとは限らないこ とにご注意ください。

さらに、LANG 環境変数などで日本語 EUC locale が指定されていて、標準の 日本語コードは EUC であることを仮定しておきます。したがって、Emacs の 標準文字コードは日本語 EUC になっており、~/.mh_profile には


File-Coding:	ja_JP.euc
Display-Coding: ja_JP.euc
Process-Coding: ja_JP.euc

のような行があって、表示・ファイル・プロセス間の日 本語が EUC でやりとりされているものとします。

ベースとなる MH

MH-E 8 がサポートするのは

の3種ですが、このうち nmh と mailutils は日本のメール固有の事情に対応し ていない部分が多く(※2006年5月現在)、日本で使うならオリジナルの MH を 日本語化した MH-JP 以外の選択肢は事実上ないでしょう。これは MIME への対応状況がやや古い、という問題があるのですが、しかたありま せん。nmh には存在する group reply 機能も MH-JP にはないので、どなたか nmh の日本語化をやってくださると嬉しいのですが…。→上でも書きましたが、 大木さんが着 手してくださっているようです[2017, 4/13] だいたい使えるようになりました。

以下、MH-JP と MH-E 8 はインストール済みとします。

新しい MH-E では変数名に多少の変更が行われているので、以前 ~/.emacs でカスタマイズを行っていた人は 文書 によく目を通しておきましょう。

メールを読む

Summary 表示

文字化け

メールを読むとき、まず、素の状態で困るのが、Summary バッファにおいて 「差出人名」と「表題」が日本語の場合、「=?ISO-2022-JP?B…」 といった表示になっていて全然読めないことでしょう。これは、以前 の mh-e ではなかったことです。

こうなる理由は、現在の MH-E では、scan 時に独自の format パターンを与えているため、MH-JP の scan の RFC-2047 decode 機能が抑制されてしまっているためです。これを解決する簡単な方法としては、 ~/.emacs


(setq mh-scan-format-file nil
      mh-adaptive-cmd-note-flag nil)

と書き、独自 format を使用しないようにしておくとよ いでしょう。これで文字化けが起きるとしたら、~/.mh_profile での日本語コード指定に誤りがあるか、Emacs の process-coding-system 周り の設定のどこかがおかしいのだと思います。

なお、MH-E の独自 format は、新機能「メール番号の桁数への動的対応」の ために必要とされるもののようなのですが、上記の設定はそれを殺しています。 なので、「桁数固定じゃいやだ!」という人は、mh-scan.elmh-scan-format-nmh をもとにして、MH-JP の hdecode 関数を用いた format file を作り、そのファイル名を mh-scan-format-file に指定するとよいでしょう(未確認)。

色づけがずれる

文字化け以外の問題点として、font lock を利用してカラー表示をしている 場合、差出人名が日本語のメールは、色づけの境界がずれてしまっていることに 気づくと思います(差出人名を修飾するはずの黒色が、一部表題にまではみ出す; ごめんなさい、スクリーンショットは用意してません)。

この問題を完全に解決するのは難しいのですが、部分的な解決については 項を改めて後述します

本文表示

さて、上の設定で Summary バッファでの表示については大体問題はなくなっ たはずで、本文の表示にも大体は不都合はないはずですが、以下のように少数な がらまだ調整が必要なケースも残っています。

文字化け

本文を読むとき、次の条件をみたすメールが文字化けしてしまいます(ヘッ ダ、ボディともに)。

これもやはり、従来の mh-e ではなかった現象で、MIME 周りの処理を MH-E が自前で行うようになったことによるとばっちりです。

このようなメールは、最近では受け取ることも少なくなっているので、特に 問題が起きない、という人も多いでしょう。しかし、MIME が普及するよりも前 に受け取ったり、送ったりしたメールが資産として手元にある人にとっては、こ れでは困ります。日本で使うメールソフトとしては、MIME 関連のヘッダが 何もついていないメールを読むときは、JIS コードで記述されているという前提 で動作してくれないとものの役には立たないのです。 (何かのスクリプトで、まとめて MIME-Version ヘッダと Content-Type ヘッダ を付加してしまえばよい、ですって?嫌ですよ、そんなもん)

これを解決するため、私は以下のようなパッチを当て た上で、 ~/.emacs


(defun decode-message-body-without-mimeheader (orig-fun)
  "MIME-Version ヘッダなしでも、メール本文を decode させる。"
  (let ((mail-parse-charset 'undecided))
    (funcall orig-fun)))
(advice-add 'mh-decode-message-body :around
	    #'decode-message-body-without-mimeheader)

としています(多少汎用性を持たせるため、 'iso-2022-jp を直接指定するのではなく、 'undecided(自動判別)を利用しています)。 [2016, 10/14] emacs 24 辺りから入った「新しい advice の枠組」に対応して 更新しました。

なお、文字化けを避ける別解として mh-mhl-format-filet または mhl 用の適切な format file を指定する、という手も あるのですが、これだと添付ファイルを「ボタン」化して扱える、という MH-E の新機能(※ 注)の恩恵が受けられない、というデメリットがあります。もち ろん、「添付ファイルなんかどうでもいい」という人はその方法でも構いません。 これだと、「ヘッダの表示される順番を format file で指定できる」というメ リットもありますしね!(mhl を使わなければ、ヘッダの順番は元のメールのま まソートされない)

PGP 署名付きメッセージの検証・表示

PGP 署名されたメッセージ(multipart/signed ではなく、署名され たメッセージ全体が text/plain になってるタイプ)を受け取った場合も、日本 語部分が decode されず読めない、という問題が起こります。

[2016, 10/14] この問題は根が深く、完全に解決するのは難しいことがわかっ たのですが、とりあえず私が今の所受け取っている範囲のメールでは、以下で公 開しているパッチに加えて、.emacs 等で次の行を加えることによっ て問題は糊塗できています。


(setq mm-uu-text-plain-type '("text/plain" (charset . undecided)))

なお、mm-uu-text-plain-type に対する変更は、本来は上記のよ うな ad hoc な対処ではなく、関数 mm-uu-pgp-signed-extract-1 に decode 処理を入れるのが筋なのでしょう (mm-uu-pgp-encrypted-extract-1 みたいに)。

[2017, 4/30] しばらく前に書いた以下の部 分は、どうやら私が独自に追加していた修正の、「run time の cl ライブラリへの依存性をなくす」処置が不適切だった ことが原因だったようです。ちゃんと修正したところ、customize option を元 に戻してみたら、以前と同じ挙動に戻りました。

ま た、PGP 署名されたメッセージを表示する際にその検証を行うための設定は、現 行の emacs 24.4 だと以前と事情が変わってきたようです。以前は PGP署名の検 証は自動ではなされず、K v とタイプしたときだけ行われる、とい う動作でしたが、どうもこれは元々意図されていたものではなくて、本来「自動 的に検証されるというオプションをオンにすれば何もしなくても検証される。オ フのままだと検証されない」というもののようです。これまで MH-E 上では K v で検証されていたのは、意図せず偶然そうなっていただけっぽ い感じです(※ ちゃんと調べたわけではなくて想像で書いてます。鵜呑みにし ないようご注意ください。Gnus の文書をちゃんと読んだりするとどこかに説明 があるのかもしれませんので、本当の所を知りたい方はがんばって調べてくださ い)。

それではどうするのが正しいのかと言うと、mm-verify-optiongnus-buttonized-mime-types という2つの変数をカスタマイズ するのが正統的な方法のようです。これらの変数を M-x customize-option でカスタマイズし、前者は alwaysknownにセットし、後者は「INS」ボタンを押して Regexp に multipart/signed をセット(引用符不要)すれば、PGP 署 名されたメールを MH-E で表示しようとするだけで自動的に検証されるようにな ります。

なお、これまで通り検証するかしないかをその都度選択できるようにするに は、mm-verify-optionask にセットすると、MH-E で表示しようとした時点で検証するかどうかを選択できます。ただし、そ の場合、以下のような制限があるようです。

S/MIME [2014, 1/28]

銀行などから、差出人が真正であることを証明するために S/MIME 署名つきの メールが届くことがあります。ある時期まではこれも RET で表示さ せて K v で検証できていたのですが、いつの間にか検証がことごと く失敗するようになってしまっていました。原因は、私の場合は、 mml-smime-use の定義が

(defcustom mml-smime-use (if (featurep 'epg) 'epg 'openssl)

...
のようになっていて、「epg が有効な場合は epg 経由で S/MIME を処理する」 というようになっていたためでした。epg は S/MIME の処理には gnupg の gpgsm を利用するのですが、私が使っ ている FreeBSD で普通にインストールされる gnupg だと gpgsm は省かれる ため、epg が検証を行うことができずエラーになっていたようです。結局、epg が想定している「gnupg がインストールされている環境では必ず gpgsm が使え る」という仮定が粗い、ということなのでしょう。

試しに gpgsm を追加インストールしてみたり、mml-smime-use の 値を openssl にしてみたりすると、再びちゃんと検証がうまく行 くようになりました。

結局、こういう場合は、~/.emacs(あるいは、 ~/.emacs.d/init.el など)に次のように書いておけばいいようで す。

(setq mml-smime-use (if (executable-find "gpgsm") 'epg 'openssl))

もっとちゃんとやるには mml-smime.eldefcustom そのものをいじるんでしょうが、そこまでやるとおお ごとなのでとりあえずはこれで。

メールを書く

さて、ここまでで「受け取ったメールの表示」についての問題はおおよそ解 決できます。しかし、これだけではまだ、「自分が書いて、出すメール」に重大 な問題が残っています。

anti MIME

私は個人的に MIME というものが嫌いなので、添付ファイルを送る必要があ る場合を除き(つまり、本文が全文単なる平文で済む場合)、日本語を含む場合 も送信メールが MIME 形式にならないようにしています。現行の MH-E をそのよ うに振る舞わせるのには少々苦労しましたが、


(setq sendmail-coding-system 'iso-2022-jp)
(defun disguise-all-ascii ()
  "`mh-ascii-buffer-p' を無効化する。"
  (eq mail-send-nonascii t))
(advice-add 'mh-ascii-buffer-p :before-until #'disguise-all-ascii)
(setq mail-send-nonascii t)

(add-hook 'mh-compose-letter-function
	  (lambda (to subject cc)
	    (set-buffer-file-coding-system sendmail-coding-system)))

とすることによって、一応狙いどおりのことはできてい ます(※ これは、「自分が送る日本語メールはちゃんと全部 MIME 形式 にしたい」という人はやってはいけない設定です。くれぐれ もご注意ください)。[2016, 10/14] emacs 24 辺りから入った「新しい advice の枠組」に対応して更新しました。

Emacs 22+ の更なる問題

Emacs 22 以降で使う場合、これまでに問題が2つ1つ見つかっています。

[2012, 12/7] 以前、ここで書いていた 「default-sendmail-coding-system の起動時の値」についての問題は、 半田さんのお話によればむしろ「そういうもの」と理解すべきものだったこ とのようなので、カットしました。本文書では、単に sendmail-coding-systemiso-2022-jp にセットす る、という話に留めています。

もうひとつの問題ですが、emacs 22 では、「ヘッダが MIME 符号化されたメー ルに対して返信を書く」とき、 送信時に2重に MIME 符号化されてしまい、結果受け取った相手がまともに読め ない、という問題が発生するようになりました。これを解消するには、更に


;; for emacs 22 and later
(setq rfc2047-encode-encoded-words nil)

という設定を追加する必要があります。こちらは、 ~/.emacs 内なら置く位置はどこでもよいです。

[2012, 10/1] なお、 後者の問題は MH-E 8.3 では修正されたという触れ込みなのですが、よく読むと書いてある通り、対処され ているのは Subject ヘッダのみです。日本で使う場合は、From ヘッダなど、他 のヘッダでも MIME 符号化が行われるヘッダが多いので、上記の設定は引き続き 必要となるでしょう。

段落処理

メールを書いているときの推敲中、段落移動や、段落の整形処理がうまく働か ないことがあります。具体的には、1段落だけ整形するつもり で M-q と打ったのに、次の段落までまとめて1段落と見なされて整 形処理に巻き込まれる、というような現象が発生したりします。これは、メール を書くモードでの標準の「段落認識設定」が日本語文章向けにチューンされてい ないからです。

以下のような処理を ~/.emacs に追加するとよいでしょう。


(add-hook 'mh-letter-mode-hook
	  (lambda ()
	    ;; 空白から始まる行も段落の始めにする。欧米人はそうはしない
	    ;; のかもしれないけど、日本じゃこうなってないと困るよ…。
	    (paragraph-indent-minor-mode 1)
	    (setq paragraph-start (concat " .\\|" paragraph-start))))

本当は、current-language-environment をチェックして、日本 語環境の時だけ上記処理を実行する…というように丁寧に書く必要があるんでしょ うけど、そこまでは踏み込まないでおきます。

※ なお、上述の「日本語文書に対する段落認識処理」の 問題は、MH-E とは無関係に、text mode 系統の major mode 全般に見られるよ うになっています(emacs 20 頃から。確か、mule 2 の頃はこんなではなかった はず…)。ですので、少なくとも純正 text mode に対しては、次のような行を 追加しておくことをお勧めします(これは、emacs 22 以降でもそうでなくても)。


(add-hook 'text-mode-hook (lambda ()
	(if (eq major-mode 'text-mode)
	    (paragraph-indent-minor-mode 1))))

また、段落開始を表す字下げを全角空白で行うタイプの人は、上記 mh-letter-mode-hook への hook を参考にして、 paragraph-start に全角空白を追加する処理を hook に加えるとよ いでしょう。

純正 text mode 以外でも、必要に応じて paragraph-indent-minor-mode を呼び出す hook を追加するとよい と思います。

その他

私家版パッチ

emacs 25.2 付属の MH-E 8.6 に見つけたいくつかのバグに対するパッチを置 いておきます。上述した不具合を修正するための個人的な変更も含めてあります。 本家にパッチを提 出するには sourceforge のアカウントを取らねばならないらしいので、こ こにひっそりと置いておくだけにします。

------>mh-e-8.6-patch.bz2 emacs 25.2 用 [2017, 4/30]
※ 4/16から4/29までのものは、更新したつもりで更新さ れてませんでした。以下の説明の修正が入ってなくて困惑した方すみません。

バグとパッチの内容を説明しておきます。

  1. [2017, 4/16] nmh との併用を試しているとき、 mh-pathmh-sys-path よりも優先させることに失敗 しているバグを見つけたので修正しました。[2017, 4/30] 4/29 までのものはこの修正が入っていませんでした。すみ ません。
  2. [2016, 10/14] メールを書いているとき、C-c C-m C-f で既存 のメッセージを転送(forward)する際、inline 形式だけでなく添付ファ イルとして転送することもできるオプションを追加しました。customize option mh-mime-forward-disposition"attachment" にすると、転送対象が添付ファイルになりま す。
  3. [2016, 10/14] 理由はよくわかりませんが、私の手許だとメールを書くときに mail-abbrev-syntax-tablenil になってい てエラーになる現象が起きていたので、それの対処を入れてあります。 [2017, 4/30] この現象は、次項の「run time の cl library への依存を解消する」事情への私の理解が浅くて修 正が不適切だったためだったことがわかりました。より根本的な部分を修 正したので、以前の場当たり的な処置は外してあります。
  4. [2016, 10/14] emacs 付属の elisp library では、run time に cl library を要するようになってはいけない、というのが現在の emacs の方針で すが、それに沿っていなかったので沿うように直してみました。その結果、新 たに byte compile されるようになったファイルが2つほどあります(macro だけでなく run time に実行される普通の関数定義も含んでいたので)。 [2017, 4/30] 上述の通り、これまでの修正 は不適切だったので更に修正を加えました。「macro の展開は byte compile 時に行われる」ことと、「byte compile 時に、 requiretop level に直接書かれたときだけ byte compiler にも評価される」ということをきちんと理解していないと いけなかったんですね…。mh-copmat.elmh-gnus.el が byte compile 対象から外してあったのは、 ちゃんと理由があったことで、単純に byte compile 対象に含めるだけで はだめだったのですね。必要な修正を追加した結果、「届いたメールの添 付ファイルを K o で保存することがなぜかできなくなってい た」という謎の現象(でもあまり気にしていなかった)も解消しました。 根は同じ原因だったのですね。念のため、他のファイルの「ひょっとした ら影響があるかもしれない」箇所もより安全な処置に書き直してあります。 (なお、原因がわかった目で見てみると、上記の mail-abbrev-syntax-table がらみのエラーは、xemacs では必ず起こってしまうように思えます。にも関わらず放置されてるって ことは、現在の xemacs ユーザーで MH-E を使ってる人って事実上いない のでは…)
  5. [2016, 10/14] 以前は別個にしていた texinfo ファイルに対する修正も一 本化しました。
  6. mh-acros.el に対するパッチは単なる typo の修正ですが、 そもそもこの行の内容は describe-function のとき一番上 に表示されるので、取っぱらってしまった方がいいような気もします。
  7. forw コマンドに対する -mime オプションは MH 6.8.4 に対しても存在するはずですので、mh-comp.el でベー ス MH によらず mh-compose-forward-as-mime-flag を見るよ うにしました。
  8. mh-e.el は一部アクセントつきアルファベット母音を UTF で記述していますが、これが正しく解釈されない(日本語 EUC locale で はもちろん、C locale であっても)ので、Local Variables に coding 指定を明示しました。
  9. Summary バッファ中最後のメールを SPC で読んでいって、最 後まで到達して「End of message (Type SPC to read next(previous) undeleted message)」と表示された時点で、DEL で逆スクロー ルしたとします。ここで再度 SPC を叩いたときは再スクロー ルして欲しいのですが、そうはならずに next(previous) undeleted message を表示しようとしてしまうので、mh-folder.el で この愚直な動作を修正しました。
  10. search-pattern バッファでは C-c C-f C-t などのキーバイン ドが使えるはずなのですが、mh-letter.el をロードするまで はこれらが使えなかったバグを修正しました。
  11. search-pattern バッファで C-c C-f C-b などで Bcc: ヘッダ を指定すると read only エラーが出るのですが、Bcc: ヘッダが検索対象と なることはないはずなので、mh-search.el でそのキーバ インドを削除しました([2007, 6/20] うーんそうか、でも draft フォルダー に残る書きかけのメールでは Bcc: ヘッダが残っていることもありうるか。 でも、書きかけのメールがそんなに検索を必要とするほどたくさん残ってる、 という事態は想定する必要はないかな?)。
  12. F v で他のフォルダに移るとき、document には
    it will show all the messages in the buffer as long there are fewer than `mh-large-folder' messages. If there are more, then you are prompted for a range of messages to scan.
    と書いてあるのですが、環境によっては後半の動作をせず、たくさんのメー ルが入っているフォルダに移るときも全メッセージを scan してしまうことがありました(もちろん、prefix argument をつければ range を訊いてこさせることは可能でしたが)。これは、 mh-seq.el の正規表現の不備が原因だったので、修正しま した。
  13. 本文を読むとき、In-Reply-To ヘッダを表示させる設定にしていても、大 文字小文字が合わないと正しく着色されなかった問題を mh-show.el で修正しました。ついでに、 という2点も修正してあります。
  14. ツールバー上の、alias 未登録な相手を新たに登録するボタンが機能して いなかったのを修正。ただ、このせいで、フォルダを開いたときは常に mh-alias.el がロードされるようになってしまいました。
  15. メニューとツールバーについて、いくつかの項目について、フォルダモー ドでカーソルがメッセージ行の上にない場合は無効化されるようにしまし た。※ そういう場合も、prefix argument を付ければ range が指定でき るので、一律無効化するのは適切ではないかもしれません。
  16. Auto fill を自動では on にせず、状況に応じて後から手で on にするか どうかを選択する主義の人のため、letter mode で normal-auto-fill-function を設定しておきました。
  17. [2009, 2/1]「どうも送信時、 C-u を付けて C-c C-c とすると Message-ID が 付かないな…?」と思っていたらバグだったので、修正しました。
  18. これはバグとは言い切れませんが、上の方でも解説した通り、MIME 形式で はない日本語メールを読むときに、文字化けしてしまうのを解消する変更 を入れてあります。(その結果、RFC に厳密には沿わなくなったモノを処 理することになっているはずなので、ちょっとインチキな修正ではありま す。が、おそらくそこら辺の処理には干渉しないはずなので、読むだけな らたぶんこれでも大丈夫)

    mh-mime.el では、 mh-decode-message-header した後で mh-show-addr している部分があるなあ…。これだと、MIME decode の結果、quote・escape さ れていた特殊文字が生で出てきているかもしれないので、アドレス解析が正しく 行く保証がないので、厳密にはバグじゃないだろうか。

  19. その他明白な typo 修正。

※ 上で修正したバグ以外に、日本語 Subject を持つメー ルに対し、フォルダモードで / s は大抵効かない、という不具合が あります。MH-JP の pick コマンドは、引数に RFC 2047 decode の文字列を与えなければいけないことが原因ですが、この問題には 対処していません。

色づけ再び

上で書いた通り、font-lock を利用している場合、 差出人名が日本語で書いてある メールは、Summary バッファでは色づけの境界位置がおかしくなるという問 題があります。これは、

ということから発生しています。

上の問題を、正規表現を工夫するだけで解決することは私には無理だったの で、とりあえず以下のような強引な手段によって mh-scan-subject-regexp を使わないようにして色づけをさせていま す。


(eval-after-load "mh-folder"
 '(defun mh-folder-font-lock-subject (limit)
    "Return MH-E scan subject strings to font-lock between point and LIMIT."
    (when (save-excursion
	     (or (bolp) (forward-line 1))
	     (move-to-column (+ mh-cmd-note mh-scan-field-subject-start-offset))
	     (if (< (point) limit)
		 (looking-at
		  "\\(\\(?:[Rr][Ee]\\(\\[[0-9]+\\]\\)?:\\s-*\\)*\\)\\([^<\n]*\\)")))
      (goto-char (match-end 0))
      (if (< (match-beginning 1) (match-end 1))
	   (set-match-data (list (match-beginning 1) (match-end 3)
				 (match-beginning 1) (match-end 3) nil nil))
	 (set-match-data (list (match-beginning 3) (match-end 3)
			       nil nil (match-beginning 3) (match-end 3))))
      t)))

が、これで問題が解決したわけではありません。正規表現が hard code され ていることにはまだ目をつぶるとしても、

という大きな問題が残っていて、猛烈にヘボヘボです。 この2つは色づけとは無関係な問題であり、font-lock を利用しているかどうか にかかわらず発生します。

また、類似の問題として、

というものもあります。

これらの問題を解決するのは、私にはちょっと無理そうなので、どなたかぜ ひ頑張ってください。どうぞよろしく(他力本願)。

大木さんの nmh 日本語パッチ

大木さん が公開されている nmh 日本語パッチをちょびっとだけ試してみました。私 は、From: アドレスと Envelope From を別個に指定できるように、 MH-JP をちょっと変更して使っているのです が、nmh ではそれは無効となり、代わりに別の手法を使うようになっていました。 通常の使い方をしている方は、そこだけ修正すればいいと思います。以下、その 方法を述べます。

MH-JP では ~/.mh_profile 中の「Sendername」という項目で Envelope From を指定していたと思いますが、nmh では個々の送信メールに擬似 ヘッダー「Envelope-From:」を付けることで Envelope From が指定できるよう になっています。1通ごとにこのヘッダーを手動で付けるのは面倒すぎますから、 自動化するには components, replcomps, forwcomps の各ファイ ルを ~/Mail にコピーして、次の行を最初に追加すると MH-JP で の ~/.mh_profile の設定をそのまま生かせます。

%(void(profile Sendername))%(void(width))%(putaddr Envelope-From: )

なお、SASL と TLS を使って、nmh が直接 SMTPS サーバーにメールを送信す る…という機能もテストしてみて問題なく使えたのですが、それをやると(すべ てのメールをプロバイダの配送サーバーに送りつけることになるため) localhost 上のユーザーにテストメールを送るのが難しくなってしまうという盲 点がありました。このため、結局その機能は使わず従来通り MTA 任せにするよ うに戻しています。

大木さん、有用なパッチを公開してくださり、誠にありがとうございます。

個人事情

以下は私の個人事情に基づくさらなる修正です。普通に使ってる方には関係 ない話となるでしょう。

上でも書いた通り、私は MIME というものが嫌いなので、メールを送るとき、 ファイルを添付するなど MIME を必要とする場合を除いては MIME 形式を使わず、 Subject: も本文も JIS コードで日本語を書いています。このため、さらにあれ これ手を入れないと nmh は使えませんでした。

まず困るのが、scan コマンドの出力で、そういったメールの Subject の表 示が文字化けすることです(私の使い方では、そういうメールが outbox フォル ダに大量に残ることは上で書いた通り)。MH-JP だとそこは日本語 EUC にちゃ んと直した上で出力してくれていたので問題なかったのですが、nmh はそんな気 の利いたことはしてくれません。JIS コードを無変換のまま出力するのですが、 その際 escape コード(に限らずコントロールコードはすべて)は出力から落と しているため、文字化け表示になります。

もう1つの問題は、nmh の send コマンドが送るメールをすべて MIME 形式 に変換してしまうことです。雑に調べた所ではどうやら送信前に mhbuildコマンドにかけて MIME-Version:, Content-Type:ヘッダーがないメールにはすべてそれらを補うよう なのですが、困るのは JISコードで書いてあるメールも charset="us-ascii" という大ウソ情報を付加してしま うことでした(せめて正しくcharset=iso-2022-jp と付けてくれ ればまだしもなのですが…)。

色々試行錯誤して、上記2つの問題は次のようにして解決しました。まず JIS コードで書かれた Subject に関しては、大木さんのパッチを眺めてみて 「どうも、ここの所をこうすると Subject 部分も JIS コードを内部コード (UTF-8?)に変換しておいてくれるんじゃないの?」と思われる処理を追加し たところ、確かに思惑通りの動作になってくれました。

ついでに、JIS コードで JISX0208 モードへの切り替えは ESC $ B だけでなく ESC $ ( B も有効なはずなので、それに対 する対処も入れたパッチを置いておきます。大木さん のパッチを当てた後、さらに適用してください。例によって私は C 言語が全然 わかってないため、書き換えはすべて見よう見まねに過ぎないので、 利用される場合は自己責任でお願いします。

次に後者の問題ですが、これは send コマンドについては、nmh のものでは なく MH-JP のものを引き続き使い続けるようにしないと解決は難しいでしょう。 ところが、単に PATH の先頭にある ~/bin/usr/local/nmh/bin/scan/usr/local/nmh/bin/inc からのシンボリックリンクを作っておく だけ(/usr/local/nmh/bin は PATH には入れない)では解決しま せんでした。MH-E のコードを読んでみると、nmh が存在する場合はたとえ PATH が通っていなくても実際にそこにディレクトリと実行ファイル一式があれば mh-progs/usr/local/nmh/bin をセットし、コマ ンドはすべて絶対パスで呼ぶようになっていたのが原因でした。このため、上述 のような小細工をしても結局は MH-JP ではなく nmh の方の send コマンドが呼 ばれてしまうのです。

仕方ないので、更に MH-E の処理を読んでみて、次のようにしてやっと目的 を達成しました。なお、上の私家版パッチ必須 です! [2017, 4/30] と書きつつ今回 の修正までは必要な修正が含まれない古いバージョンのままでした。どうもすみ ません。

  1. 適当なディレクトリ(ここでは、例として ~/bin/mh として おく)に、MH-JP の実行ファイルのシンボリックリンクを一揃い作っておく。 ただし、そのうち inc, scan, repl, mhparam だけは nmh の実行ファイルに対す るシンボリックリンクにしておく。(また、flist, flists も nmh の実行ファ イルにに対するシンボリックリンクを作っておくとよい?こちらの効果はまだ 未検証)
  2. .emacs 等で (setq mh-path '("~/bin/mh")) と しておく。
  3. 上で書いた、components, replcomps, forwcomps に対する 修正は廃棄する(もともと ~/Mail になかった場合は削除し、 もともと MH-JP 用のものが置いてあった場合はそれに戻す)。

こうしておくと、MH-E は ~/bin/mh に nmh の実行ファイル一 式がある、と思ってくれてそこのコマンドを絶対パスで呼ぶようになるので、 「inc と scan は nmh のものを使い、その他のコマンドは MH-JP のものを使う」 としてくれて目的達成です。 [2017, 4/27] また、MH-E は nmh があると思って いるときは repl には nmh 用のオプションを与えるので、MH-JP の repl を使っ てしまうとエラーになります。そのため、上のように repl も nmh のものを使 うようにした所、どうやらエラーは出ずに使えているようです。また、まだちゃ んと確かめていませんが、プログラムを眺める限り、nmh の group reply 機能 は使えそうです。MH-E は、通常の reply と group reply の区別はつけず、同 じ r というキーで group reply と通常の reply のうち適切な方を 自動で判定して、repl に与えるオプションを変えるようです(つまり、「メー ルリストで配信されたメールを、あえて個人あてに返信する」という使い分け方 はできない感じ。どうしてもやりたかったら、draft バッファでヘッダー部を手 で書き換える)。なお、私家版パッチが必要です。でないと、 mh-pathmh-sys-path よりも優先するようになってく れず思惑が破綻します。[2017, 4/30] と言いつ つ、本日入れ替えまでの私家版パッチは手違いで必要な修正が入っていない旧バー ジョンのままでした。どうもすみません。

上の例の ~/bin/mh は、PATH に含めても含めな くてもどちらでもよいです。shell 上で scaninc を直接打つことが多い人は入れておいた方がよいでしょう。


コンピュータ関連のページ目次へ
トップページへ
井汲 景太 <ikumikeita@jcom.home.ne.jp.NOSPAM.>(迷惑メールお断り)
最終更新日: 2017年4月30日