Mew マニュアル
*********

山本和彦
作成 1996/02/19
更新1998/05/23

この Info は Mew バージョン1.93 について解説します。

はじめに読んでね
********

Mew とは、

  - 電子メール

  - ネットニュース

  - MIME(Multipurpose Internet Mail Extensions)

  - PGP(Pretty Good Privacy)

を統合し、簡単に読み書きするためのインターフェイスです。Mew を使えば、友達の誕生日にケーキの絵と「Happy Birthday to You」の歌を添えたメッセージを暗号化して送れます。ネットニュースの統合は、2.xx 以降で予定しています。

Mew は 「Messaging in the Emacs World」 の略です。先頭の M は大文字で表記し、「みゅう」と読みます。M で始まるかわいらしい単語を選んだ結果 Mew になりました。決して漫画の題名や某アイドルの歌、あるいは、関西の会社に因んでいるわけではありません。:p

Mew バージョン 1.xx の特長を以下に示します。

  - 複雑な構造を持つメッセージを簡単に表示できます。メッセージを表示する作業は、SPC を押すだけです。

  - コピー程度のファイルの操作を知っている人ならだれでも簡単に複雑なメッセージを作成できます。

  - メッセージの一覧表示が終了するまで待たなくても、メッセージを読み始められます。

  - Summary モードのメッセージの一覧を保存しているので、フォルダを移動した場合は、更新された部分だけを一覧表示します。

  - メッセージの整頓先を賢く推測します(たくさんメッセージを受け取る人は、これがないと生きていけません)。

  - Draft モードでは、フィールド名、アドレス名、ドメイン名、フォルダ名を補完できます。

  - Subject: や Date: などを条件に指定して、簡単にメッセージを選択できます。

  - 便利なマークが提供されています。uuencode した後で分割されたメッセージにマークを付けて、一度に元のファイルに戻せます。

  - PGP で暗号化されたメッセージを自動的に復号化します。また、電子署名を自動的に検証します。

  - PGP を使って、メッセージを簡単に暗号化したり、署名したりできます。

  - MIME の構造を解析したり、PGP を復号化したりするのには少し時間がかかります。そこで、一旦解析した結果をしばらく保存し、2度目の表示を高速化しています。

  - 複数のフォルダを1つのフォルダに見せかけられます。

  - XEmacs では、Emacs でのキー入力によるインターフェイスと全く同じ機能を持つアイコン・ベースのインターフェイスが提供されています。

Mew は、Emacs 19.28 以降(Emacs 20.xx も含む)、Mule 2.3 以降、XEmacs 20.3 以降をサポートしています。XEmacs 19 での動作は確認していませんが、無修正か少しの修正で動くと思います。これら以外の Emacs、たとえば、Emacs 18、 Nemacs、Mule 1 および XEmacs 20.2 などはサポートしていませんし、今後もサポートする予定はありません。また、beta リリースである Emacs をサポートすることもありますが、正式リリースになって仕様が変わったときは、正式リリースである Emacs の仕様に合わせます。

このマニュアルで単に Emacs と言った場合には、サポートしている全てのプラットフォームを意味します。Mule といった場合は、多国語が利用できる Mule 2 と Emacs 20、そして、--with-mule オプション付きでコンパイルした XEmacs 20.3 を指します。これに対し、Bilingual Emacs と言った場合には、英語と Latin 1 しかサポートしていない Emacs 19 と --with-mule オプション無しでコンパイルした XEmacs 20.3 を意味します。また、XEmacs と言った場合には、グラフィックを楽しめる XEmacs 20.3 を指します。反対に、テキストしか表示できない Emacs は、Text Emacs と呼びます。

さぁ始めよう！
*******

Mew には次の4つのモードがあります。

  - Summary モード :: メッセージの一覧を表示し選択するモード。

  - Virtual モード :: 複数のフォルダからある条件に合致したメッセージを取り出し、仮想的に1つのフォルダにしたモード。Summary モードに似ている。

  - Message モード :: テキストの内容を表示するモード。

  - Draft モード   :: メッセージの送信、返答、転送を準備するためのモード。

Mew を起動するには、以下の方法があります。

 1. M-x mew :: Mew を起動する。mew-auto-get が t なら、到着したメッセージを +inbox フォルダに保存しながら、+inbox のメッセージを Summary モードに一覧表示。mew-auto-get が nil なら、単に +inbox のメッセージを Summary モードに一覧表示。

 2. C-uM-x mew :: mew-auto-get の値を逆だと思って、M-x mew を実行する。

 3. M-x mew-send :: メッセージを書くための Draft モードへ移行。

Text Emacs で Mew を起動した際には、Mew を型どった「/\\ - \\/」という図形がくるくると回るデモが始まります。XEmacs では、可愛い2匹の子猫がオープニングを飾ります。

このとき Mew は、フォルダ名を集めるなどの作業をしています。もし起動が遅いなと思ったら、see faster の対処方法を読んで下さい。

メッセージを表示する
**********

M-x mew と入力すると、Mew はスプールのメッセージを +inbox フォルダに移して以下のように一覧表示します。

         1  07/17 いとぢゅん     v6: items to be no in6_pcbnotify()がなにも
         2  07/18 歌代先生       Re: behavior after これ、mark-ring がどんど
         3  07/19 のむさん       refile info.       乃村です。遅くなりました。

これを Summary モードといいます。ここでは、主に Summary モードでのメッセージの読み方について説明します。

読み方の基礎
======

メッセージを上から順に読んでいくのであれば、SPC を適宜押すだけです。簡単でしょ？

しかしそれだけではあんまりなので、以下にページを操作する基本的なコマンドを示します。

SPC
     メッセージを読み進める。つまり、メッセージを表示し、スクロールさせ、他のメッセージに移動して表示する。移動の方向は、 mew-summary-show-direction を参照のこと。up, down, next(現在の方向) stop が選択できる。デフォルトは down。

DEL
     現在のメッセージを上にスクロールさせる。不必要なヘッダフィールドは、ウインドウの上に隠れている。よって、DEL を入力すると、それらが現れる。

.
     現在のメッセージを強制的に表示する。非 MIME 解析モードの場合は、強制的に解析する。

RET
     現在のメッセージを1行上にスクロールする。

M-RET

-
     現在のメッセージを1行下にスクロールする。

C-n
     下の行へ移動。

C-p
     上の行へ移動。

n
     下方向に移動し表示。対象となるのは、パート、* マークの付いたメッセージ、マークの付いていないメッセージ。C-u と共に呼ばれると、パート部分を飛ばす。

p
     上方向に移動し表示。対象となるのは、パート、* マークの付いたメッセージ、マークの付いていないメッセージ。C-u と共に呼ばれると、パート部分を飛ばす。

j
     入力された番号にしたがってメッセージへ移動。

MIME を表示する
==========

マルチパートを読むのは別に大変なことではありません。今まで通り、 SPC を押していけばよいだけです。

マルチパートのメッセージは、以下のように日付の左に "M" という印が付いています。

         4  07/19 しげやさん     Re: imget very fir ということで、こんなもん
         5 M07/20 としちゃん     small patch to ims imsetup.in にちょっとだけ
         6  07/21 もとのりさん   Re: imget very fir POPでサーバにメッセージの

"5" のところで、SPC を押すと、ヘッダを Message モードに表示すると共に、以下のように Summary モードでマルチパートの構造を簡素に表示します。

         4  07/19 しげやさん     Re: imget very fir ということで、こんなもん
         5 M07/20 いとぢゅん     MagicPoint         今度の発表で使用する資料
     B    2  Image/Gif                    MagicPoint のロゴ            mgp.gif
     Q    3  Application/Postscript       資料                         ohp.ps
         6  07/21 もとのりさん   Re: imget very fir POPでサーバにメッセージの

もし、第1パートが Text/Plain なら、Summary モードには第1パートは可視化されず、そのかわり第1パートがヘッダと共に Message モードに表示されます。

マルチパートの各行はマーク、パート番号、データの型、説明、ファイル名

から構成されています。マーク、データの型、説明、ファイル名はそれぞれ、 Content-Transfer-Encoding:、Content-Type:、Content-Description:、 Content-Disposition: の値です。Content-Description: はパートに対する Subject: と考えられます。この表示は Draft モードの添付領域とほとんど同じです。それぞれのカラムの詳しい意味は、see mime-comp を参照して下さい。

SPC や n でパート1へ進めば、そのパートがデータ型に応じて表示されます。たとえば、Text/Plain なら Message モードで、PostScript なら ghostview で表示されます。

n や p は、パート部分まで含んだ行を移動することに注意して下さい。パート部分を飛ばして下のメッセージを表示するには C-u n と入力して下さい。また、パート部分を飛ばして 1 つ上のメッセージを表示するには C-u p と入力して下さい。

Mew は、MIME を再帰的に処理します。以下は転送されたマルチパートのメッセージの例です。

       501 M02/22 Itojun         Fw: MagicPoint           伊藤先生からこんな
          2  Message/Rfc822               MagicPoint
     B    2.2  Image/Gif                    MagicPoint のロゴ          mgp.gif
     Q    2.3  Application/Postscript       資料                       ohp.ps

(メモ) テキスト以外のデータを、シングルパートとしてメッセージに格納するのは、書式としては間違いではありませんが、お勧めできません。マルチパートを作成し、そのパート1に説明のテキストを、パート2にテキスト以外のデータを入れる作法をお勧めします。

テキスト以外のデータが本文に直接格納されているメッセージに対し、Mew はこれをあたかもマルチパートように表示します。

PGP/MIME を表示する
==============

今までと同様 SPC などを利用することで、Mew では PGP で暗号化や電子署名を施されたメッセージを簡単に表示できます。まず、簡単な例から紹介しましょう。

         8 S07/22 酒井さん       Re: home was full  MsgStore.pm のバグです
         9 E07/23 ニートすみかわ Wine               おはようからおやすみま

8番と9番のメッセージには、それぞれ "S" マークと "E" マークが付いています。これはそれぞれ、本文全体が署名されている、および、暗号化されていることを意味します。

PGP/MIME では、一部のパートに電子署名を施したり、暗号化したりできます。この場合このようなマークは付きません。マークが付くのは、本文全体が対象になっている場合です。

また、単に署名や暗号化と言いましたが、これは最終的な処理が署名や暗号化であったことを意味しています。やや複雑なはなしになりますが、もしかすると前者は本文全体を暗号化した後署名したのかもしれませんし、後者は一部のパートに署名しさらに全体を暗号化している可能性もあります。

本文全体、あるいは、一部のパートが暗号化されている場合、Mew はパスフレーズを訊いてきます。入力されたパスフレーズは、あなたの秘密鍵を復号化するのに使われます。そして、復号化された秘密鍵によって、暗号化されているメッセージを解くわけです。ある PGP/MIME メッセージを表示するには、暗号化された数だけパスフレーズを入力する必要があります。これは、安全をきして Mew がパスフレーズをどこにも保存しないので、以前入力されたパスフレーズを再利用できないからです。

********************************************************************
もし Emacs がローカルのコンピュータで動いていない場合は、パスフレー
ズを入力しないで下さい。入力すると盗聴される恐れがあります。
********************************************************************

一旦復号化されたメッセージはしばらく保存されるので、2回目の表示にはパスフレーズを訊かれないかもしれません。

一方、通信相手の署名を検証するためには相手の公開鍵が利用できればよいので、パスフレーズを訊かれることはありません。

Mew は自動的に電子署名を検証したり、入力されたパスフレーズを使って暗号メッセージを復号化したりして、もとのメッセージを表示します。そこで、ユーザが署名の存在に気づかないかもしれませんし、どの部分が暗号化されていたのか分からないかもしれません。

そこで、検証の結果やどの部分が暗号化されていかをユーザに通知するために、 Mew は以下のようにヘッダに X-Mew: フィールドを挿入します。

     X-Mew: <body> PGP decrypted.
             Good PGP sign "kazu@mew.org" COMPLETE

"<>" 内の番号は、どのパートの結果であるかを示しています。"body" は、メッセージの本文全体が保護されていることを意味します。この例では、メッセージ全体が kazu によって署名され、受信者のために暗号化されています。Mew はまずこれを復号化し、そして署名を検証しています。署名は正しいので、 kazu@mew.org という ID の付いた秘密鍵で署名されたときから、内容は変更されていないと分かります。この署名の検証に使われた公開鍵の「有効性」は "complete" です。よって、受信者はこの公開鍵が ID が示すユーザに属していると信頼していることになります。つまり、このメッセージは信頼をおいている公開鍵によって検証され結果が正しいので、改竄されていないということになります。

以下の例では、まずマルチパートである本文全体の電子署名が検証され、その後パート 2 のメール全体が復号化されています。つまり、作成時には、まずパート 2 が暗号化され、そして本文全体が署名されたことが分かります。

     X-Mew: <body multi> Good PGP sign "kazu@mew.org" COMPLETE
     X-Mew: <2 message> PGP decrypted.

するどい人なら、悪い人があらかじめ X-Mew: フィールドを挿入しておき、あなたをだますかもしれないと思うかもしれません。でも大丈夫です。Mew は、ヘッダにある X-Mew: をあらかじめ削り、本物の X-Mew: フィールドを挿入しますから。

X-Mew: フィールドは他にもさまざまな結果を伝えてくれます。たとえば、署名を検証するための公開鍵がないとか、復号化に失敗したなどです。以下の例は、鍵 ID が 0x1B8BF431 である公開鍵がないことを示しています。

     X-Mew: <body multi> No his/her public key. ID = 0x1B8BF431

この場合、C-cC-f と入力すると、Mew は mew-pgp-keyserver-url-template で指定された URL を使ってこの公開鍵の入手を試みます。もし、X-Mew: フィールドがない場合は、C-cC-f は From: を ID と考えます。また、C-uC-cC-f は、X-Mew: フィールドに加えて mew-x-pgp-key-list に指定されたフィールドも鍵 ID を切り出す対象とし、公開鍵の入手を試みます。

フォルダの更新と移動
==========

到着したメッセージを +inbox フォルダに移動し、一覧を表示するには i を使います。一覧は、+inbox フォルダの Summary モードの最後に挿入されます。

フォルダの一覧を再表示するには、s を使います。このコマンドは range を訊いてきます。Mew で重要な range の意味を以下に示します。

update
     「Summary モードの最後のメッセージ＋１」から「フォルダ内の最後のメッセージ」まで。つまり、Summary モードと実際のフォルダ内のメッセージの差分。

