さて、2 人の人間が電子メールを使ってやりとりするときに
通常起こる情報の流れを説明しましょう。
Alice (彼女のマシンは wonderland.com) が
Bob (彼のマシンは dobbs.com)
にメールを送ろうとしているものとします。
どちらのマシンもインターネットに繋がっています。
インターネットのメールは 2 つの部分からできていることを知っておきましょう。 メールヘッダとメール本文です。 これらは空行で区切られます。 メールヘッダにはメールの差出人と宛先、ユーザが指定したサブジェクト行、 メールが送られた日付、その他にも必要な情報が含まれています。 メール本文はメッセージの実際の内容です。例を以下に示します:
From: "Alice" <alice@wonderland.com>
Message-Id: <199711131704.MAA18447@wonderland.com>
Subject: 私の白うさぎを見なかった?
To: bob@dobbs.org (Bob)
Date: Thu, 13 Nov 1997 12:04:05 -0500 (EST)
Content-Type: text
とっても心配なの。穴に落ちてしまったのかもしれないわ。
--
>>alice>>
インターネットメールのヘッダの配置と意味は、 RFC822 というインターネット標準で定義されています。
全体の処理を図示します。全ての処理と用語については後述します。
+---------+ +-------+
+-------+ 入力 | 送信側 | 呼出 |送信側 |
| Alice |--------->| MUA |--------->| MTA |::::>::::
+-------+ | | | | :: 送信側
+---------+ +-------+ :: の
:: マシン
.......................................................................
SMTP ::
::::::::::::::::::::::::::::<::::::::::::::::::::::::::::
::
:: +---------+ +-----+ +--------+
:: | 受信側 | 呼出 | | 配送 | Bob の |
::::>| MTA |--------->| LDA |===============>| メール | 受信側
| | | | |ボックス| の
+---------+ +-----+ +--------+ マシン
| |
| |
+----------------<-------------+ |
| |
+----------+ +-------+ |
| Bob の | |Bob の |<----------+
|通知ソフト| | MUA |
+----------+ +-------+
| |
| +-----+ |
+----->| Bob |<----+
+-----+
メールを送るために、 Alice は メールユーザエージェント (mail user agent, 略して MUA とも呼ばれます) と呼ばれるプログラムを呼び出します。 MUA はユーザが「メーラ」と考えているものです。 このプログラムはメッセージ作成の補助を行います。 普通はユーザが選んでおいたテキストエディタを呼び出すことになります。 MUA の「送信」ボタンを押すと、ユーザが処理する部分は終わりです。 有名な MUA についてはこの HOWTO の後の部分でざっと説明します。
Alice が使った MUA は、 Alice が書いたメッセージを即座に
メール配送エージェント (mail transport agent, または
MTA) と呼ばれるプログラムに渡します。
このプログラムは普通は sendmail でしょうが、
これ以外の MTA も一般的になりつつあるので、
将来は Linux ディストリビューションに入るかもしれません。
MTA についても、この HOWTO の後の部分でざっと説明します。
MTA の仕事は、メールを Bob のマシンの MTA に渡すことです。
Alice のマシンの MTA は To: ヘッダを解析し、
Bob のアドレスの右側にある dobbs.com を見て、
Bob のマシンを決定します。
Alice のマシンの MTA は、このアドレスを使って
Bob のマシンへのインターネット接続をオープンします。
この接続を確立する機構は、本文書とは全く関係がない話題です。
ここでは、この接続の目的:
Alice の MTA からテキスト形式のコマンドを Bob のマシンに送信すること、
そのコマンドに対する応答を受け取ること、
を理解していれば十分です。
MTA のコマンドはシェルには送られません。 MTA のコマンドは Alice のマシンのサービスポートに送られます。 サービスポートとは待ち合わせ場所のようなもので、 インターネットサービス用のプログラムが やってくるリクエストを監視しているポートです。 サービスポートには番号が振られており、 Bob のマシンにメールを渡すには 25 番ポートに話しかければ良いことを Alice のマシンは知っています。
Bob のマシンの 25 番ポートでは、コマンドを待っている MTA がいます (たぶん別の sendmail でしょう)。 Alice の MTA は Simple Mail Transfer Protocol (または SMTP) を使って Bob の MTA とやりとりを行います。 SMTP でどういったやりとりが行われるかを以下に示します。 Alice のマシンが送った行は S: で示し、 Bob のマシンからの応答は R: で示します:
S: MAIL FROM:<alice@wonderland.com>
R: 250 OK
S: RCPT TO:<bob@dobbs.com>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: From: "Alice" <alice@wonderland.com>
S: Message-Id: <199711131704.MAA18447@wonderland.com>
S: Subject: =?iso-2022-jp?B?GyRCO2QkTkdyJCYkNSQuJHI4KyRKJCskQyQ/GyhCPw==?=
S: To: bob@dobbs.org (Bob)
S: Date: Thu, 13 Nov 1997 12:04:05 -0500 (EST)
S: Content-Type: text
S:
S: とっても心配なの。穴に落ちてしまったのかもしれないわ。
S: --
S: >>alice>>
S: .
R: 250 OK
(訳注: Subject や本文で日本語を扱うにはそれなりの注意が必要に
なりますが、 MUA 側の問題なのでここでは割愛します :-)
通常 SMTP コマンドはテキスト行 1 行であり、応答も同じく 1 行です。 ただし DATA コマンドだけは例外です。 DATA コマンドの後には、 SMTP の受信側は ピリオド (".") が単独で現われる行まで メッセージ行を受け取り続けます。 (SMTP はインターネット標準 RFC821 で定義されています。)
これで Bob の MTA は Alice のメッセージを受け取りました。 Bob の MTA は、以下のようなヘッダをメッセージに付け加えます:
Received: (from alice@wonderland.com)
by mail.dobbs.com (8.8.5/8.8.5) id MAA18447
for alice; Thu, 13 Nov 1997 12:04:05 -0500
このヘッダは、メールがエラーを起こした時に追跡するために使います
(メッセージが複数のマシンに中継され、
このヘッダがたくさん付くこともあります)。
Bob の MTA は修正されたメッセージを
ローカル配送エージェント(local delivery agent,
あるいは略して LDA)に渡します。
Linux システムでは、普通 LDA は
procmail と呼ばれるプログラムですが、
LDA は他にもあります。
LDA の仕事は、このメッセージを Bob のメールボックスに追加することです。 LDA と MTA とは分離されていて、 双方のプログラムの仕事をより単純にしています。 これによって MTA は、 ユーザのメールボックスの場所などのローカルな細かい事情を気にすることなく、 インターネット関連の処理に専念できます。
Bob のメールボックスは、普通は /usr/spool/mail/bob や /var/mail/bob といったファイルです。 Bob がメールを読む時には、 自分の好きな MUA (mail user agent)を実行し、 このファイルを参照・編集します。
他にも電子メールに関係する重要なプログラムがあります。 ただし、それ自身はメールを読んだり配送したりはしません。 これはメールの到着通知プログラムというもので、 メールボックスを監視して、 新しいメールが来た時にユーザに知らせるプログラムです。
最初の通知プログラムは、 biff(1) と comsat(8) という、 対になる Unix 用プログラムでした。 biff プログラムは comsat サービスを有効にするフロントエンドです。 このサービスが有効になっていると、新しいメールが到着した時に そのヘッダが端末に出力されます。 この機能は、CRT 上で行指向のプログラムを使う人向けに設計されました。 そのため、今日の環境ではあまり使いでがありません。
ほとんどの Unix シェルにはメールチェック機能が付いており、 あまり邪魔にならない (新しいメールが来るとプロンプトの直前にメッセージを出力するなど) ような方法でメールの通知を行うことができます。 普通この機能は、環境変数を設定することによって有効にできます。 お使いのシェルのオンラインマニュアルで説明されているでしょう。 sh/ksh/bash 系のシェルを使っている方なら、 環境変数 MAIL と MAILPATH を調べてください。
X をサポートしているシステムには、定期的に新着メールを確認し、 メールの到着を絵と音の両方で知らせてくれる デスクトップ用の小物プログラムが付いてきます。 この類のプログラムで最も古く、かつ最も広く使われているのが xbiff です。 お使いの Linux ディストリビューションで最初から X のデスクトップが使える設定になっていれば、 たぶん xbiff もデスクトップ上にあるでしょう。 詳しくはオンラインマニュアルの xbiff(1) を見てください。
この文書を注意深く読んできた人は、あることに気付いたかもしれません。 ここで説明した情報の流れでは、 Alice のマシンはただちに Bob のマシンと会話できなければならないのです。 Bob のマシンが落ちていたらどうなるのでしょうか? あるいは Bob のマシンが起動していても、 インターネットに繋がっていなかったらどうなるのでしょうか?
Alice の MTA がすぐに Bob の MTA と通信できなければ、
Alice の MTA はメッセージを
wonderland.com のメールキューにしまっておきます。
Alice の MTA は期限切れになるまでは定期的に何度も再送を試み、
期限切れになった時点で、送信に失敗したことを知らせる
バウンスメッセージを Alice に送り返します。
もっともよく使われている MTA (sendmail)では、
再送の間隔は 15 分、送信の期限は 4 日です。
現在の多くの Linux ユーザは、ISP (Internet Service Provider, インターネット接続業者) 経由でインターネットに接続しており、 自分自身のドメインを持っていません。その代わり、こういったユーザは ISP のマシンにアカウントを持っています。 彼ら宛のメールは ISP のマシン上のメールボックスに配送されます。 しかしユーザは自分のマシンを使ってメールを読み書きしたいのが普通です (これらのマシンは、SLIP や PPP を使って 断続的に ISP に接続します)。 Linux ではこれを支援する リモートメールプロトコル が使えます。
これは前の節で説明したシナリオとは異なっています。 キューに入って再送を待っているメールは、 サーバのメールボックスに送られたメールとは違います。 キューに入っているメールはまだ配達されていないので、 期限切れになることがあります。 しかし ISP のサーバのメールボックスに配送されたメールは 「配達済み」なので、いつまででもそこに置いておくことができます。
リモートメールプロトコルを使うと、 クライアントはサーバ上にあるメールを ネットワーク接続経由で引き出すことができます (これは通常の配送の逆です。普通の配送では送信側の MTA が受信側の MTA にメールを送り付けます)。 一般的に使われているリモートメールプロトコルは 2 つあります。 POP3 (インターネット標準 RFC1939 で定義) と IMAP (インターネット標準 RFC2060 で 定義)です。 事実上全ての ISP が POP3 をサポートしています。 ただし IMAP (こちらの方が強力です) をサポートしている ISP の数も増えつつあります。
POP3 のセッションの例を以下に示します:
S: <クライアントがサービスポート 110 に接続します>
R: +OK POP3 server ready <1896.697170952@mailgate.dobbs.org>
S: USER bob
R: +OK bob
S: PASS redqueen
R: +OK bob's maildrop has 2 messages (320 octets)
S: STAT
R: +OK 2 320
S: LIST
R: +OK 2 messages (320 octets)
R: 1 120
R: 2 200
R: .
S: RETR 1
R: +OK 120 octets
R: <POP3 サーバがメッセージ 1 を送ります>
R: .
S: DELE 1
R: +OK message 1 deleted
S: RETR 2
R: +OK 200 octets
R: <POP3 サーバがメッセージ 2 を送ります>
R: .
S: DELE 2
R: +OK message 2 deleted
S: QUIT
R: +OK dewey POP3 server signing off (maildrop empty)
S: <クライアントが接続を切ります>
IMAP のセッションで使われるコマンドや応答は POP3 と違いますが、 ロジックはよく似ています。
POP3 や IMAP の利点を生かすためには、 リモートメールクライアントプログラムを使って メールを取り寄せる必要があります。 一部のメールユーザエージェントにはクライアント機能が組み込まれており (どのクライアントがどのプロトコルをサポートしているのかは後述します)、 例えば Netscape ブラウザは POP と IMAP の機能を最初からサポートしています。
MUA に組み込まれている POP クライアント機能の大きな欠点は、 サーバにポーリングをかけるよう明示的にメーラに指示しなければならない点です。 xbiff(1) や同じ機能を持つプログラムから通知は受けられません。 これらはローカルのメールか、従来の SMTP による「push」 型接続を使って配送されたメール用のものだからです。 また当然ながら、全ての MUA が POP/IMAP を使えるわけではないので、 他の機能をあきらめなければならないかもしれません。
お使いの Linux ディストリビューションにはたぶん fetchmail というプログラムが入っていると思います。 このプログラムは特別に設計されていて、 リモートメールサーバと通信し、メールを取り込み、 ローカルのメール受信プログラムと SMTP で通信して、 このメールを通常のメール配送経路に送ることができるようになっています。
メールをサーバ上に保管する必要がある場合 (例えば、クライアントマシンがしょっちゅう変わる場合) を除くと、 POP/IMAP 機能を持つどんなユーザエージェントよりも fetchmail の方がたぶん優れています。 fetchmail はバックグラウンドで動作して 定期的にサーバに問い合わせることができるので、 xbiff(1) や他のメール到着通知プログラムを SMTP メールの場合と同じように使うことができます。 また fetchmail を MUA に付いているクライアント機能と比べると、 風変わりなサーバや標準に準拠していないサーバの癖に対して強く、 エラー回復機能も優れています。
(fetchmal がある場合とない場合の)両方の動作を表す図を示します:
+---------+ +-------+
+-------+ 入力 | 送信側 | 呼出 |送信側 |
| Alice |--------->| MUA |--------->| MTA |::::>::::
+-------+ | | | | ::
+---------+ +-------+ :: 送信側
:: の
SMTP :: マシン
::::::::::::::::::::::::::::<::::::::::::::::::::::::::::
::
.::.......................................................................
::
:: +---------+ +-----+ +--------+
:: | 受信側 | 呼出 | | 配送 | Bobの |
::::>| MTA |--------->| LDA |============>|サーバの|::::>::::
| | | | |メール | ::
| | | | |ボックス| :: メール
+---------+ +-----+ +--------+ :: サーバ
::
POP または IMAP ::
::::::::::::::::::::::::::::<:::::::::::::::::::::::::::::::::::
::
.::........................................................................
::
:: +-----------+
:: | |
:::::::>::::::::::::| fetchmail |:::::::: 受信側
:: | | :: マシン
:: +-----------+ :: (fetchmail
:: :: がある場合)
:: ::::::::::::::::<:::::::::::::::::::
:: ::
:: :: +---------+ +-----+ +--------+
:: :: | 受信側 | 呼出 | | 配送 | Bob の |
:: ::::>| MTA |--------->| LDA |===============>| メール |
:: | | | | |ボックス|
:: +---------+ +-----+ +--------+
:: | |
:: | |
:: +----------------<-------------+ |
:: | |
:: +--------------+ +-------+ |
:: | Bob の | | Bob の|<----------+
:: |通知プログラム| | MUA |
:: +--------------+ +-------+
:: | |
.::........................................................................
:: . | |
:: fetchmail . | |
:: がない場合 . | |
:: . | +-----+ |
:: +----------+ . +----->| |<----+
:: | Bob の | . | Bob |
:::::| POP/IMAP |----.--------->| |
| 対応 MUA | . +-----+
+----------+ .
届いたメールがメールボックスに追加される時に、 あるメッセージの終わりと次のメッセージの始まりを示す 何らかの区切り記号を入れるのは MTA の役割です。
Unix においてほとんどのメーラが従っている慣習として、 ``From '' で始まる (空白にも意味があります) それぞれの行がメッセージの先頭であるという決まりがあります。 本文中に ``From '' で始まる行が現われた場合には、 Unix の MTA は通常「小なり」の記号を前に置き、 ``>From '' という形にします。 RFC822 形式のヘッダがこの From 行に続きます (普通は送信者の名前と受信日が続きます)。
この慣習は Unix バージョン 7 が起源なので、 この形式のメールボックスは「V7 メールボックス」と呼ばれます。 「mbox 形式」と呼ばれることもあります。 特に断らない限り、本 HOWTO で説明する全てのプログラムは この形式を使います。しかしこれはそんなに普遍的ではなく、 異なる形式を利用・生成するツールによって、 お互いが混乱する可能性もあります。
他に知られている (そして注意しなければならない!) 形式は 4 つあります。 BABYL, MMDF, MH, qmail maildir です。これらの中では MMDF が最も単純です。 MMDF は Ctrl-A (ASCII の 001) 4 つの後に CR-LF が続く形式の 区切り記号を使います。 MMDF は昔に使われていた、 比較的大雑把なインターネットメール配送方式です。 その子孫はまだ SCO システムで使われています。
BABYL は MMDF とは別の生き残りであり、 MIT の昔のメールシステムが起源です。 BABYL はまだ Emacs のメールリーダモードで使われています。
MH と qmail maildir は「メールボックス」の形式ですが、 実際にはメールボックスをメッセージ 1 つずつに分割して ディレクトリに置く方式です。このような「メールボックス」に grep をかけても無駄です。なぜならディレクトリファイルに grep しても、ディレクトリの内部データを示すデータ列を参照するだけからです。
(訳注: まあ後半はあまりできの良くない冗談でしょう(^_^;)
Microsoft Outlook Express の .mbx 形式のメールボックスは、 mbx2mbox というアプリケーションを使えば RFC822 形式に変換できます。