メーリングリストの構築と運用（前編）：実用qmailサーバ運用・管理術（4）（4/4 ページ）

» 2001年12月11日 00時00分公開

コラム：Envelope・Header・Data

　インターネットで交換されるメールは、次のようなパートで構成されています。

Envelope：エンベロープ（表書き）
Header：ヘッダ
Data：メッセージの内容

　HeaderとDataはメールソフトの［メッセージの詳細］などで見ることができるためなじみの深いものですが、EnvelopeはMTA（サーバ）間でメッセージが交換される際に使用されるものであるため、普通見ることはできません。

　HeaderとDataが便せんに書かれた手紙の内容だとすると、Envelopeはその名のとおり封筒に書かれたあて先（Envelope To）や差出人（Envelope From）になります。Envelopeを見ることができないのは、手紙が開封されて封筒が始末された後では差出人やあて先が分からないのと同じことです。

　MTAは受け取った便せんを封筒に入れ、差出人とあて先を記入し（Envelope化し）、次のMTAに配信します。受信側のMTAは封書を開封し、中身のメッセージだけをユーザーに引き渡します。つまり、MTA間ではHeaderではなくEnvelopeが利用されているのです。いくら便せんにクパチーノやサンノゼと書こうとも、肝心の封筒に岐阜県各務原市と書いてあればそちらに届いてしまうのと同じように、Envelopeで指定されたあて先にしか届きません。

　Envelope ToやEnvelope Fromには、さまざまな表現が用いられます。

Envelope From（どこのアドレスからメッセージが送信されたか）
　revers-path（RFC 821用語）
　envelope sender（送り主）
　　「MAIL FROM」コマンド時に渡される
　　しばしばメールヘッダの「Return-Path:」として記録される
Envelope To（どこのアドレスへメッセージを送信するか）
　forward-path（RFC 821用語）
　envelope recipient（受取人）
　　「RCPT TO」コマンド時に渡される
　　しばしばメールヘッダの「Received:」として記録される

　もう少し実体がつかみやすいように、telnetコマンドを使ったMTAとの対話で見ていきましょう。以下は、qmailが動作しているサーバで直接telnetを行っている様子です。

$ telnet localhost smtp

            Trying 127.0.0.1...

            Connected to localhost.

            Escape character is '^]'.

            220 qmail.example.jp ESMTP

            helo

            250 qmail.example.jp

            mail from: <user1@example.jp>　←ここに「Envelope 
            From」データをタイプ

            250 ok

            rcpt to: <user2@example.jp>　←ここに「Envelope 
            To」データをタイプ

            250 ok

            data

            354 go ahead

            From: userA@example.jp　←以降「.」まで「Header」「Date」データをタイプ

            To: userB@example.jp

            tset mail

            .　←終了「.」の入力

            250 ok 1006330511 qp 26178

            quit

            221 qmail.example.jp

            Connection closed by foreign host.

　HeaderではuserB@example.jpへメールを送信しているはずなのに、実際はuser2@example.jpに届いていることが分かるはずです。メールループを未然に防ぐには、この「Envelope From」の理解が重要になります。

　メールソフトで返信ボタンを押してメールを作成する場合、送られてきたメールヘッダの「Replay-to」や「From」を返信メッセージの「To」に置き換えますが、MTA間でエラーの通知を行う先はEnvelope Fromになります。「User Unknown」などのエラー通知がMLや投稿者に流れずML管理者に戻るように注意する必要があります（ezmlmでは対応されています）。

　Headerデータ中のReply-Toも注意を必要とする重要なフィールドです。Reply-Toは、通常はFromフィールドのアドレスと違うアドレスに返信させたいときに用いるものです。Fromと同じアドレスをReply-Toに設定してしまうなど、誤解の多いフィールドでもあります。

　例えば、MLの参加者の中にメール自動応答プログラムを設定してしまったユーザーがいたとします。メール自動応答プログラムはMTAではなくMTU（メールクライアント）として機能しており、Envelopeデータを参照することができず、Headerデータの中で返信先を探し、Replay-Toに応答メッセージを返してしまう仕様だったとします。ML側で親切のつもりでReply-ToをMLのアドレスで上書きするようにしていた場合、応答メッセージはMLのアドレスに送られ、MLはこれをユーザーの投稿メッセージと解釈して通常どおり一斉送信します。すると、再び自動応答プログラムがメッセージを受け取ってMLに自動応答します。これが無限に続く現象が「メールループ」です。

　実際には自動応答プログラムやezmlmの防御機能（注）により防げますが、リストの参加者がどのような自動応答プログラムを用意しているか予想できないため、対策を施しておくことが望まれます。

注：ezmlm側でHeaderデータに「Precedence」フィールドを加え、メッセージの重要度を設定することができます。「bulk」や「list」が指定されていれば自動応答メッセージに応答しないようになるものもあります。自動応答プログラム以外でも、サーバによってはPrecedenceフィールドのためエラーを返さなかったり、ボディを削ってヘッダだけを返すなど、エラーメールを抑制するものもあります。

「次回」へ

「実用qmailサーバ運用・管理術」バックナンバー