all
     フォルダ内のメッセージ全て。Summary モードの表示がおかしくなったときに、内容を一新するために用いる。

通常 range のデフォルトは、update となっています。ですから、 s の後に RET を押すだけで、現在のフォルダの最新一覧を得られることになります(Summary モードの移動に g を使うと、自動的に最新の一覧を表示しようとします)。

Mew ではあまり重要ではありませんが、以下の range も指定できます。

<num1>-<num2>
     <num1> から <num2> まで。

<num>:N
     <num> から N 個。

<num>:-N
     <num> までの N 個。

first:N
     最初から N 個。

prev:N
     現在のメッセージまでの N 個。

next:N
     現在のメッセージから N 個。

last:N
     最後のメッセージまでの N 個。

フォルダの移動には g を入力して下さい。フォルダ名は TAB で補完できます。もし、移動した際に Summary モードの一覧が古いと判断した場合は、range を訊いてきます。range のデフォルトは、+draft と +trash フォルダでは all になっています。それ以外では update になります。

送信、返答、転送
========

メッセージの送信、返答、転送には、以下のコマンドを使います。

w
     メッセージを書く。新しい草稿が Draft モードに用意される。

a
     現在のメッセージに返答する。Draft モードに草稿が用意され、To: や Cc: が自動的に決定される。

A
     現在のメッセージに返答する。Draft モードに草稿が用意され、To: や Cc: が自動的に決定された後、本文が引用される。

f
     現在のメッセージを第3者に転送する。Draft モードに草稿が用意され、現在のメッセージが自動的に添付される。

F
     @ マークの付いたメッセージを第3者に転送する。Draft モードに草稿が用意され、@ マークの付いたメッセージが自動的に添付される。詳しくは see multi mark を参照のこと。

エラーメッセージが返ってきたら、以下のコマンドで修正し再挑戦しましょう。

E
     メッセージの再編集。または、MIME 形式でカプセル化されて戻ってきたメッセージの再編集。+draft フォルダでは、そのメッセージを直接編集。その他のフォルダでは +draft フォルダにコピーしてから編集。

M-e
     "----- Original message follows -----" の後にオリジナルのメッセージが引用されてるエラーメッセージの再編集。

メッセージのソート
=========

フォルダ内のメッセージをソートするには S を使います。このとき次のようにどのフィールドでソートするか訊いてくるので、ソートしたいフィールド名を入力して下さい。

     Sort by? (default date):

ソートのモードを明示的に指定・変更したい場合には : で区切って指定します。たとえば X-Mail-Count フィールドの内容を(テキストとしてではなく) 数値とみなしてソートしたい場合には、次のように入力します。

     x-mail-count:num

なお、文字の大文字、小文字は区別しません。また、フィールド名やモードは TAB で補完できます。

ソートに関するコマンドをまとめると以下のようになります。

S
     入力したフィールドを用いてフォルダ内のメッセージをソートします。 C-u S のように prefix を付けると、リージョン内のメッセージのみをソートします。

mS
     * マークの付いたメッセージのソートをします。

便利な機能
=====

Mew では、Summary モードに以下のような便利なコマンドが用意されています。

v
     「Summary モードだけ」と「Summary & Message モード」の切り替え。「Summary モードだけ」を選んでいる場合は、d は次のメッセージを表示しないので、連続してすばやく D マークを付けられる。

M-a
     「MIME 解析モード」と「非解析モード」の切り替え。「非解析モード」では、本文を解析せず配送されたままの形で表示するので速い。

M-l
     現在の行を Summary モードの中央に移動させる。

C-cC-s
     Message モードで順方向差分検索。

C-cC-r
     Message モードで逆方向差分検索。

y
     メッセージをコピー、あるいは、パートを入力したファイル名で保存する。

#
     現在のメッセージかパートを印刷する。

|
     現在のメッセージかパートをパイプで出力する。

O
     メッセージを番号詰めして、再び一覧表示する。

B
     MIME でカプセル化された複数のメッセージをほどく。

Z
     alias のリストを更新する。C-uZ では、alias に加えフォルダのリストも更新する。mew-use-folders-file-p が t ならフォルダのリストを "~/Mail/.folders" に保存する。

化けたメッセージ
========

以下のようなメッセージは、charset がなく、US-ASCII と認識されてしまうので、化けます。

     To: kazu
     Subject: 化けるメッセージ
     From: Alice
     MIME-Version: 1.0
     Content-Type: Text/Plain

     日本語の本文

このような場合は、C-cC-l を押すと、文字コードを正しく変換し表示します。

メッセージを作成する
**********

ここではメッセージの作成方法について説明します。Mew では、MIME 形式のメッセージだけを作成できます(MIME-Version: のないメッセージは作成できません)。

Draft モードに移行するには、次の2つの手段があります。

 1. M-x mew-send と入力する。

 2. Summary モードで w を押す。

すると、以下のようなバッファが用意されます。

     To:
     Subject:
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     ----

これを Draft モードといいます。草稿は、+draft フォルダの下に作成されます。同時に複数の草稿を持つことが可能です。

以下、Draft モードの使い方を説明します。

ヘッダの補完
======

Draft モードにおいて、"----" から上をヘッダといいます。ヘッダでは TAB に対し、以下ように各フィールド用の完機能が割り当てられています。

  - フィールド名の補完

  - アドレスの別名の補完と展開 (To:、Cc: など)

  - フォルダ名の補完 (Fcc:)

<フィールド名の補完>

行頭の単語中で、しかも、上の行の最後が "," で終る継続行でなければ、 TAB で mew-fields に定義されているフィールド名を補完できます。

     To: kazu@mew.org
     RTAB

上記の場所で TAB を押すと以下のようになります。

     To: kazu@mew.org
     Reply-To:

<アドレスの別名の補完と展開>

IM では、alias という機能を使って、長く分かりにくいアドレスに短く覚えやすい別名を付けられます。たとえば、

     mine: m-sakura@ccs.mt.nec.co.jp

という別名は、mine という文字列を m-sakura@ccs.mt.nec.co.jp で置き換えることを意味しています。

Draft モードのヘッダ内で、かつ、アドレスを書くべきフィールド上で、しかも、 1文字以上の文字列が前にある場所で TAB を打つと、アドレスの別名が補完されます。

例を挙げてみます。

     To: toshi,
             miTAB

このように TAB を押すと、(他に候補が無ければ) mine まで補完されます。

     To: toshi,
             mineTAB

もう一度 TAB を押すと m-sakura@ccs.mt.nec.co.jp に展開されます。

     To: toshi,
             m-sakura@ccs.mt.nec.co.jp

アドレスが補完できない場所で TAB を打つと、単に TAB が入ります。たとえば、以下の例を考えて下さい。

     To: mine,TAB

この場合、単に TAB が挿入されます。

"@"で終る文字列は強制的に展開します。たとえば、以下のように似たような alias があった場合を考えて下さい。

     mine: m-sakura@ccs.mt.nec.co.jp
     mineo: mineo@sfc.wide.ad.jp

mine を m-sakura@ccs.mt.nec.co.jp に強制的に展開するには、以下のようにします。

     To: mine@TAB

<フォルダ名の補完>

Fcc: などのようにフォルダを補完すべきところでは、TAB でフォルダを補完できます。以下例を挙げてみます。

     Fcc: TAB

"+" が補完されます。

     Fcc: +TAB

TABをもう1度押すと候補が表示されるので、候補を見ながら適切な文字を入力します。

     Fcc: +BTAB

候補が一意に定まれば補完されます。

     Fcc: +Backup

<設定のヒント>

アドレスの別名とフォルダ名をどのフィールドで補完できるようにするかは、 mew-field-completion-switch で定義できます。デフォルトでは以下のように宣言されています。

     (defvar mew-field-completion-switch
       '(("To:"       . mew-complete-address)
         ("Cc:"       . mew-complete-address)
         ("Dcc:"      . mew-complete-address)
         ("Bcc:"      . mew-complete-address)
         ("Reply-To:" . mew-complete-address)
         ("Fcc:"      . mew-complete-folder)
         ("Config:"   . mew-complete-config))
       "*Completion function alist concerned with the key."
       )

Config: の補完に関しては see config を参照して下さい。

ヘッダの循環的な補完
==========

ヘッダでは、C-cTAB に循環的な補完機能が割り当てられています。循環的な補完機能とは、あるリストのある値がそのリストの次の値に置き換えられることです。リストの最後は、最初につながっていると考えます。ヘッダ中の循環的な補完機能は、以下のようにフィールドごとに異なります。

  - ドメイン名の循環的な補完 (To:、Cc: など)

  - From: の循環的な補完 (From:)

<ドメイン名の循環的な補完>

アドレスを書くべきフィールドでは、C-cTAB でドメインを補完します。補完の候補は mew-mail-domain-list から選ばれます。

     To: kazu@C-cTAB

上記の場所のように候補が一意に定まらない場合は、 mew-mail-domain-list の最初のドメイン名が挿入されます。

     To: kazu@mew.orgC-cTAB

補完された後、さらに C-cTAB を押すと mew-mail-domain-list の次の候補に変換します。

     To: kazu@wide.ad.jp

また、以下の補完が一意に定まれば、その候補を挿入します。

     To: kazu@wC-cTAB

上記の例は次のようになります。

     To: kazu@wide.ad.jp

<From: の循環的な補完>

From: フィールド上では、C-cTAB はmew-from-list の値を循環的に補完します。このリストの最初の値(別名 mew-from)は、次のように既に挿入されているかもしれません。

     From: Kazu Yamamoto (山本和彦) <Kazu@Mew.org>

値の場所ならどこでも構いませんが、C-cTAB と入力すると、この値を mew-from-list の次の値と置き換えます。たとえば、

     From: Kazu Yamamoto (山本和彦) <Kazu@Mew.org>C-cTAB

は以下のようになります。

     From: Kazuhiko Yamamoto <kazu@wide.ad.jp>

循環的な補完のフィールドと関数の対応は、 mew-field-circular-completion-switch で定義できます。デフォルトでは以下のように宣言されています。

     (defvar mew-field-circular-completion-switch
       '(("To:"       . mew-circular-complete-domain)
         ("Cc:"       . mew-circular-complete-domain)
         ("Dcc:"      . mew-circular-complete-domain)
         ("Bcc:"      . mew-circular-complete-domain)
         ("Reply-To:" . mew-circular-complete-domain)
         ("From:"     . mew-circular-complete-from)
         ("Config:"   . mew-circular-complete-config))
       "*Circular completion function alist concerned with the key."
       )

Config: の循環的な補完に関しては see config を参照して下さい。

メッセージの送信
========

草稿を書き上げ送信する準備ができたら、C-cC-m C-cC-c と入力して下さい。

たとえば、以下のようなメッセージを送る場合を考えます。

     To: mine
     Subject: PGP/MIME を使おうよ
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     ----
     Mew がセキュリティ・マルチパートをサポートしました。

     --かず

C-cC-m まで入力すると、以下のようになります。

     To: mine
     Subject: PGP/MIME を使おうよ
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     Content-Type: Text/Plain; charset=iso-2022-jp
     Content-Transfer-Encoding: 7bit

     Mew がセキュリティ・マルチパートをサポートしました。

     --かず

ここで注意して頂きたいのは、Content-Type: に Text/Plain を選び、charset を推測していることです。

次に C-cC-c と入力すると通常のテキストメッセージを送れます。メッセージはバックグランドで送信されます。このように C-cC-m は MIME の作成、C-cC-c は送信です。Mew では「できるだけ見たままのメッセージを送信する」というポリシーがあるので、ユーザに明示的に MIME を作ってもらうことにしています(今までに余分な .signature や Fcc: が勝手に付けられていやな思いをした人はいませんか？ :p)。

エラーが起きた場合は、"*Mew watch*" バッファを表示します。エラーが生じて消えなかった "*Mew watch*" バッファは、C-cC-q で消せます。多くの場合、草稿は +draft フォルダに残っています。そこで、Summary モードで g と押して +draft フォルダに移動し、+draft フォルダの Summary モードで E を押して再編集して下さい。

メッセージの送信が終っていないのに、C-xC-c で Emacs を終了させようとすると、

     Active processes exist; kill them and exit anyway? (yes or no)

と訊かれます。"*Mew watch*" バッファがなくなってから終了させて下さい。

C-cC-m は省略できます。この場合、MIMEを自動的に作った後に

     Content-Type: was automatically added. Send this message? (y or n)

と訊いてきますので、y を入力して下さい。Mewでは、見たままのメッセージを送信することをモットーにしているので、Mew が勝手にメッセージを書き換えた場合は、このように質問を受けます。

全てのメッセージ作成方法で C-cC-m を省略して構いません。ただし、見たままのメッセージを送信したい人は、C-cC-m C-cC-c と入力する癖を付けることをお勧めします。

カーソルのある場所に "~/.signature" を挿入するコマンドは C-cTAB です。シグニチャファイルは、mew-signature-file で設定できます。 mew-signature-as-lastpart や mew-signature-insert-last を設定することで、C-cTAB の動作をカスタマイズできます。

もし、アドレスの alias がどう展開されるか一度に知りたい場合は、 C-cC-w と入力して下さい。

出てきたコマンドを以下にまとめます。

C-cC-m
     MIME を作成する。Charset の推測、ファイル構造をマルチパートへ変換など。

C-cC-c
     メッセージを送信する。

C-uC-cC-c
     メッセージを送信するが、草稿は消さない。複数の人に内容を少しずつ変えながらメールを送りたい場合に便利。

C-cTAB
     カーソルの位置に "~/.signature" を挿入する。

C-cC-w
     アドレスの alias を展開し、別のウインドウに表示する。

引用
==

Summary モードの a や A を使ってメッセージに返答するための草稿を用意すると、Emacs が3分割されます。上が現在の Summary モード、中が Message モード、下が Draft モードです。

Message モードのテキストを引用するコマンドを以下に示します。

C-cC-y
     Message モードからメッセージの一部をコピー、引用ラベルと引用記号付でペーストする。

      1. おおまかに言えば、Message モードの本文がコピーされる。たとえば、 Text/Plain が表示されていると、Message モード全体がコピーされる。 Message/Rfc822 が表示されている場合は、ヘッダを除いた本文がコピーされる。

      2. C-u と共に呼ばれると、ヘッダがあればヘッダをコピーする。

      3. Emacs のマークがあると、そのマークとカーソルの間が対象となる。

C-cC-t
     Message モードからメッセージの一部をコピー、引用ラベルと引用記号なしでペーストする。

