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

コミュニティとしてだけでなく、情報発信手段としても有効な「メーリングリスト」。しかし、ヘッダなどの知識なしに安易に運用するのは危険だ。構築・運用方法とともに、メール配送の仕組みについても解説する。

[鶴長鎮一，＠IT]

コラム：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を行っている様子です。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　Headerでは[e-mail]へメールを送信しているはずなのに、実際は[e-mail]に届いていることが分かるはずです。メールループを未然に防ぐには、この「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サーバ運用・管理術」バックナンバー

• qmailをより使いこなすTips（便利な小技編）
• qmailをより使いこなすTips（インストール関連編）
• qmail導入・運用関連トラブルシューティング集
• qmailのパフォーマンス・チューニング
• ツールを使った効率的なログ分析術
• daemontoolsによるロギングとプロセス監視
• メールサーバで行うウイルス対策
• GUI管理ツールの導入とユーザー情報のSQL化
• バーチャルドメインにおけるqmailの運用
• メーリングリストの構築と運用（後編）
• メーリングリストの構築と運用（前編）
• SPAMメール徹底対策
• POP／IMAPサーバの構築と不正中継対策
• qmailによるSMTPサーバの構築