デフォルトの引用ラベルと引用記号は以下のようになります。

     From: SUMIKAWA Munechika <sumikawa@ebina.hitachi.co.jp>
     Subject: Wine
     Date: Wed, 23 Jul 1997 11:40:50 +0900

     > おはようからおやすみまでニートでおなじみの角川です。
     >
     > さて、とろけるワイン作戦ですが、定石通り '89 のボルドーの
     > カベルネ・ソービニョンを狙いたいと思います。ピノノアール
     > がちょっぴりブレンドしてあるといいかも。

Draft モードでは Message モード("*mew message*"バッファ)に表示されているものならなんでも引用できます。つまり、複数のメッセージを簡単に引用できるのです。引用したいメッセージを表示させて、本文を引用する手順を、引用したいメッセージの回数だけ繰り返して下さい。そのための3分割です。

Mew は supercite とリンクできますが、supercite は C-cC-m を奪ってしまうことがあります。適宜修正して下さい。mew.dot.emacs に入っているように設定すれば、以下のような引用が可能なので、supercite は不要かもしれません。詳しくは see level-three を参照して下さい。

     From: SUMIKAWA Munechika <sumikawa@ebina.hitachi.co.jp>
     Subject: Wine
     Date: Wed, 23 Jul 1997 11:40:50 +0900

     sumikawa> おはようからおやすみまでニートでおなじみの角川です。
     sumikawa>
     sumikawa> さて、とろけるワイン作戦ですが、定石通り '89 のボルドーの
     sumikawa> カベルネ・ソービニョンを狙いたいと思います。ピノノアール
     sumikawa> がちょっぴりブレンドしてあるといいかも。

もし、引用の様式が上記ではなく以下のようになるなら、 mail-citation-hook が定義されているのかもしれません。

     In article .....

Mew 独自の引用様式を使いたいなら、以下の行を ".emacs" に加えて下さい。

     (setq mail-citation-hook nil)

マルチパートの作成
=========

さて、ここでマルチパートの作り方を披露しましょう。

たとえば、+draft/1 でメッセージを書いているときに、C-cC-a と入力すると、草稿の一番下に

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
          2                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

という行が挿入されます。"1/" はマルチパートを構築するための一時的なディレクトリで、実体は "~/Mail/draft/mime/1" です。パート1の CoverPage は本文を意味します。ここで Draft モードは次のようになっているでしょう。

     To: mew-dist
     Subject: ここがヘッダ
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     ----
     本文だよ。

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
          2                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

3つの領域を以下のように呼ぶことにします。

  * "----" より上を 「ヘッダ」

  * "----" から "attachments" までを「本文」

  * "attachments" より下を「添付領域」

Draft モードでは、リージョンによってキー割当が違います(そんなことができるのかですって？ できたものはしょうがないでしょう)。

たとえば、TAB は以下のようになります。

ヘッダ
     さまざまな補完。

本文
     TAB の挿入。

添付領域
     なにもしない。

c だと以下のようになります。

ヘッダ
     c を挿入。

本文
     c を挿入。

添付領域
     ファイルのコピー。

以下、添付領域でのキー割当です。

C-p
     現在のディレクトリの前のファイルへ移動。

C-n
     現在のディレクトリの後のファイルへ移動。

C-f
     1番目のサブディレクトリに移動。

C-b
     親ディレクトリに移動。

c
     ファイルのコピー。"." 上で有効。ネットワーク経由でも可。リモートのファイルをコピーする場合は、"/[user@]hostname:/filepath"の形式でファイルを指定。

l
     ファイルへシンボッリクリンクを張る。"." 上で有効。

d
     ファイルとディレクトリの消去。

m
     サブディレクトリ(つまりマルチパート)の作成。"." 上で有効。

f
     ファイルをバッファに読み込む。

F
     新規ファイルをバッファに読み込む。"." 上で有効。

e
     external-body の入力。"." 上で有効。

a
     音をサンプリングしオーディオファイルとして挿入。"." 上で有効。

p
     入力されたユーザの PGP 公開鍵を取り出す。"." 上で有効。

D
     ちょっとした説明(Content-Description:)の入力。

T
     データ型(Content-Type:)の変更。

C
     Text/* 型のデータの charset を指定する。

P
     受信側でこのパートを保存する際のファイル名(Content-Disposition:)の変更。ファイル名の入力の際に、単に RETを押すと値が消える。そして、送信側のファイル名が * と共に表示される。

添付領域では、ファイルのサフィックスによってデータを取り扱います。現在サポートしているサフィックスは以下の通りです。

     .txt       Text/Plain
     .html      Text/Html
     .rtf       Text/Richtext
     .rfc822    Message/Rfc822
     [0-9]+     Message/Rfc822
     .ext       Message/External-body
     .ps        Application/PostScript
     .tar       Application/Octet-stream ;; dummy
     .gif       Image/Gif
     .jpg       Image/Jpeg
     .jpeg      Image/Jpeg
     .png       Image/Png
     .xwd       Image/X-xwd
     .xbm       Image/X-xbm
     .bmp       Image/X-bmp
     .au        Audio/Basic
     .mpg       Video/Mpeg
     .mpeg      Video/Mpeg
     .pgp       Application/Octet-Stream
     .pka       Application/Pgp-keys
     .*         Text/Plain

c でファイルをコピーすると、たとえば次のようになります。コピーするときのファイル名は、適切なデータ型を推測できるようサフィックスに気を付ければなんでもよいです。

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
     B    2  Image/Gif                    MagicPoint のロゴ          mgp.gif
     Q    3  Application/Postscript       資料                       ohp.ps
          4                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

各行は、マーク、パート番号、データの型、説明、ファイル名

から構成されています。マーク、データの型、説明、ファイル名はそれぞれ、 Content-Transfer-Encoding:、Content-Type:、Content-Description:、 Content-Disposition: の値になります。

マーク(Content-Transfer-Encoding:)を変更する方法は、see mark-b-comp を参照して下さい。データの型(Content-Type:)は T によって変えられます。説明(Content-Description:)は D で入力できます。この説明のカラムは、see mark-b-comp で説明する暗号化の際に上書きされます。

第5カラムに表示されるのは、実際にはコピーしたファイル名か Content-Disposition:、つまり、受信者がそのパートを保存する際のファイル名です。Content-Disposition: の値があれば、それが表示されます。なければ、コピーしたファイル名に * を付加して表示します。ファイルをコピーした際の Content-Disposition: の値は、コピーしたファイル名が指定されています。ただし、Message/* と Multipart/* には Content-Disposition: は設定されません。Content-Disposition: を指定するには、P を利用して下さい。

ファイルはシングルパートに、ディレクトリはマルチパートに対応します。ですから、ファイル構造を作っていく感覚で複雑なマルチパートを作成できます。簡単でしょ？

ディレクトリのデフォルトの Content-Type: は Multipart/Mixed です。これも T によって変更できます。

さて、お好みのマルチパートが作成できたら、C-cC-m とタイプしましょう。あーーーら不思議。ファイル構造がマルチパートへ変換されるではありませんか。むろん、多段のマルチパートもサポートしています。あとは、 C-cC-c で送るだけです。

MIME の文法が分かっていない人は、C-cC-m の後に草稿を変更しないようにしましょう。もし、どうしても草稿を修正するときは、「最初の境界の前と最後の境界の後は無視される」ことに注意して下さい。

マルチパートの変換後、やっぱり元に戻したいと思ったら、C-cC-u を使って下さい。たとえば、次に述べる PGP/MIME を作っている最中で、パスフレーズを3回入力に失敗したら、間違った MIME メッセージが作られてしまいます。こういうときには、C-cC-u が役に立ちます。

パートの実体が外部にある external-body を作成するコマンドe について説明しましょう。access-type に ftp か anon-ftp を入力するときは、 ange-ftp のおかげでリモートのファイル名が補完できます。access-type が local-file の場合は、もちろんファイル名を補完できます。

もし、マルチパートの作成途中でやっぱりシングルパートに戻したくなったら、一番上のマルチパート部分で d を押して下さい。

文字コードの推測
========

Mew はシングルパートとマルチパートの両方に対し、charset を推測する機能を持っています。

<シングルパート>

Draft モードで C-cC-m と入力すると、Mew は本文の charset を推測します。Bilingual Emacs では、7ビットの文字コードに対し US-ASCII を選び、8 ビットの文字コードに対し ISO-8859-1 を選択します。Mule では、Mule で定められた文字コードの内部表現から charset を推測します。

<マルチパート>

テキストファイルを添付領域に添付した際には、以下のように "(guess)" と表示されます。

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
          2  Text/Plain(guess)                                       textfile
          3                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

シングルパートとマルチパートで charset を推測することの違いは、データがどこに存在するかです。シングルパートはバッファに格納されていますが、マルチパートのそれぞれのファイルはディスク上に存在します。charset を推測するためには、Mew はこれらのファイルをバッファに読み込み、そしてシングルパートと同じ要領で文字コードを推測します。

Bilingual Emacs では、Mew はファイルをそのままの形式で読み込みます。ですから、7ビットのファイルには US-ASCII が、8ビットのファイルには ISO-8859-1 が選ばれます。

Mule では、Mew はファイルをそのサイトの環境(つまり、auto conversion)に従ってファイルを読み込みます。この環境はサイトごとによって異なります。日本語の環境では、Mule は ISO-2022-JP、EUC-Japan、そして、Shift JIS が見事に推測し、日本語用の内部表記に変換してバッファに格納します。Mew は、この内部表記から charset を推測します。よって、ISO-2022-JP、EUC-Japan、そして、 Shift JISのファイルを安全に添付できます。Mule でこの環境を決定する関数は、 set[up]-<language>-environment という名前ですから、詳しいことが知りたいならこれらの関数の説明を読んで下さい。

もし、ファイルの charset を明示的に指定したいなら、C を使って下さい。典型的な使用例は、日本で ISO-8859-1 のファイルを添付することです。この例の場合、添付領域は以下のようになります。

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
          2  Text/Plain(iso-8859-1)                                  textfile
          3                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

Bilingual Emacs では C は利用できません。

PGP を利用する
=========

ここでは、テキストである本文を PGP で署名したり暗号化したりする方法について説明します。出てくるコマンドは以下の通りです。

C-cC-s
     シングルパートの草稿を PGP で署名する。パスフレーズを入力すること。

C-cC-e
     シングルパートの草稿を PGP で暗号化する。

C-cC-b
     シングルパートの草稿を PGP で署名後暗号化する。パスフレーズを入力すること。

これらは、以下で説明するマークを使った PGP/MIME の作成方法の省略方法にあたります。

もし、Mew で PGP を使うなら、PGP の userid として電子メールアドレスを選ぶ必要があります(例 "Kazuhiko Yamamoto <kazu@mew.org>")。

以降の説明では、次の例を取り上げます。

     To: mine
     Subject: PGP/MIME を使おうよ
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     ----
     Mew がセキュリティ・マルチパートをサポートしました。

     --かず

署名するには、C-cC-s とタイプし、自分のパスフレーズを入力します。

********************************************************************
もし Emacs がローカルのコンピュータで動いていない場合は、パスフレー
ズを入力しないで下さい。入力すると盗聴される恐れがあります。
********************************************************************

パスフレーズを入力すると、次のメッセージが得られます。

     To: mine
     Subject: PGP/MIME を使おうよ
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     Content-Type: Multipart/Signed;
             protocol="application/pgp-signature";
             micalg="pgp-md5";
             boundary="--Security_Multipart(Sat_Nov_16_03:55:00_1996)--"
     Content-Transfer-Encoding: 7bit

     ----Security_Multipart(Sat_Nov_16_03:55:00_1996)--
     Content-Type: Text/Plain; charset=iso-2022-jp
     Content-Transfer-Encoding: 7bit

     Mew がセキュリティ・マルチパートをサポートしました。

     --かず

     ----Security_Multipart(Sat_Nov_16_03:55:00_1996)--
     Content-Type: Application/Pgp-Signature
     Content-Transfer-Encoding: 7bit

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.3i

     iQCVAwUAMoy8ig9kihyeT3RNAQHt7AQAySDg4n8pOp/YuLaAp68Un/YDtWS0FnOC
     7EqHJd6fyViPBnZq8d+uGikA7kOBTz+8Kcv+hN6I7BrQVJGEzd0Y9yHHhXvZj++1
     0D09vgWL5G/Zfk/JMnLBt/BZ1ppOhJPT/L5qi2abk+mBVMKxQe071lfFEfvjF1C2
     8trTXm/bBz4=
     =TvAG
     -----END PGP MESSAGE-----

     ----Security_Multipart(Sat_Nov_16_03:55:00_1996)----

C-cC-c で送信して下さい。

暗号化するには、C-cC-e と入力して下さい。(パスフレーズなしで)次のようになります。

     To: mine
     Subject: PGP/MIME を使おうよ
     X-Mailer: Mew version 1.93 on XEmacs 20.4
     Mime-Version: 1.0
     Content-Type: Multipart/Encrypted;
             protocol="application/pgp-encrypted";
             boundary="--Security_Multipart(Sat_Nov_16_03:57:47_1996)--"
     Content-Transfer-Encoding: 7bit

     ----Security_Multipart(Sat_Nov_16_03:57:47_1996)--
     Content-Type: Application/Pgp-Encrypted
     Content-Transfer-Encoding: 7bit

     Version: 1

     ----Security_Multipart(Sat_Nov_16_03:57:47_1996)--
     Content-Type: Application/Octet-Stream
     Content-Transfer-Encoding: 7bit

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.3i

     hIwDD2SKHJ5PdE0BA/9gUkcQYVfT+3LrUmcgLkNepuOnDfjADHrWiNo10t4ijyf8
     ODBpUBXoBdTg08eNLAWmRFhiJPmI+mxpF6cYFZXhr7gVpa0Qzp3Gr9nYvngRPKNK
     qUiQjA/ORR3c1TBawufB19jJ9RdU2f0BidhzOSbzsJh1LTgUZu/7Qyd02LxyEqYA
     AACbrV867PeoFyFc9MVfqTUR6Zw6kGBAlnVYjqQgBhuuyG79vbAbDJMhFiRpoRPf
     0MqEewxRonwKOik/PoKnLrwFg77Cb5pxRqMiWPyECJnqtX7r7Wg1c8kqPD0VRjI9
     GhHPiG/RmNbpbj/5g6zZri1YBCe8qxIS0QKa3YO7HRDcdBFARr22RaFGFtgdBQ6X
     cZB+qNeEaKXt3AneTWc=
     =djCr
     -----END PGP MESSAGE-----

     ----Security_Multipart(Sat_Nov_16_03:57:47_1996)----

C-cC-c で送信して下さい。このメッセージは、受信者の公開鍵に加えて、自分の公開鍵でも暗号化されています。ですから、保存したメッセージを復号化できます(例 g で +Backup に移動したとき)。

署名後暗号化するには、C-cC-b とタイプ後、パスフレーズを入力します。 C-cC-c で送信して下さい。このメッセージは、受信者の公開鍵に加えて、自分の公開鍵でも暗号化されています。ですから、保存したメッセージを復号化できます(例 g で +Backup に移動したとき)。

3回パスフレーズの入力に失敗すると Draft モードがおかしくなりますが、 C-cC-u で元に戻ります。

マークを使った PGP/MIME の作成
====================

PGP/MIME をサポートするために、マークを使った作成方法が提供されています。以前の例を思い出してみましょう。

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
     B    2  Image/Gif                    MagicPoint のロゴ          mgp.gif
     Q    3  Application/Postscript       資料                       ohp.ps
          4                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

行頭に B や Q といったマークがあります。このマークは符号化を意味しています。Mew では、新しい概念「符号化」を導入しています。符号化には、Base64, Quoted-Printable, Gzip64(Gzip + Base64), PGP で署名, PGPで暗号化などがあります。

現在次の 6 つのマークがサポートされています。

" "
     符号化しない。ただし、8ビットのテキストは Quoted-Printable で符号化されるかもしれない。

B
     Base64

Q
     Quoted-Printable

G
     Gzip64(gzip 圧縮し Base64 で符号化する。Mew が実験的に採用している。相手が Mew を使っていない場合は、使用すべきではない。)

PS
     PGP で電子署名。

PE
     PGP で暗号化。

添付領域でのマークに関係する新しいキー割当は以下の通りです。

B
     Base64 で符号化するため B マークを付ける。

Q
     Quoted-Printable で符号化するため Q マークを付ける。

G
     Gzip64 で符号化するため G マークを付ける。ただし、Text/Plain と Application/Postscript でしか実行できない。これ以外の型には圧縮は無意味である。なぜなら、jpeg などはあらかじめ圧縮されているから。

S
     PGP で署名するため PS マークを付ける。

E
     PGP で暗号化するため PE マークを付ける。受信者のアドレスを入力する。

U
     符号化を元に戻す。もともとのマークに戻る。

次の例を考えてみましょう。パート2は PGP で署名され、"kazu" 用に PGP で暗号化されます。安心して下さい。説明の部分は上書きされていますが、保存されています。パート3は Gzip64 で符号化されます。

     ----------------------------- attachments -----------------------------
           Multipart/Mixed                                         1/
          1  Text/Plain(guess)                                       CoverPage*
     PSPE 2  Image/Gif                    kazu@mew.org               mgp.gif
     G    3  Application/Postscript       資料                       ohp.ps
          4                                                          .
     --------0-1-2-3-4-5-6-7-8-9--------------------------------------------

適宜マークを付けた後は、C-cC-m で MIME(PGP/MIMEなど) を作成し、 C-cC-c で送信して下さい。

3回パスフレーズの入力に失敗すると Draft モードがおかしくなりますが、 C-cC-u で元に戻ります。

PGP の鍵の配布
=========

PGP の公開鍵を配布するには、Draft モードの添付領域で p を押して下さい。だれの公開鍵を配布するか尋ねられます。自分の公開鍵であれば、単に RET と入力して下さい。他人の公開鍵であれば、補完を利用しながらその人のアドレスを入力して下さい。PGP の公開鍵は、Application/Pgp-keys というデータ型で配送されます。

Summary モード、あるいは、Virtual モードでメッセージを読んでいる際に、あるパートのデータ型が Application/Pgp-keys であれば、Mew は PGP の公開鍵リングにそれを登録しようとします。Mew は、「信用度」と「有効性」を全く考慮しないことに注意して下さい。これらの値を設定するのは、あなた自身です。設定には、"pgp -ke" と "pgp -ks" を使って下さい。もし、「信用度」と「有効性」の意味が分からなければ、PGP を使って自分のプライバシを保護しようとする前に、PGP が提供する「信用の輪」とは何かを学ぶべきです。

愉快なマークたち
********

ここでは、Summary モードで利用できるマークについて説明します。マークは以下のように、数字の右に付きます。

         1D 07/17 いとぢゅん     v6: items to be no in6_pcbnotify()がなにも
         2o 07/18 歌代先生       Re: behavior after これ、mark-ring がどんど
         3* 07/19 のむさん       refile info.       乃村です。遅くなりました。

現在利用できるマークは以下の4つです。

D
     消去のマーク。

o
     整頓、つまり、フォルダを移動させるマーク。

@
     複数のメッセージを一度に扱うためのマーク。

*
     後から読み返すためのマーク。

以下それぞれについて説明します。

消去 D
====

メッセージを消去するには、まず Summary モードで d を押して、 D マークを付けます。マークを付けただけでは何も起こらないので、間違って d を押しても大丈夫です。デフォルトでは、x を押すと D マークの付いたメッセージが +trash フォルダに移動します。

+trash フォルダ内のメッセージを実際に消去するには、デフォルトでは以下の 2 つの方法があります。

 1. コマンドラインで imclean を実行する。

 2. +trash フォルダ内で D マークを付けて、x を押す。

これまでしつこいように「デフォルトでは」と念を押してきました。ここでいうデフォルトとは、mew-msg-rm-policy が'trashonly であるということです。mew-msg-rm-policy は以下のような値をとれます。それぞれの説明は x を押した際の動作についてです。

'totrash
     +trash フォルダ以外のフォルダでは、Dマークの付いたメッセージが +trash フォルダに移動します。+trash フォルダでは単にマークが消えます。

'always
     D マークの付いたメッセージは実際に消去されます。

'trashonly
     +trash フォルダの D マークの付いたメッセージは、実際に消去されます。それ以外のフォルダにある D マークの付いたメッセージは、+trash フォルダに移動します。

'uselist
     mew-msg-rm-folder-list で指定されたフォルダの D マークの付いたメッセージは、実際に消去されます。それ以外のフォルダにある D マークの付いたメッセージは、+trash フォルダに移動します。

それ以外
     'totrash と同様に扱われます。

自分の好きなように x の動作をカスタマイズして下さい。

全ての * マークを D に変換できれば、一度にたくさんの D マークを付けれて便利です。これには、md を利用して下さい。

以下に、D マークに関するコマンドをまとめます。

d
     D マークを付ける。

x
     D マークの付いたメッセージを mew-msg-rm-policy に従って処理する。

md
     * マーク全てを Dマークに変換する。

整頓 o
====

メッセージを整頓するには o を押して、整頓先のフォルダを入力し、 o マークを付けます。整頓先のフォルダは、賢く推測してくれるので、ほどんどの場合はフォルダ名を入力する代わりに RET を押すだけです。 "," で区切って複数のフォルダを入力することもできます。もちろん、 TAB で補完できます。詳しくは see Refile を参照して下さい。

o マークの付いたメッセージの上で o を押すと、整頓先を追加したり変更したりできます。また、実際の整頓は x と入力されたときに実行されます。

以下に、o マークに関するコマンドをまとめます。

o
     o マークを付ける。

x
     o マークの付いたメッセージを整頓する。

mo
     * マークの付いたメッセージに対し入力されたフォルダへ整頓するための o マークを付ける。

複数 @
====

複数のメッセージを一度に取り扱うためには、@ マークを付けます。 @ マークが付いた単数／複数のメッセージを取り扱うコマンドは以下の通りです。

@
     @ マークを付ける。

F
     @ マークの付いたメッセージを MIME 形式で転送するための草稿を準備。

M-s
     @ マークの付いたメッセージを "unshar" の入力として渡す。つまり、 shar (の後に split)されたデータを取り出す。

M-t
     @ マークの付いたメッセージを "uumerge" の入力として渡す。つまり、 uuencode(の後に split)されたデータを取り出す。

M-s や M-t では、@ マークの付いたメッセージの番号がきちんと分割順になっている必要があります(番号はとびとびでも構いません)。ちゃんと順番になってないなら、S でソートするとよいかもしれません。

復習 *
====

後から読み返したいメッセージには、* で * マークを付けて下さい。また、選択コマンド ? を使うと、入力した条件にマッチするメッセージに* マークが付きます(詳しくは、see Pick を参照して下さい)。 N や P で * マークの付いたメッセージに移動し表示できます。

以下に、* に関連するコマンドを示します。

*
     * マークを付ける。

N
     下方向の * マークの付いたメッセージへ移動し表示。

P
     上方向の * マークの付いたメッセージへ移動し表示。

ma
     マークの付いていないメッセージ全てに * マークを付ける。

mr
     入力した正規表現にマッチしたメッセージに * マークを付ける。

md
     * マークを D マークに変換。選択コマンド ? で選んだメッセージを消去するときに便利です。

mo
     * マークを o マークに変換。選択コマンド ? で選んだメッセージをあるフォルダに整理する場合に便利です。

マークの消去
======

o マークや D マークが付いたメッセージは、マーク実行コマンド x を押さない限り処理されません。よって、x を押す前に、マークを取り止めるコマンド u でマークを消せば、誤ってメッセージを消すことはありません。

以下にマークを消去するコマンドをまとめます。

u
     現在のメッセージのマークを消す。

U
     入力したマークが付いている全てのメッセージのマークを消す。

マークの強さ
======

マークには「強いマーク」と「弱いマーク」があります。同じレベルのマークは上書きできます。強いマークは弱いマークを上書きできます。

マークを付けた際の動作は、以下の通りです。

強いマーク :: o と D
     新たにマークしたときは、次のメッセージを表示。上書きした場合は、その行に留まる。

弱いマーク :: * と @
     常にその行に留まる。

マークは以下のように交換できます。

m@
     * -> @ :: 選択コマンド ? で選び、"uumerge" を起動するコマンド M-t を利用する場合に便利です。

m*
     @ -> *

ms
     @ <-> *

md
     * -> D :: 選択コマンド ? で選んだメッセージを消去するときに便利です。

mo
     * -> o :: 選択コマンド ? で選んだメッセージをあるフォルダに整理する場合に便利です。

楽々整理整頓
******

1日に数百のメッセージを受け取るようになると(え、そんなに受け取らないですって？幸せですね。:) 整理整頓が大変になります。Mew では、o でメッセージを整理する際に、整頓先を推測しデフォルト値として表示してくれます。たとえば、次のようになります。

     Folder name (+work/mew-dist): +

もし、() のなかのデフォルト値が自分の希望通りであれば、RET を押すだけでよいのです。整頓先が決定しているメッセージには、o マークが付きます。

この整頓先の推測が賢ければ賢い程ユーザは楽になります。Mew では以下のようなルールが用意されています。

フォルダ名から推測
=========

ヘッダの情報を見ただけでは、整理先となるフォルダの候補は無限です。よって、なんら手がかりのない状態で、メッセージから整頓先を決定するのは無理な話です。しかし、フォルダ名の一覧は限りありますから、この中から整理先を選び出すことはそんなに難しいことではありません。

たとえば、+work/happy-networking というフォルダがあったとしましょう。次のようなメッセージは、このフォルダに整頓すればよい可能性が高いといえます。

     To: happy-networking@mew.org

このように、To: や Cc: のアドレスが、フォルダ名の一番右側にマッチするものがないか探すわけです。フォルダを階層化していない人が多いようですが、 Mew を使う限り、階層化しない手はありません。

さて、鋭い人は次の様なときに困るのではないかと思うでしょう。

     To: simozono
     Cc: happy-networking@mew.org

kazu は happy-networking の一員ですから、このメッセージが届きます。しかし、simozono さんと仲がいいので ~/Mail の下の +simozono にマッチしてしまいます。

そこで、Mew では無視するフォルダを設定できるようになっています。デフォルトでは、"~/Mail/from" 以下を無視します。ですから、個人からのメッセージは "~/Mail/from" に収めて下さい

候補が決定できたら

     Folder name (+work/happy-networking): +

と訊いてきます。あっていれば RET を、違っていればお望みのフォルダを入力して下さい。

o で新しいフォルダを指定すると、そのフォルダが自動的に作成され、次からは推測用の候補にも加わります。便利でしょ？

この機能を提供する関数は mew-refile-guess-by-folder です。

指定したルールから推測
===========

フォルダ名から推測する機能だけでは、思うようなフォルダを推測してくれない場合があります。たとえば、

     To: staff@mew.org

と

     To: staff@iijlab.net

は、フォルダ名からの推測では同じフォルダ(たとえば、"+net/staff")が選ばれてしまいます。そこで、Mew では、変数 mew-refile-guess-alist に明示的にルールを設定できます。

1つ例を挙げてみましょう。

     (setq  mew-refile-guess-alist
       '(("To:"
           ("staff@mew.org" . "+net/mew/staff")
           ("staff@iijlab.net" . "+net/iijlab/staff")
          )))

これは、メッセージヘッダ中の To: の横の文字列に staff@mew.org があれば +net/mew/staff へ、staff@iijlab.net があれば +net/iijlab/staff へ整頓するという意味です。

ルールは、以下のように書きます。

     rule ::= '((<key> <alist>) (<key> <alist>) (<key> <alist>) ...)

全体は (<key> <alist>) のリストです。<key> はフィールド名を書きます。 <alist> は以下のようになります。

     <alist> ::= (<value> . <folder>|<rule>) (<value> . <folder>|<rule>) ...

<value> は <key> で示したフィールドにくる値です。<folder> は <key> にマッチした際にどのフォルダに整頓するかを意味しています。<value> と <folder> を . で区切るのを忘れないで下さい。<folder> の代りに <rule> を再帰的に記述することもできます。

特殊な <key> として nil と t があります。nil は、何も推測できなかった場合に返す <value> を指定するために用います。t は、推測した値に加えて返す <value> を指示するために使います。

正規表現を知っている人は、以下のような複雑なルールを設定できます。

     (setq mew-refile-guess-alist
       '(("Newsgroups:"
         ("^nifty\\.\\([^ ]+\\)" . "+Nifty/\\1")
         (".*"         . "+rec/news"))
        ("To:"
         ("\\(inet\\|wide\\)@wnoc-fuk" . "+wide/\\1-wnoc-fuk"))
        ("From:"
         ("uucp@"      . "+adm/uucp")
         ("ftpsync@"   . "+adm/ftpsync"))
        (nil . "+unknown")))

この機能を提供する関数は mew-refile-guess-by-alist です。

Message-ID から推測
===============

In-Reply-To: フィールドの Message-Id をたどり、親のメッセージがかつてどこに整頓されたかによって推測する機能があります。

たとえば、Alice、Bob、Chris との間で、スキーに行こうという話題が盛り上がったので、+tmp/ski というフォルダを作って、そこに 整頓したとしましょう。以降、3人の間のメッセージがきちんとした返答であるかぎり、+tmp/ski を推測してくれるでしょう。

Message-Id とフォルダの情報は、"~/Mail/.mew-refile-msgid-alist" に保存されています。この情報を過去何通のメッセージに関して保存するかは、 mew-refile-alist-max-length で決定します。500通にしたい場合は "~/.emacs" 中で以下のように設定して下さい。

     (setq mew-refile-alist-max-length 500)

この機能を提供する関数は mew-refile-guess-by-msgid です。

From: から推測
==========

同じ From: フィールドを持つメッセージがかつてどこに refile されたかによって推測する機能があります。

Alice がスキーのための宿の情報をメッセージしてきました。きちんとした返答メッセージではないので、Message-ID からの推測からでは正しく推測できません。しかし、+tmp/ski を選んで欲しいのが人情です。直前の彼女からのメッセージが +tmp/ski に整理されていれば、正しく +tmp/ski を推測してくれるでしょう。

その他、機械からくるメッセージは、いつも +adm/misc に入れることにしたい場合なども、明示的なルールを書かずに済ませられます。

この機能を提供する関数は mew-refile-guess-by-from です。

Newsgroups: から推測
================

ネットニュースをメッセージで受けて Mew で読んでいる人のために、 Newsgroups: からフォルダを推測する機能を用意しました。将来 Mew がネットニュースをサポートした場合にも有効でしょう。関数名は mew-guess-by-newsgroups です。

デフォルトの規則
========

デフォルトの規則は、From: からユーザ名を切り出して、 +from/username を選ぶようになっています。関数名は、 mew-refile-guess-by-default です。

ルールの制御
======

Mew では、フォルダ推測のルールを2つの変数、 mew-refile-guess-control と mew-refile-ctrl-multi で制御します。mew-refile-guess-control は、呼び出す関数を順に定義します。候補を複数にしたい場合は mew-refile-ctrl-multi を t に、単数にしたい場合は nil に設定します。

標準では、mew-refile-guess-control は以下のように宣言されています (宣言なので defvar が使われています)。

     (defvar mew-refile-guess-control
       '(
         mew-refile-guess-by-alist
         mew-refile-guess-by-newsgroups
         mew-refile-guess-by-folder
         mew-refile-ctrl-throw
         mew-refile-ctrl-auto-boundary
         mew-refile-guess-by-msgid
         mew-refile-guess-by-from
         mew-refile-guess-by-default
         )
       )

Mew は mew-refile-guess-control に並べられた関数を順番に全て実行します。各々の関数が複数の候補を推測することがあります。

mew-refile-guess-control の動作例として以下を考えてみましょう。

mew-refile-guess-by-alist
     が +aaa, +bbb を推測。

mew-refile-guess-by-folder
     が +ccc, +ddd を推測。

mew-refile-guess-by-default
     が +eee       を推測。

+aaa 〜 +eee 全てをユーザに提示して欲しい場合は、 mew-refile-ctrl-multi を t に, +aaa だけを提示して欲しい場合は、nil に設定します。

また、+aaa 〜 +ddd は提示して欲しいけれどもそれ以降はいらない、つまり、 +eee を提示するのは先に実行された関数群が何も推測できなかったときだけにしたい場合は、mew-refile-ctrl-multi を t にして、 mew-refile-guess-by-folder と mew-refile-guess-by-default の間に mew-refile-ctrl-throw を入れて下さい。

自動で整理整頓
=======

毎日メッセージをたくさんもらう人は、まだ整理していないメッセージを +inbox フォルダに大量に溜めてしまうことがあります。そんなときは、「メッセージ達よ、とにかく +inbox フォルダからどこかに行ってしまえ」と叫びたくなることがあるでしょう。Mew は、そんなわがままなを満足させるための自動整理整頓関数を提供しています。:)

M-x mew-summary-auto-refile がその呪文です。あまりに恐しい呪文なので、キーにはバインドされていません。この関数を実行すると、現在のフォルダ内の o や D マークが付いていないメッセージについて、自動的に o マークを付けてくれます。整頓先の決定には、先に説明した推測関数群が働くようになっています。この関数は、o を付けるだけですので、x を押さない限り実際にメッセージがどこかに行ってしまうことはありません。

Mew の整頓先推測はあまりにも賢すぎるので、この機能には仇となってしまいす。というのは、Mew が推測機能をフルに使って勝手に整頓してしまうと、大抵のユーザはどこにメッセージが整頓されたか分からなくなってしまうのからです。:) そのために、Mew が使う推測関数を制限する機能が提供されています。前に出てきた宣言をもう一度思い出して下さい。

     (defvar mew-refile-guess-control
       '(
         mew-refile-guess-by-alist
         mew-refile-guess-by-newsgroups
         mew-refile-guess-by-folder
         mew-refile-ctrl-auto-boundary
         mew-refile-guess-by-msgid
         mew-refile-ctrl-throw
         mew-refile-guess-by-from
         mew-refile-guess-by-default
         )
       )

mew-refile-guess-control の中に mew-refile-ctrl-auto-boundary という関数があります。これがその仕掛です。自動整理整頓のときに限り、Mew はこの関数より下に記述してある推測を無視します。mew-refile-ctrl-auto-boundary より上に記述している関数が何も推測できなかった場合は、そのメッセージには o が付きません。破滅が訪れる前に mew-refile-ctrl-auto-boundary の御札を貼って下さい。

お目当てのメッセージを選択するには
*****************

たとえば、Subject: に party という文字が含まれているメッセージを見つけ出したり、From: が kazu@mew.org であるメッセージを選択したいと思うことがあります。このように、入力した条件にあるメッセージを見つけ出すコマンドを Mew は 3 つ提供しています。

?
     入力した条件に合うメッセージに * マークを付ける。現在の Summary モードの一覧を利用する。? を押した後に、条件を入力して下さい。

/
     入力した条件に合うメッセージを Summary モードに一覧表示する。現在の Summary モードの一覧は上書きされます。/ を押した後に、フォルダ名と条件を入力して下さい。

V
     複数のフォルダから入力した条件に合うメッセージを見つけ出して Virtual モードに一覧表示する。操作は、see virtual を参照して下さい。

以下条件の入力方法と Virtual モードに付いて解説します。

条件の入力方法
=======

Mew が条件の入力をユーザに促すときは以下のように訊いてきます。

     pick pattern:

以下に示すキーワードを組み合わせて条件を入力して下さい。

field=string
     フィールド field に文字列 string が含まれているときマッチ。フィールド field が、head、body、および、all の場合は、それぞれヘッダ全体、本文、メッセージ全体を意味します。

<pattern1> & <pattern2>
     <pattern1> かつ <pattern2> のときマッチ。

<pattern1> | <pattern2>
     <pattern1> または <pattern2> のときマッチ。

! <pattern>
     <pattern> でないときマッチ。

( <pattern> )
     <pattern> の内容を先に評価。

以下に例を示します。

(a) From: に kazu か含まれるメッセージ

     from=kazu

(b) To: が mew、または、Cc: が mew であるメッセージ

     to=mew | cc=mew

(c) To: が mew、または、Cc: が mew で、かつ、from が kazu であるメッセージ

     (to=mew | cc=mew) & from=kazu

後は類推して下さい。

Virtual モード
===========

Virtual モードは、複数のフォルダから入力した条件に合うメッセージを選びだし、単一の仮想的なフォルダとして扱います。Summary モードで V を押すと、Virtual モードが作れます。

最初に、仮想フォルダ名を訊かれます。

     Virtual folder name (virtual) :

任意の文字列を入力して下さい。単に RET を押すと、"++virtual" になります。次に、単数または複数のフォルダ名を入力します。複数のフォルダを入力する場合は、"," で区切って下さい。もちろん、TAB で補完できます。

     Folder name (+inbox) : +inbox, +mew

そして、条件を入力します。

     pick pattern:

すると仮想フォルダができあがります。Virtual モードは、整頓や消去、検索など一部のコマンドを除いて、Summary モードと一緒です。仮想フォルダはまさしく仮想であり、ファイルシステムなどには存在しないことに注意して下さい。 Emacs を終了すると、仮想フォルダはなくなります。

一休み
***

Mew を終了させたり、一時中断させたり、そのモード(正確にはバッファ)を消去する方法を以下に示します。

<Summary モードと Virtual モード>

q
     Mew を一時中断し、他のバッファに切り替えます。Mew 用のバッファは全て残っていますから、バッファ操作で選べば再開できます。

Q
     Mew を終了します。Mew が使った全てのバッファを消去します。

C-cC-q
     そのモード(正確にはバッファ)を消去します。

<Draft モード>

C-cC-q
     その草稿を消去します。

<"*Mew watch*" バッファ>

C-cC-q
     そのバッファを消去します。

自分好みの Mew にするには
***************

ここでは、Mew のデフォルトの動作を変更し、自分好みの Mew にする方法を説明します。主に "~/.emacs" で設定して下さい。

初級
==

ここでは、以下の変数について説明します。

  - mew-draft-mode-hook

  - mew-from

  - mew-fcc

  - mew-cc

  - mew-dcc

  - mew-window-use-full

  - mew-summary-show-direction

Draft モードでは、text-mode-hook、mew-draft-mode-hook の順で評価します。text-mode-hook で auto-fill-mode の設定していない人は、 mew-draft-mode-hook を以下のように設定するのがよいかもしれません。

     (setq mew-draft-mode-hook (function (lambda () (auto-fill-mode 1))))

電子メールの管理者が設定しているのとは違うアドレスで送信したいことがあります。たとえば、管理者の設定が甘く、不要なホスト名が付いてしまう場合などです(この場合は管理者に頼み設定を修正してもらうのが一番です)。Mew では草稿のヘッダに From: アドレスがあれば、それがそのまま From: となります。補完を使いながら書いて下さい。いつも草稿に From: を用意するには、以下の例のように mew-from を指定して下さい。

     (setq mew-from "Kazu Yamamoto (山本和彦) <Kazu@Mew.org>")

From: 行を自分で指定できるということは、簡単にだれかになりすませるということです。くれぐれもこの機能を使ったいたずらをしないでください。また、他人も容易にだれかになりすませることに注意して下さい。大切な用件は、 PGP/MIME を使って送りましょう。

毎回 Fcc: でバックアップを取りたい人は、以下を .emacs に設定して下さい。

     (setq mew-fcc "+Backup")

自分へ Cc:(Dcc:) したい人は mew-cc(mew-dcc)を設定して下さい。

いつも Emacs のフレーム全体で Mew を使いたい人は、以下の設定をして下さい。

     (setq mew-window-use-full t)

Summary モードの SPC は、mew-summary-show-direction によって、次のメッセージの表示の仕方が変わります。以下の値を設定できます。

up
     上のメッセージを表示する。

down
     下のメッセージを表示する。

next
     読み進めている方向の次のメッセージを表示する。

stop
     次は表示しない。

デフォルトは 'next です。いつもメッセージを下から読む人は、以下のようにすればよいでしょう。

     (setq mew-summary-show-direction 'up)

中級
==

ここでは、以下の変数について説明します。

  - mew-use-highlight-cursor-line

  - mew-use-highlight-mouse-line

  - mew-use-highlight-mark

  - mew-use-highlight-header

  - mew-use-highlight-body

  - mew-use-highlight-url

  - mew-use-highlight-x-face

mew-use-highlight-cursor-line が t の場合、Summary モードでカーソルのある行に下線が引かれます。デフォルトは t です。

XEmacs では mew-use-highlight-mouse-line が t の場合、 Summary モードでマウスのある行に色がつきます。真中のボタンをクリックしながら、マウスだけでメッセージを読む際にはとても便利です。XEmacs でのデフォルトの値は、t になっています。

mew-use-highlight-mark が t で、かつ、 mew-highlight-mark-folder-list に列挙したフォルダが Summary モードである場合、マークの付いている行に色がつきます。 mew-highlight-mark-folder-list のデフォルトは '("+inbox") であり、 mew-use-highlight-mark のデフォルトは t です。

mew-use-highlight-header が t の場合、Message モードと Draft モードでヘッダが色付けされます。デフォルトは t です。

mew-use-highlight-body が t の場合、Message モードと Draft モードで本文が色付けされます。デフォルトは nil です。

mew-use-highlight-url が t の場合、Message モードの URL を示す文字列が強調されます。デフォルトは t です。

mew-use-highlight-x-face が t で、かつ XEmacs を使っている場合、ヘッダ中の X-Face: が Message モードでアイコン化されます。XEmacs でのデフォルトは t です。

上級
==

ここでは、以下の変数について説明します。

  - mew-header-alist

  - mew-cite-fields

  - mew-cite-format

  - mew-cite-prefix

いつも入れて欲しいヘッダは、mew-header-alist に連想リスト形式で定義して下さい。以下に例を示します。

     (setq mew-header-alist
           '(("X-fingerprint:" . "6B 63 38 88 67 5E 96 8E  CE A4 62 73 3F 11 64 94")
             ("X-URL:" . "http://www.mew.org/~kazu/")))

引用ラベルは、引用するフィールドを mew-cite-fields、ラベルの書式を mew-cite-format に定義します。引用記号は mew-cite-prefix に指定します。デフォルトは、以下のようになっています。

     (defvar mew-cite-fields '("From:" "Subject:" "Date:"))
     (defvar mew-cite-format "From: %s\nSubject: %s\nDate: %s\n\n")
     (defvar mew-cite-prefix "> ")

引用ラベルに Message-ID: を加え、ユーザ名付の引用記号にするには、以下のようにします。

     (setq mew-cite-fields '("From:" "Subject:" "Date:" "Message-ID:"))
     (setq mew-cite-format "From: %s\nSubject: %s\nDate: %s\nMessage-ID: %s\n\n")
     (setq mew-cite-prefix-function 'mew-cite-prefix-username)

フック
===

Mew で用意されているフックをまとめます。

mew-init-hook
     Mew の起動時に評価されます。

mew-summary-mode-hook
     Summary モードに入るときに評価されます。

mew-virtual-mode-hook
     Virtual モードに入るときに評価されます。

mew-message-mode-hook
     Message モードに入るときに評価されます。

mew-message-hook
     メッセージが Message モードで表示される度に評価されます。

mew-draft-mode-hook
     Draft モードに入るときに評価されます。

mew-cite-hook
     Draft モードで引用する際に呼ばれます。通常 supercite を設定するために使います。

mew-send-hook
     メッセージを送信する前に評価されます。

mew-quit-hook
     Mew の終了時に評価されます。

mew-summary-inc-sentinel-hook
     imget が終了する際に評価されます。

mew-summary-scan-sentinel-hook
     imls が終了する際に評価されます。

mew-summary-exec-hook
     Summary モードの x の実行が終了する際に評価されます。

Config
======

IM の "Config" ファイルに case 文を記述すると imget や imput の挙動を変化させられます。たとえば、Config が以下のように記述されていたとしましょう。

     Imget.Src=pop/apop:kazu@mail.mew.org
     FromDomain=Mew.org
     case wide
     Imget.Src=pop/rpop:kazu@mx.wide.ad.jp
     FromDomain=wide.ad.jp
     case iijlab
     Imget.Src=imap:kazu@mailbox.iijlab.net
     FromDomain=iijlab.net

通常では、imget は APOP を使って mail.mew.org から kazu のメールを読み込みます。また、imput は送信されるメッセージに From: がない場合(mew-from が nil の場合など)、ユーザ名である kazu と Mew.org を @ で連結した文字列を From: に指定します。

もし --config=wide が指定されると、imget は RPOP を使って mx.wide.ad.jp から kazu のメールを読み込みます。また、imput は From: に対し kazu@wide.ad.jpを選ぶようになります。

このように imget や imput は、--config オプションで指定された文字列をもとに、有効な case 文を選択します。上の例から明らかですが、この機能を使うと読み込むメールボックスや送信時の From: を変更できて便利です。

Mew は起動時に Config の case 文を調べます。もし、1 種類以上の case がある場合、mew-config-list に設定します。--config が指定されない場合に読まれる部分は、default という文字列で表現されます。上の例では、 mew-config-list には、'("default" "wide" "iijlab") が設定されます。

Summary モードで C を押すと、mew-config-list を補完の候補として利用しながら、imget に渡す --config の値を選択できます。デフォルトでは "default" です。もし他の値が設定されていた場合、たとえば "wide" が設定されていた場合、i は次のように表示します。

     Getting +inbox (wide)...

imput に case の選択を指示するには、--config オプション以外に、送信するメッセージのヘッダ中の Config: フィールドで指定できます。Draft モードでは、see header で説明したように、Config: というフィールド名を TAB で補完できます。また、mew-config-list の値を TAB で補完可能です。さらに、C-cTAB を使えば、 mew-config-list の値を循環的に補完できます。

しかし、自分で値を選ぶのはめんどうです。Mew は整頓先のフォルダを推測するのだから、Config: の値も推測して欲しいと思うでしょう。もちろん、Mew は Config: の値を推測できます。Config: の推測ルールは、 mew-config-guess-alist に設定できます。書式は、see by-alist で説明した mew-refile-guess-alist と同じです。

1 つ例を挙げてみましょう。

     (setq mew-config-guess-alist
        '(("To:"
           ("wide.ad.jp" . "wide")
           ("mew.org" . "mew"))))

この場合、To: が wide.ad.jp に合致すれば "Config: wide" を、mew.org にマッチすれば "Config: mew" を挿入します。

この推測を利用して Config: を挿入できるタイミングは以下の 3 つです。

 1. mew-config-insert-when-prepared が t なら、草稿を用意した時点。

 2. mew-config-insert-when-composed が t なら、 C-cC-m でメッセージを作成した時点。

 3. C-cC-o と入力した任意の時点。

参考までに書きますが、ホスト名で Config を変更したい場合は、以下の行を ".emacs" に入れるとよいでしょう。

     (setq mew-config-guess-alist
        (list (cons nil (system-name))))

Mew の起動を速くする
============

長い間使うと Mew の起動が次第に遅くなる理由は、フォルダ数が増えているからです。Mew は、起動時にフォルダ名の一覧を集めていることを思い出して下さい。

Mew の起動を速くするには、cron で impath を叩き "~/Mail/.folders" に結果を入れておきます。

     impath --list + > ~/Mail/.folders

また、以下の行を "~/.emacs" に入れて下さい。

     (setq mew-use-folders-file-p t)

mew-use-folders-file-p が t の場合、Mew は起動時に "~/Mail/.folders" を読み込みます。また、mew-use-folders-file-p が t の場合、C-uZ はフォルダを調べたあと結果を "~/Mail/.folders" に保存します。

アイコンのある生活
*********

コンパイルの仕方にもよりますが Text Emacs のメニューってかっこ悪くて使う気になりません。しかし、XEmacs はメニューがおしゃれなのに加えて、さまざまな機能を持ったアイコンをツールバーに表示できます。

XEmacs で Mew を使えば、アイコン・ベースのインターフェイスでメッセージを読み書きできます。アイコン・ベースのインターフェイスは、従来のキー入力によるインターフェイスと親和性が高いように設計されています。

アイコン・インターフェイスの使い方は.....、説明するまでもありません。直感的にわかるはずです。でも少しだけ手ほどきを。

Summary、Virtual、および、Draft モードの標準のアイコンに束縛されている機能を利用するには、左ボタンをクリックして下さい。

マルチパートのメッセージを読み書きする際に表示されるアイコンは、左ボタンのクリックでそのバーを表示し、右ボタンを押すとポップアップ・メニューが表示されます。このメニューのおかげで、パートに対しさまざまな処理が可能となっています。

マルチパートのアイコンは、デフォルトで標準のアイコンの右に表示されます。左に表示するのが好きな人は、以下のように設定して下さい。

     (setq mew-multipart-icon-position 'left)

XEmacs の導入になかなか踏み切れない人は、以下の URL を参照し、XEmacs で動く Mew の雰囲気を味わってみるのもよいでしょう。

     http://www.Mew.org/

メッセージの作法
********

メッセージをやりとりする際には、最低限のマナーがあります。マナーを守っていないメッセージは読みにくいため、大変損します。簡潔かつ適切な文章を書き、なるべく相手に理解してもらえるよう努力しましょう。

メッセージを書く際に気を付けるべき項目を以下に示します。

To: と Cc: を正しく書く
     To: が目的の人で、Cc: は参考までに送り付ける人です。自分のアドレスが Cc: の場合は、読み飛ばす人がいますから注意して下さい。また、不必要なアドレスを To: や Cc: に書いて、相手に迷惑をかけないようにしましょう。

Subject: には本文の内容を的確に短く書く
     Subject: を見て読むか決める人がいますから、不適切な Subject: だと読んでもらえないかもしれません。長い Subject: は読みにくいので止めましょう。

改行は行末を、空行は改段落を表す。1行は半角70文字程度にとどめる
     意味もなく1行おきに書いたり、なん行にも渡って改行しないのは読みづらいです。とくに行が長いと引用するのに困ります。また、行頭にいくつかの空白文字を入れて右によせて書く人がいますが、これも無意味です。テキストの表示は、使っているコンピュータでまちまちですから、結局自分のコンピュータでみためがよくても、他人のコンピュータでそうであるとは限らないのです。

必要な部分だけを引用する
     面倒でも不要な部分は削りましょう。Mew を使っていれば、引用は楽勝のはずです。

シグニチャは簡素にする
     長いシグニチャは単なる自己満足です。

いたずらメッセージを送らない
     こんなことは注意したくありませんが、それでも不幸のメッセージなどを送ってくる人がいます。人格を疑われることを理解すべきです。

また、インターネットのマナーは RFC1855 を読むといいでしょう。See Bib を参照して下さい。著者は、正確な文章の書き方について学生のためにまとめた入門書を WWW で公開しています。興味があれば、以下の URL にアクセスして下さい。

     http://www.mew.org/~kazu/japanese.html

MIME ってなぁに？
***********

今までのメッセージ、正確には RFC822 メッセージは、本文にテキストしか格納できない規格でした。MIME は RFC822 を拡張した多目的メッセージです。

MIME は、ヘッダに

     MIME-Version: 1.0

というフィールドを持ちます。このフィールドがない場合は、RFC822 メッセージです。MIME では、データの型を示す Content-Type: と符号化方式を示す Content-Transfer-Encoding: が重要なフィールドです。以下ではこれらのフィールドや MIME の特長について説明します。

データの型指定
=======

MIME では、Content-Type:(以下 CT:)というフィールドにデータの型を指定できます。以下は、本文が US-ASCII である MIME の例です。

     MIME-Version: 1.0
     Content-Type: Text/Plain; charset=us-ascii
     Content-Transfer-Encoding: 7bit
     Subject: hello
     From: Kazu

     Hi all,

CT: が省略された場合は、Text/Plain; charset=us-ascii として取り扱われます。また、CT: Text/Plain のときに、charset が省略されると US-ASCII と解釈されます。

このように MIME では、CT: がテキストの場合は、charset で文字コードを指定できます。日本語には ISO 2022 JP を使います。

MIME では、本文に複数のデータを格納できます。これをマルチパートといいます。マルチパートのそれぞれのパートは、コンテントヘッダとコンテントボディから構成されています。CT: はヘッダだけでなく、コンテントヘッダ中にも現れます。逆に、ヘッダは特殊なコンテントヘッダだと考えても構いません。

詳しくは、see mime-multi を参照して下さい。

以下に重要な CT: を示します。

Text/Plain
     テキスト

Message/Rfc822
     MIME を含むメッセージ。ヘッダと本文という構造がある。

Multipart/Mixed
     マルチパート

Application/Postscript
     PostScript

Application/Octet-Stream
     バイトストリーム。バイナリファイルと思ってよい。

Image/Gif
     GIF

Image/Jpeg
     JPEG

Audio/Basic
     AU 形式の音声ファイル

Video/Mpeg
     MPEG

Message/External-Body
     メッセージの外部に実体がある

安全な符号化
======

以前からバイナリを配送するために uuencode という符号化プログラムが使われていました。uuencode は、8ビット3文字を6ビット4文字に変換しますが、変換後にたくさんの記号が現れます。これらの記号はメッセージのヘッダで特殊な意味を持つものが含まれており、ヘッダの拡張のためには利用できません。

また、空白文字も使われているのも厄介です。なぜなら、BITNET のファイルシステムには、行末に空白がありえないのです。もし、uuencode で符号化したときに、行末にたまたま空白が現れたとしましょう。これを BITNET のメッセージゲートウェイが受け取ると、当然行末の空白を削ってしまいます。よって、受信者は元のバイナリファイルを復元できません。

そこで、MIME では本文用に 2 つの符号化方式を定めました。

Base64 符号化方式
     "0-9A-Za-z/+" の64文字を用いて、8ビット3文字を6ビット4文字に変換する。もともとは PEM で考え出された。

Quoted-Printable 符号化方式
     表示不可能な文字を "=" に続けて16進表記する。

各コンテントヘッダ中の Content-Transfer-Encoding:(CTE:)で符号化方式を指定します。取り得る値は以下の通りです。

7bit
     無変換。7ビットの行から構成される。

8bit
     無変換。8ビットの行から構成される。

binary
     無変換。8ビットのデータ・ストリーム。

base64
     Base64 で符号化した。7ビットの行から構成される。

quoted-printable
     Quoted-Printable で符号化した。7ビットの行から構成される。

CTE: が省略された場合は 7bit として扱われます。

ISO 2022 JP は7ビットの文字コードですから、CTE: は 7bit です。つまり、 CTE: は省略して構いません。もちろん、base64 や quoted-printable で符号化しても構いませんが、フォルダにあるメッセージを more などで直接読めなくなるので、お勧めではありません。

マルチパート
======

CT: が Multipart である場合、そのコンテントボディには複数のデータが格納されることを意味します。データの境界は boundary に指定された文字列で区切られます。以下に例を示します。

     Message-Id: <13060.789566615@mew.org>
     From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=
             <kazu@mew.org>
     Subject: =?ISO-2022-JP?B?GyRCPC8kTjMoGyhC?=
     To: m-sakura@ccs.mt.nec.co.jp
     Mime-Version: 1.0
     Content-Type: Multipart/Mixed; boundary=simple
     Content-Transfer-Encoding: 7bit

     --simple
     Content-Type: Text/Plain; charset=iso-2022-jp
     Content-Transfer-Encoding: 7bit

     奈良名物「鹿」の絵を送ります。

     --かず

     --simple
     Content-Type: Image/Gif
     Content-Transfer-Encoding: base64
     Content-Description: "Deer on the Nara park"

     R0lGODdhFwG8ANUAABETDCoYDC8lFi4dJxcnKTMwLkUUC04uG2opEkgeJ04yMWg4Ly1FLVJG
     NWdSMywyTks1Tmc3RjdRVjNcalRMUG9UU1xbY051eG9pcIcxEp5bM8d1NI1VSJhrVrRwUpR0
     cKZ1dcN9WXuHOWmHc7WJN6yLbcyEWNCZdDZjjml0i5t7im+TmGeRonWly5aLlrCLlK+arJmn
     pbettMabktWumM+zsrnCrtTLua21ycq6x6/J3NbQ1+bk29na5dzp8+7w8ywAAAAAFwG8AAAG
     /8CLcPhYtVgNyirWasZYEgDhIWGxRiXWcTIATHS/Hs6K2+1wt59azYtdJnBhKrVaWYcp7==

     --simple--

この例では、"simple" という文字列で区切られています。boundary に指定された文字列には、先頭に "--" が付きます。最後の区切りには、後ろにも "--" が付きます。

各パートは、コンテントヘッダとコンテントボディから構成されます。両者は、ヘッダと本文のように空行で区切られます。逆にいうと、ヘッダと本文は、それぞれ特殊なコンテントヘッダとコンテントボディです。

テキスト以外を MIME で送信する場合は、必ずマルチパートを利用するようにしましょう。たとえば、本文にいきなり Audio/Basic を格納できますが、そんなメッセージを受け取ったらびっくりします。パート1に説明のテキスト、パート2 に Audio/Basic を入れた方が親切でしょう。

マルチパートは、入れ子構造にできます。つまり、マルチパートのマルチパートなども作成できます。

ちなみに境界ですが、前後の改行まで含みます。上記の例では、 "CRLF--simpleCRLF" が区切りです。

ヘッダの拡張
======

ヘッダはメッセージの配送に関わる情報を格納しているため、配送プログラムが誤動作するような文字列を入れるべきではありません。MIME では、ヘッダに以下のような形式で非 ASCII を安全な文字列に符号化し挿入します。

     =?<charset>?<encoding>?<encoded-string>?=

指定できる <charset> は CT: Text/Plain の charset と同じです。<encoding> には、B と Q 符号化方式があり、前者は Base64 符号化方式、後者は Quoted-Printable 符号化方式の亜種を意味します。

ISO 2022 JP には、B 符号化方式が奨励されていますが、Q 符号化方式でも構いません。しかし、Q 符号化方式に対応しているインターフェイスはあまりないようです(もちろん Mew は対応していますが)。

たとえば、「山本和彦」をこの形式で符号化すると以下のようになります。

     =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=

嗚呼漢字コード
*******

ここでは、非 ASCII 文字をメッセージで使うために人々が奮闘してきた歴史を漢字を例に取って振り返ります。

電子メールと地域化
=========

1982年、互換性を保証するために、電子メールの規格 RFC822 が記述されました。電子メールはアメリカ育ちであったため、残念ながら本文やヘッダには、ASCII 文字列しか格納できない規格でした。

しかし、英語以外の言語を母国語としている人達にはとても不便です。そこで、配送に関わるヘッダはともかく、本文に母国語を格納するため RFC822 はさまざまな国で拡張されました。

ヨーロッパ諸国では、ウムラウト(アクセント)文字を表す8ビット1文字のコード Latin 1 がよく使われるようになりました。Latin 1 は ISO 8859 1 と呼ばれることがあります。

日本では、7ビット2文字の JIS コード、UNIX でよく使われる 8ビット2文字の EUC コード、パソコンで使われている 8ビット2文字の SJIS コードが存在しました。日本のインターネットの前身である JUNET の先駆者達は、配送のためのコードとして JIS コードを ESC シーケンスで切り替える、いわゆる JUNET コードを選びました。

JUNET コードは ISO 2022 JP と呼ばれることがあります。ISO 2022 JP を使えば、複数の文字コードを切り替えるだけでなく、使われている文字コードが何かという情報を得られます。

Latin 1 や ISO 2022 JP に見られる本文の拡張は、あくまで地域に限定された紳士協定です。RFC822 を使う限り、地域間を越えてメッセージをやりとりするには、結局英語を使うしかないのです。

RFC822 は記述が曖昧なので、ヘッダや本文に 7 ビット文字である ISO 2022 JP を入れてもよいように読めます。たぶん、この説明を読めば誤解が解けるでしょう。「RFC822 は、ヘッダと本文のシンタックス(構文)を7ビット、それらのセマンティックス(意味)を US-ASCII と定めています。ISO 2022 JP のシンタックスは RFC822 に従っていますが、セマンティックスは RFC822 に違反しています。」

MIME の登場
========

絵や音声などを配送したい、地域化された RFC 822 の架け橋となる規格が欲しいなどの要望を満たすために、1992年に MIME が規定されました。MIME では、テキストの文字コードを charset というパラメータに指定できます。たとえば、 ISO 2022 JP は以下のように指定します。

     Content-Type: Text/Plain; charset=iso-2022-jp
     Content-Transfer-Encoding: 7bit

     日本語のテキスト

この charset は役に立つのでしょうか？ もちろんです。charset は、インターフェイスに正しくテキストの文字コードを伝える役割を果たします。ノルウェーの人が ISO 8859 1 で日本にメッセージを送ってきたとしましょう。ISO 8859 1 に対応しているインターフェイスなら、対応するフォントで表示すればいいし、対応していないなら無視すればいいのです。Mew では、Mule の内部コードに変換する関数の引数に charset を利用しています。

「ISO 2022 JP の上位互換規格であり、さまざまな文字コードを格納できる ISO 2022 JP2 などを使えば charset など要らない。なぜなら ISO 2022 JP2 自体に文字コードの情報が含まれているから」という人がいます。しかし、これらの人は MIME を理解できているとは思えません。

確かに理想的にいえば、この主張は正しいのです。しかし、MIME は現実主義です。MIME はユーザが明日から ISO 2022 JP2 を使うようになるという大胆な仮定はしていません。また、世の中に存在する脆弱な配送プログラムでも安定して動くように考慮されています。世の中は、そんなにお行儀のよいプログラムばかりではないし、たくさんの資源を使えるほど豊かでもないのです。「明日から UNICODE を使え」と言われたらいやでしょう？

MIME は、さまざまに地域化されたメッセージの架け橋として charset を用意しました。MIME で増えた作業は、charset の挿入だけであり、今まで通り我々は ISO 2022 JP を使えます。ISO 2022 JP2 を標準にしたいなら、ISO 2022 JP2 をデフォルトで使う地域を広げていけばよいのです。この意味で、ISO 2022 JP2 と MIME は相反してはなく、逆に、ISO 2022 JP2 の普及のために MIME を利用できると言えます。もちろん文字コードの符号化方式である ISO 2022 xx に charset という単語が相応しくないのは、MIME の開発者も認めているところです。

MIME を使えば、非 ASCII 文字を ASCII 文字列に符号化し、ヘッダに挿入できます。このような枠組で、電子メールの配送プログラムの誤動作を防止し、また、ヘッダに英語以外の言語を書くことを実現しているのです。もう、Subject: に「日本語を書いてはいけません」なんて言わなくてよくなりました。:)

MIME は地域化された RFC 822 を禁止する規格ではありません。よって、MIME のインターフェイスは、以下のような動作が望まれています。

読むとき

 1. ユーザがデフォルトの charset を選べるようにしておく。

 2. MIME-Version: がないメッセージの場合は、本文をデフォルトの charset として扱う。

 3. MIME-Version: があり、Content-Type: がない場合は、US-ASCII として扱う。

 4. MIME-Version: と Content-Type: がある場合は、Content-Type: に指示された charset を利用する。

書くとき

 1. MIME-Version: と Content-Type: Text/Plain の charset を必ず付ける。

 2. charset には、最小限の文字集合を選ぶようにする。たとえば、英語だけなら US-ASCII を選ぶようにする。すると、US-ASCII だけなのに、ISO 2022 JPと書いてあるため kterm が呼び出されるといった事態がなくなる。

スプールやフォルダに ISO 2022 JP を EUC Japan に変更して格納する場合は、無条件に変換してはいけません。きちんと charset を確かめ、ISO 2022 JP だけを EUC Japan に変換するようにして下さい。

ヘッダに非 ASCII 文字を挿入する機能は MIME の一機能ですが、実際には、 MIME-Version: フィールドは必要ありません。

正規化の概念
======

残念ながら、世の中のコンピュータは、データをさまざまな方法で表現します。以下によく利用されている OS とその行末を示します。

  - UNIX   :: LF(0x0a)

  - MS-DOS :: CRLF(0x0d0a)

  - MacOS  :: CR(0x0d)

よって、行末に関して取り決めがないと、これらの OS 間では安全にテキストが交換できません。RFC822 では、メッセージの再送の際に行末を CRLF に変換することになっています。このように、共通の書式への変換を「正規化」といいます。SJIS や EUC Japan を ISO 2022 JP に直すのも正規化の一種です。

さて、PGP の暗号化や署名ついて考えてみましょう。たとえば、Mac のユーザが行末が CR である文章に署名し UNIX ユーザに送ったとします。UNIX ユーザが行末を LF に変換し署名を確認したとしたら、検証が失敗するのは明らかでしょう。そこで、PGP への入力はあらかじめ正規化されている必要があるのがお分かりになると思います。

PGP で暗号化したり署名したりする場合は、まずテキストを ISO 2022 JP に変換し、行末を CRLF に直して下さい。

Mew のこだわり
*********

Mew の精神を一言で表すと、

     Mew wants something simple or nothing at all.

となります。つまり、複雑な機能は要らないのです。単純で吟味された機能しか提供しません。

たくさんの方が「昔使っていたメーラにはこんな機能があって便利だから、Mew にも付け加えて欲しい」といいます。しかし、こんな説明では著者を説得するのは難しいでしょう。なぜなら、Mew は他のプログラムが今までやっていないことを実現しようとしているからです。「昔はこうだった」という理由はあまりにも力不足です。

たとえば、返答や転送したメッセージに、R マークや F マークを付けて欲しいという人がいます。しかし、たくさん議論をした結果、サポートしないことに決めました。なぜなら、返答したメッセージにだけ確実に R マークを付けるのは困難だからです。もし、a で返答しようと思い、Draft モードで C-cC-q でやっぱり止めたらどうでしょう？ a を押した時点で、R マークを付けるのであれば、誤ってマークが付くことになります。不完全な機能を提供するよりも、もっと進んだマルチパートエディタを作ろうと思っています(詳しくは、see todo を参照して下さい)。

もし自分の意見が正しいと思うのでしたら、根気強く著者を説得して下さい。著者は忙しいので昔説明されたことはすぐ忘れてしまいますし、人間ですから思い込みや偏見があります。素晴らしいアイディアを理解できないことが多分にあるでしょう。どうか、くじけないで下さい。

「Mew は mh-e に似ている」とか「Mew は mh-e の改良バージョン」などとは言わないで下さい。見ためは似ているかもしれませんが、Mew は mh-e とは全く異なった概念で実装されているのですから。

Mew の来た道
********

役には立ちませんが、Mew の歴史をひもといてみましょう。

もう mh-e はたくさんだ
==============

1993年の秋に WIDE Project の FJPEM の実験に参加しました。そのころ、櫻井さんが FJPEM を mh-e で利用しやすくするため、mhpem を作りました。mhpem に触発され、1994年の冬は修論の逃避行動を兼ねて mhpem の改良に励みました。

mhpem は暗号メッセージを自動的に復号化するおしゃれなプログラムでしたが、いくつか問題がありました。大きな問題は、mh-e が簡単に拡張できない柔軟性に欠けたプログラムだったことです。復号化したメッセージは、次に読むときは速くなるよう保存したいと思いますが、mh-e を改良するのは難しいのです。 mh-e がバージョンアップし、mhpem が新しい mh-e で動かなかったとき、著者は切れました。

復号化した PEM を保存したい。MIME も保存したい。どうして、簡単に MIME を取り扱えるインターフェイスがないのか。なぜ、複数のメッセージから簡単に引用できないのか。マークを駆使して面白いことができないなんて。メッセージの整理が大変なのはいやだ。もう、mh-e はたくさんだったのです。

mhpem の自動復号機能、mhasync の非同期な scan 機能、ウインドウの大きさを動的に変更できる GNUS の機能、マークを付けて複数のニュースを取り扱える gnus-mark の機能、VM のような整頓機能、メッセージのキャッシュ、美しく柔軟性のあるプログラミングスタイル.... さまざま断片が著者の中で1つにまとまり始めました。1994年3月、奈良への引越し前のことでした。

Mew の誕生
=======

1994年4月、本格的に Mew の製作に取り掛かりました。一覧表示の終了を待たなくてよい機能、動的なウインドウ設定、マーク、メッセージのキャッシュなどは、お手本があったので早くから実装されていました。

はじめの頃は MIME を MIME モードで表示していました。マルチパートのメッセージで SPC を押すと、Summary モードから MIME モードに移動していたのです。しかし、歌代さんは言いました、「なぜ MIME モードかあるの？ Summary だけで十分ではないか」。目から鱗の落ちる思いでした。

このころの大きな障害は、メッセージの整頓方法と MIME の作成方法でした。

確かに VM のように、ユーザにいちいち Lisp を書かせれば、整頓は簡単になります。しかし、ユーザにこまめに設定させること自体が嫌だったのです。「メッセージのヘッダから無限の可能性のある整頓先を模索するのは馬鹿だ。限りのある実際のフォルダの中から候補を選べばいい」。このアイディアを思いついたときは、次の朝が来るのが待ち遠しかったものです。整頓機能は、後に乃村さんによって強化されました。

複雑な MIME を簡単に作成するにはどうすればよいか？ ユーザには作成文法とか MIME の書式などの理解を押しつけるのはあんまりだ。一言説明すれば、だれでも直感的に MIME を作れるようにしたい。この答えをくれたのは門林さんです。「MIME の構造ってファイルシステムに似ているよね」。そうです、シングルパートをファイル、マルチパートをディレクトリと考えればよいのです。ファイル操作はだれにでもできるし、ファイル構造を MIME に変換する仕事は Mew が請け負います。

PGP との出会い
=========

FJPEM の実装に疑問を感じていた著者は、1994年の初夏 PGP と出会いました。そのころは PGP 2.5、つまり、MIT が RSAREF を使って、RSA の特許に抵触しない非商用の PGP を模索していた時期です。PGP 2.6 のリリースによって、Phil と RSADSI は和解しましたが、RSAREF を使っている 2.6 は米国国外への持ち出しが禁止されています。

しかし、2.3a を基にした 2.6ui の存在を知り、PGP ユーザになりました。PGP を始めて使ったときの感動は忘れられません。本当に計算し尽くされたプログラムです。1995年の冬、サンディエゴで開かれた通称 ISOC Security Symposium(NDSS)という国際会議に参加しました。このとき、プロシーディングと共に O'Reilly から発売されてすぐの Simson の PGP という本をもらいました。久々に読みふけった傑作中の傑作です。このような理由から、PEM と MIME の統合よりも、PGP と MIME の統合に力を注ぐようになりました。PGP/MIME は現在実験段階であり、標準化にはまだ時間がかかります。

「暗号化とか署名はマークで表せばいい」というアイディアは、櫻井さんと情報処理全国大会の論文を書いたときに教えてもらいました。マークならいつでも好きなときにキャンセルできるという利点を理解するのは少し時間がかかりましたけど。

MH からの独立
========

「うまい寿司を食わせてやるからみんな福岡に集合だ」のかけ声のもと、1997年 4月にそうそうたるプログラマが福岡ドームのある百道に結集しました。九州システム情報技術研究所にハック部屋を借り、近くのハイヤット・リージェンシーを寝床にして、3泊4日に及ぶ MH からの独立作戦が開始されました。

とにかく食べる、気に入るまでハックする、とことんまで議論するという作業をなんども繰り返し、福岡を後にするころにはほぼ Mew が MH から独立し、IM を使うようになっていました。(この週のエンゲル係数が高かったのは言うまでもありません。)

その後もメーリングリストで議論を戦わせ、合意を取り、またハックするという作業を繰り返し、最後に歌代先生が高速化の魔法を唱えて、ようやく7月頭にベータリリースにこぎつけました。

ニュースの統合
=======

1994年秋の WIDE 合宿で Mew の BOF(Birds Of a Feather::井戸端会議)をしました。この BOF で佐野さんは「電子メールとニュースの中間がメーリングリストだよね」という忘れられない言葉を残しました。闇の中で手探り状態だったところに、一筋の光を見た思いです。Perl 5 が安定してきた現在、ニュースの統合は間近に迫っています。

Mew の行く道
********

ここでは 2.xx 以降で実装する予定の機能や概念について説明します。

インターネットメッセージ
============

ここでは、電子メール、メーリングリスト、ニュースを統合するインターネットメッセージの概念について説明します。

電子メール、メーリングリスト、ニュースを配送範囲と通信相手の観点から分類すると以下のようになります。配送範囲とは実際にメッセージが配送される人の範囲を示し、通信相手は通信相手が特定できるかを意味します。

               電子メール  メーリングリスト  ニュース
     配送範囲   狭い            中間           広い
     通信相手   特定        特定／不特定      不特定

このように、電子メール、メーリングリスト、および、ニュースは段階的な関係にあるので、メッセージという概念で一括りにしても問題ありません。

電子メールやメーリングリストでは、配送先を To: や Cc: で指定します。電子メールの To: とメーリングリストの To: を区別しないのですから、ニュースの配送先を示すフィールド Newsgroups: を To: や Cc: と同一視しても構わないはずです。

よって、インターフェイスが賢ければ、以下のように To:、Cc:、Newsgroups: を同時に書いても問題ありません。

     To: person@foo.ac.jp
     Cc: ml@bar.com
     Newsgroups: comp.baz
     Subject: test
     From: kazu@xxx.ac.jp

     The body.

このような記述が許されると、今まで繁雑だった電子メール、メーリングリスト、および、ニュースへの操作は、メッセージの送信、返答、転送というたった3つの操作で網羅できます。

送信
==

メッセージには、To:、Cc:、Newsgroups: を同時に書けます。もちろん、省略しても構いません。

     To: person@foo.ac.jp
     Cc: ml@bar.com
     Newsgroups: comp.baz
     Subject: test
     From: kazu@xxx.ac.jp

     The body.

メッセージのインターフェイスは、To: や Cc: があれば SMTP を喋り、 Newsgroups: があれば NNTP を喋ってメッセージを配送します。

返答
==

返答のコマンドを入力すると以下のような草稿が用意されます。

     To: kazu@xxx.ac.jp
     Cc: person@foo.ac.jp, ml@bar.com
     Newsgroups: comp.baz
     Subject: Re: test
     From: person@foo.ac.jp

     The body.

From: が To: へ、To: や Cc: が Cc: へ、Newsgroups: が Newsgroups: へ用意されます。もし、自分が希望する配送範囲を越えているなら、適宜削って下さい。ここが肝心なところです。Mew は、「可能性のある配送範囲を列挙し、不要ならユーザが削る」という単純なルールしかありません。

「電子メールで回答したい」とか「ニュースにだけに返答したい」という希望はよく分かります。でもさまざまなパターンがある中でだれもが納得するルールを決めるのは困難ですし、また、規則が繁雑になれば理解できなくなります。ですから、基本的に上記のポリシーは変更しません。

電子メールとニュースを統合し、経験を積んだ際には、「電子メールでの回答」といったコマンドを提供するかも知れません。しかし、それはあくまで「近道」なのです。

転送
==

転送のコマンドを入力すると、To:、Cc:、そして、Newsgroups: を訊かれます。よって、どのサービス間でも簡単に転送できるようになります。転送には MIME 形式を使います。

     To: guy@foo.ac.jp
     Cc: ml@bar.com
     Newsgroups: comp.hack
     Subject: Forward: test
     From: Alice
     MIME-Version: 1.0
     Content-Type: Multipart/Mixed; boundary=boundary
     Content-Transfer-Encoding: 7bit

     --boundary
     Content-Type: Text/Plain; charset=iso-2022-jp
     Content-Transfer-Encoding: 7bit

     こんなメッセージが届きました。

     // Alice

     --boundary
     Content-Type: Message/Rfc822
     Content-Transfer-Encoding: 7bit

     To: person@foo.ac.jp
     Cc: ml@bar.com
     Newsgroups: comp.baz
     Subject: test
     From: kazu@xxx.ac.jp

     本文

     --boundary--

作りたくてうずうずしていること
===============

マルチパートエディタを作る

  * 不適切なヘッダを書き換えられる。たとえば Subject: を適切に書き換えたり、返答したことを記録したりできる。

  * マルチパートを編集できる。

  * 暗号メッセージを第3者に転送できる。

入手方法とメーリングリスト
*************

ここでは、Mew の入手方法とメーリングリストについて触れます。

Mew の入手方法
=========

Mewの最新バージョンは以下から入手できます。

     ftp://ftp.Mew.org/pub/Mew/mew-current.tar.gz

ときどきサンプルメッセージが以下のように提供されます。

     ftp://ftp.Mew.org/pub/Mew/samples.tar.gz

メーリングリスト
========

新しいバージョンは、

     mew-release@Mew.org

で英語でアナウンスしています。入りたい人は

     mew-release-ctl@Mew.org

宛に本文に "#help" と書いて電子メールを送って下さい。mew-release には著者以外が投稿できないように制限が加えられています。

Mew の質問や議論などは、

     mew-dist@Mew.org

に日本語で投稿できます。mew-dist へ入りたい人は

     mew-dist-ctl@Mew.org

宛に本文に "#help" と書いて電子メールを送って下さい。mew-dist は mew-release に含まれているので、mew-dist に登録すれば、自動的に mew-release 宛の電子メールを受け取るようになります。

Mew の質問はできるだけ mew-dist へお願いします。著者には受け取った全ての質問に答えている時間はありません。mew-dist へ質問すると、他の人が答えてくれることを期待できます。

謝辞
**

まずはじめに、櫻井三子さんにお礼を述べたいと思います。彼女が mhpem を作り触発してくれなかったら Mew を作ることはなかったからです。(もうなくなってしまいましたが) mew-url や mew-pem の多くの部分を書いています。また、複雑なメッセージの作成にマークを使うというヒントも与えてくれました。

Summary モードをもっと簡素にと助言して頂いた歌代和正さん、MIME とファイル構造って似てるよねと言ってくれた門林雄基さん、いつも電子メールに関して貴重な助言をしてくれる中村素典さん、電子メールとニュースを統合するきっかけを与えてくれた佐野晋さんに心から感謝します。

いつも素晴らしいコードを提供しくれる酒井清隆さん、メッセージの整頓機能を賢くしてくれた乃村能成さん、こまめに英語を直してくれる牛島幹友さん、info を書く気にさせてくれた島慶一さん、ありがとうございます。

I would like to thank David Worenklein for contributing many codes. I'm grateful to Atsushi Shionozaki, Darren Stalder, and David Worenklein for proofreading my paper. I'd like to acknowledge to Scandinavia guys for their good suggestions.

IM の作成に協力してくれた伊藤純一郎さん、笠原義晃さん、中村素典さん、乃村能成さん、西和則さん、太田英憲さん、IM を高速にしてくれた歌代和正さんに感謝します。Mew を OS/2 で動かす努力とたくさんのテストをしてくれる奥西藤和さんにお礼を申し上げます。Mew が Win95/WNT で動くようになったのは、主に北口修一さんと山口修平さんの努力によるところが大きいです。Mew が XEmacs で楽しいのは、寺西裕一さんのおかげです。

Mew はたくさんの人の貢献の上に成り立っています。ここに名前を挙げていない方にも心から感謝しています。著者はなにぶん多忙ですので、全ての電子メールに答える時間が取れません。返事が帰って来なかった人は、本当にすみませんでした。

著作権について
*******

Mew は以下の著作権に従います。

Copyright (C) 1994, 1995, 1996, 1997, 1998 Mew developing team.

All rights reserved.

変更の有無にかかわらず、ソースおよびバイナリ形式の再配布および利用は、以下の条件を満たしていれば、これを許可する。

 1. ソース・コードの再配布は、上記の著作権表示、この条件項目、および、以下の免責事項を保存しなければならない。

 2. バイナリ形式の再配布は、上記の著作権表示、この条件項目、および、以下の免責事項を、その配布に付随する説明書、あるいはその他の資料のいずれかに明記しなければならない。

 3. このソフトウェアの特徴や利用方法について述べている全ての広告資料に、以下の文章が掲載されなければならない。「この製品は、Mew 開発チームとその貢献者達によって開発されたソフトウェアを含んでいる。」

 4. 前もって特別に許諾を得ない限り、このソフトウェアから派生した製品の推奨や販売促進のために、このチーム名と貢献者達の名前を利用してはならない。

このソフトウェアは「このままの形で」提供され、明示的あるいは言外の保証は、商用利用および特定目的への適合に対する言外の保証も含み、またこれらだけに限らず、存在しない。たとえ以下のような損害の可能性を示唆されていたとしても、どのような形にしろこのソフトウェアの利用から発生した問題において、このチームと貢献者達は、(代替製品やサービスの調達; 利用権、データ、あるいは利益の損失; あるいは営業の中断を含む、またこれらだけに限らず)直接的に、間接的に、偶然に、特別に、懲罰上、あるいは、必然的に生じてしまった損害に対し責任はなく、いかなる責任理論上でも契約の有無に係わらず厳密な責任はなく、また(過失あるいはその他を含む)不法行為に対しても責任はない。

CD ROM に入れて配布したいという方は、できるだけ教えて下さい。教えてくれなくても怒りませんが、教えて頂けるとありがたいです。配布を断ったことはありません。

この Info の著作権は、著者に属します。配布、利用共に自由ですが、無保証です。また、この Info から発生した被害に対し、著者は一切責任を負いません。

著者紹介
****

Kazuhiko YAMAMOTO // Kazu

山本和彦 // かず(くん)

1970年、南を虹の松原を湛える海岸、東をウグイが泳ぐ川、北と西をなだらかな山に囲まれる山口県光市に生まれる。中学生のときに映画「ウォーゲーム」を見てセキュリティに関心を持つ。自然と遊びながら、高校まで光市で過ごす。

1988年、九州大学工学部電気系入学のため福岡へ。都会の殺伐さ、汚れた海、言葉の違いに苦しみながらも卒業まで至る。3年生のときに初めて電子メールに触れ、4年生のころにインターネットに惹かれていく。Sun に入社渡米を試みるが、不幸にも米国のビザ発行ポリシーが厳しくなった時期と重なり、失敗。

1992年、九州大学大学院工学研究科情報工学専攻へ進学。本格的にインターネットの研究に従事。経路制御を専門とする。セキュリティの普及活動を開始。修士 2年の春に、書く書くと言ってなかなか書かなかった「ハッピーネットワーキング」をリリース。

1994年、奈良先端科学技術大学院大学に助手として就任。約4年の大学教官生活中に、Mew の開発に取り組む。「若いうちにプログラムを書こう、教育は歳をとってからもできるよね」という結論に至り、1998年 IIJ 技術研究所に新たな研究環境を求めた。

研究分野 :: メッセージ・システム、IP version 6

ひとこと :: 「うまく説明できないものは、本質的に優れていない」

ふたこと :: 「優しいものが優れている」

Email: Kazu@Mew.org

URL: http://www.mew.org/~kazu/

PGP fingerprint:  6B 63 38 88 67 5E 96 8E  CE A4 62 73 3F 11 64 94

用語集
***

Mew で使う単語をまとめます。

フォルダ
     受け取ったメッセージを保存するファイルやディレクトリ

Summary モード
     メッセージの一覧を表示するモード

Message モード
     テキストメッセージの内容を表示するモード

Draft モード
     メッセージを書いたり、作成したりするモード

MIME
     本文にテキスト以外のオブジェクトを格納したり、ヘッダに非 ASCII 文字を挿入したりできる規格です。MIME を使えば、本文にテキスト、絵、音声などを同時に取り込めますし、また、Subject: に日本語を書けます。Multipurpose Internet Mail Extensions の略称で、「多目的メール」と呼ぶことがあります。詳しくは、see MIME を参照して下さい。

PGP
     Phil Zimmermann 氏が作成した暗号メッセージや電子署名を実現するプログラムです。Pretty Good Privacy の略です。

ニュース
     ネットニュース、あるいは、USENET ニュースのこと。

メッセージ
     電子メールやニュース、あるいは、MIME などの総称。インターネットメッセージの省略語。

参考文献
****

ここでは、参考文献を紹介します。RFC(Request For Comments) は、インターネットで知識を共有するために書かれた文献です。たとえば、以下のサイトから入手できます。

     ftp://ftp.isi.edu/in-notes/

電子メールやニュースを使い始めたばかりで、仕組みがよく分からない人は、以下の文献を参考にして下さい。

  * 山本和彦, "ハッピーネットワーキング", ASCII 出版局, 1994.

インターネットでのマナーは、以下の RFC を読んで学んで下さい。

  * S. Hambridge, "Netiquette Guidelines", RFC 1855, 1995

昔のテキストメールの書式や配送の仕組みは以下の RFC を参照しましょう。

  * D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, 1982

  * J. Postel, "Simple Mail Transfer Protocol", RFC 821, 1982

MIME については、以下の RFC を読んで下さい。

  * N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 1996.

  * N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types" RFC 2046, 1996.

  * K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 1996.

  * N. Freed, J. Klensin and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 1996.

  * N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, 1996.

ニュースの書式と配送プロトコルは、以下の RFC で定義されています。

  * M. Horton and R. Adams, "Standard for interchange of USENET messages", RFC 1036, 1987.

  * B. Kantor and P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, 1986.

PGP を学ぶなら、以下の書籍がいいでしょう。

  * PGP: Petty Good Privacy, Simson Garfinkel, O'Reilly & Associates, Inc, 1995. (訳書:: "PGP 暗号メールと電子署名", Simson Garfinkel 著, 山本和彦監訳, 株式会社オライリージャパン, 1996.)

PGP と MIME の統合については、以下を参照して下さい。

  * J. Galvin, S. Murphy, S. Crocker and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, 1995.

  * M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, 1996.

PGP/MIME に関する研究は、以下の論文にまとめられています。

  * Kazuhiko Yamamoto, "An Integration of PGP and MIME", in proceedings of Symposium on Network and Distributed System Security, pp 17 - 24, 1996.

Mew の実装は、以下の論文を参考にして下さい。

  * 山本和彦, "インターネット・メッセージの統合",情報処理学会論文誌, 第37巻, 第5号, pp. 809 - 821, 1996.