LPI 試験対策: メールとニュース

LPIC-2 (中級レベルの管理) の主題 206

このチュートリアルは、Linux での中級レベルのネットワーク管理について取り上げる全 7 回からなるシリーズの第 2 回目です。今回は、David Mertz が Linux をメール・サーバーとして使用する方法と、ニュース・サーバーとして使用する方法を説明します。インターネット全体で見ると、e-メールはインターネットの主な用途のひとつであり、e-メール・サービスのプラットフォームとして最適なのは、Linux であると考えられます。このチュートリアルでは、メール転送、ローカルでのメール・フィルタリング、そしてメーリング・リストを保守するためのソフトウェアについて取り上げます。また、NNTP (Network News Transfer Protocol) プロトコル対応のサーバー・ソフトウェアについても簡単に説明します。

2012年 3月 29日 ― 読者からのコメントに対応し、「参考文献」に記載されている「INN ホーム・ページ」、「LPIC プログラム」、および「Sendmail に関する書籍のリスト」の各リンクの URL を更新しました。(訳注: このチュートリアルの原文は 2005年に初版が公開されたものであるため、LPI 試験の構成や内容は現在とは異なる部分があり、その他の内容も 2005年時点の現状に基づいて書かれています)

David Mertz, Developer, Gnosis Software

David MertzDavid Mertz は、2000年から続いている developerWorks の連載、「魅力的な Python」と「XML の論考」の著者です。彼の著書には『Text Processing in Python』もあります。David について詳しくは、彼個人の Web ページにアクセスしてください。



2012年 4月 26日

始める前に

はじめに、このチュートリアル・シリーズから学べる内容、そしてチュートリアルを最大限に活用する方法を紹介します。

このシリーズについて

LPI (Linux Professional Institute) では、Linux システム管理者を初級レベル (「認定レベル 1」) と中級レベル (「認定レベル 2」) の 2 つのレベルで認定しています (訳注: 2012年 3月現在は 3 つのレベルがあります)。認定レベル 1 を取得するには 101 試験と 102 試験に合格する必要があり、認定レベル 2 を取得するには 201 試験と 202 試験に合格する必要があります。

developerWorks では、この 4 つの試験に備えるためのチュートリアルを提供しています。各試験の出題範囲には複数の主題が含まれるため、developerWorks でも主題ごとに自習用のチュートリアルを用意しています。LPI 202 試験の出題範囲となっている 7 つの主題 (訳注: 2012年 3月現在、LPI 202 試験は主題 208 から主題 213 までの 6 つの主題で構成されています) と、それぞれに対応する developerWorks チュートリアルを以下に記載します。

表 1. LPI 202 試験: チュートリアルと主題
LPI 202 試験の主題developerWorks チュートリアルチュートリアルの概要
主題 205LPI 202 試験 (主題 205):
ネットワーク構成
基本的な TCP/IP ネットワークの構成方法を学びます。これには、ハードウェア層 (一般的には Ethernet、モデム、ISDN、または 802.11) からネットワーク・アドレスのルーティングまで含まれます。
主題 206LPI 202 試験 (主題 206):
メールとニュース
(本チュートリアル) Linux をメール・サーバーとして使用する方法と、ニュース・サーバーとして使用する方法を学びます。メール転送、ローカルでのメール・フィルタリング、メーリング・リストを保守するためのソフトウェア、そして NNTP プロトコル対応のサーバー・ソフトウェアについて取り上げます。試験の具体的な目標を記載した、以下の表を参照してください。
主題 207LPI 202 試験 (主題 207):
DNS
Linux を DNS サーバーとして使用する方法を学びます。BIND の基本的な構成方法、DNS ゾーンの管理方法、そして DNS サーバーをセキュアにする方法を取り上げます。
主題 208LPI 202 試験 (主題 208):
Web サービス
Apache Web サーバーをインストールして構成する方法、Squid プロキシ―・サーバーを実装する方法を学びます。
主題 210LPI 202 試験 (主題 210):
ネットワーク・クライアントの管理
DHCP サーバー、NIS クライアントおよびサーバー、LDAP サーバー、PAM 認証サポートを構成する方法を学びます。
主題 212LPI 202 試験 (主題 212):
システム・セキュリティー
ルーターを構成する方法、FTP サーバーをセキュアにする方法、SSH を構成する方法、それ以外の各種セキュリティー管理タスクを実行する方法を学びます。
主題 214LPI 202 試験 (主題 214):
ネットワークのトラブルシューティング
ネットワークの問題を検出して解決できるようにするためのツールとコマンドについて学びます。

認定レベル 1 の試験に備えるためには、LPI 101 試験のための developerWorks チュートリアルを参照してください。LPI 202 試験以外の認定レベル 2 の試験に備えるためには、LPI 201 試験のための developerWorks チュートリアルを参照してください。また LPI 試験に備えるための developerWorks チュートリアル全体についての概要も読んでください。

Linux Professional Institute では、特定のサード・パーティーによる試験対策用の教材や講座などは認定していません (訳注: 2012年 3月現在では認定を行っています)。詳細については、info@lpi.or.jp にお問い合わせください。

このチュートリアルについて

「メールとニュース」チュートリアルへようこそ。このチュートリアルは、Linux での中級レベルのネットワーク管理について取り上げる全 7 回からなるシリーズの第 2 回目です。今回は、Linux をメール・サーバーとして使用する方法と、ニュース・サーバーとして使用する方法を学んでください。このチュートリアルでは、メール転送、ローカルでのメール・フィルタリング、そしてメーリング・リストを保守するためのソフトウェアについて取り上げます。また、NNTP プロトコル対応のサーバー・ソフトウェアについても簡単に説明します。

このチュートリアルは、LPI の主題 206 の目標 (訳注: 2005年時点のものです) に合わせて編成されています。おおまかには、目標の重要度が高くなるほど、試験での設問が多くなると思ってください。

表 2. メールとニュース: このチュートリアルで対象とする試験目標 (訳注: 2005年時点の試験目標)
LPI 試験の目標目標の重要度目標の要約
2.206.1
メーリング・リストの構成
重要度 1Majordomo をインストールし、このソフトウェアを使用してメーリング・リストの保守を行います。Majordomo のログを表示することで、Majordomo に関する問題を監視します。
2.206.2
Sendmail の使用
重要度 4e-メールのエイリアス、メール・クォータ、および仮想メール・ドメインを含め、Sendmail の構成を管理します。この目標には、内部メール・リレーの構成、および SMTP サーバーの監視も含まれます。
2.206.3
メール・トラフィックの管理
重要度 3クライアント・メール管理ソフトウェアを実装して、着信ユーザー・メールをフィルタリング、ソート、監視します。この目標には、サーバー・サイドとクライアント・サイドの両方で Procmail のようなソフトウェアを使用することも含まれます。
2.206.4
ニュースの配信
重要度 1INN をインストールし、ニュース・サーバーを構成します。この目標には、サービス対象のニュース・グループのカスタマイズと監視も含まれます。

前提条件

このチュートリアルを最大限に活用するには、Linux の基礎知識と、チュートリアルに記載されているコマンドを演習できる実際の Linux システムが必要です。


メールおよびニュースについて

メール・サーバーやニュース・サーバーとして Linux が広く普及するにつれ、より改良されたツールが開発されるようになっています。LPI 認定試験が初めて作られた当時、最もよく使われていたツールは、メール転送には Sendmail、ローカルでのメール処理には Procmail、メーリング・リストには Majordomo、NNTP には innd (InterNetNews デーモン) でした。これらのツールのうち、最後に挙げた innd は、おそらく 2005年の今でもニュース用ツールのデフォルトの選択肢であると言えるでしょうが、NNTP プロトコルは、技術的に優れているにも関わらず、e-メールのメーリング・リストや Web ベースのディスカッション・フォーラムによって影が薄くなっています。

前述のツールのなかで、Sendmail と Procmail は 2005年現在でも広く使われているものの、その普遍性にはかつてほどの勢いはありません。Sendmail を置き換えるツールとして最もよく使われているのは、Sendmail との後方互換性をサポートする機能が含まれる postfix です。ローカルでのメール処理を行うツールには、さまざまな選択肢がありますが、それでもなお、Procmail は人気を維持しています。その一方、Majordomo は最近では多少時代遅れのツールとなっています。以前の listserv ソフトウェアが Majordomo によって大々的に置き換えられたように、最近では mailman によって Majordomo の影が薄くなっています。このような状況ではありますが、このチュートリアルでは 2005年現在の LPI 試験の主題に合わせて Majordomo について説明します。

その他のリソース

ほとんどの Linux ツールの例に漏れず、話題に上っているユーティリティーについては、どんな場合にも man ページが常に役立ちます。バージョンとスイッチは、ユーティリティーやカーネルのバージョン、あるいは Linux のディストリビューションによって異なる可能性があります。さらに詳しい情報を入手するには、Linux Documentation Project に HOWTO 文書をはじめ、役に立つ各種のドキュメントが豊富に揃っているので、「参考文献」のリンクを参照してください。Linux ネットワークに関する書籍も、さまざまなものが出版されています。なかでも、私が大いに参考になると思ったのは、オライリー・ジャパンから出版されている『TCP/IP ネットワーク管理』(Craig Hunt 著) です (この書籍を読むときには、「参考文献」のリンクを参考に、最新版を調べてください)。


メーリング・リストの構成

Majordomo の役割

メーリング・リスト・マネージャーは、基本的に Sendmail などのメール転送エージェント (MTA: Mail Transport Agent) のローカル拡張機能です。基本の仕組みとしては、システム上で実行されている MTA からメーリング・リスト・マネージャーにアドレス一式が渡されると、メーリング・リスト・マネージャーはこれらのアドレス宛の着信メッセージを変更、処理、そして場合によっては再送信します。メーリング・リスト・マネージャーが受け取るメッセージの中には、メーリング・リスト自体に配信されるように意図されたメッセージもあります (おそらくメーリング・リストへの配信が許可されているかどうかを検証する必要があります)。それ以外のメッセージは、メーリング・リストのステータス (特定の購読者の購読オプションなど) を変更する制御メッセージです。メーリング・リスト・マネージャーがメールを配信することはありません。その役割は、メーリング・リスト・マネージャーのサポートを行う MTA に任されます。

このチュートリアルについて紹介するセクションで述べたように、2005年現在、Majordomo は最先端のメーリング・リストではありません。メーリング・リストを新しくインストールするのであれば、おそらく Mailman が最も適した選択肢となるでしょう。しかし一方で、Majordomo はまだ完璧に機能します。また、多くの古いシステムにインストールされていて、これらのシステムでは問題なく動作しています (何年も運用されているメーリング・リストをサポートしていることもあります)。

ただし、Majordomo を使用する場合、バージョンに関して注意が必要です。このチュートリアルを作成した何年か前に、Majordomo 1.x シリーズを改良版である Majordomo2 の開発が始められましたが、残念ながら、リリース状態に至る前に立ち消えとなりました。Majordomo2 (ベータ版) は非常に限られた数のシステムで使用されているかもしれませんが、このチュートリアル作成時の最新安定版は Majordomo 1.9.5 です。したがって、このチュートリアルではバージョン 1.9.5 について説明します。

Majordomo をインストールする

Majordomo ソフトウェアのアーカイブは、Majordomo サイト (「参考文献」にリンクを記載) で入手することができます。

majordomo-1.94.5.tgz のような名前の付いたファイルを解凍した後は、必ず INSTALL ファイルをよく読んでください。Majordomo システムを正常に動作させるには、このファイルで説明しているステップのすべてを実行する必要があります。システムをビルドするには、ほとんどのソース・インストールで一般的に使われている make; make install ステップ、そして make install-wrapper を使用します。正常にインストールされているかどうかは、例えば cd /usr/local/majordomo-1.94.5; ./wrapper config-test などのコマンドで検証できるので、必ず検証してください (make install によって、インストールに関する詳細情報がメッセージに表示されます)。

ビルドの前に、Makefile を変更し、majordomo.cf を作成または変更します。出発点としては、ソース・ディストリビューションに含まれる sample.cf を majordomo.cf にコピーすることから始めることができます。Makefile には多数の環境変数が設定されていますが、そのうち最も重要で扱いが難しいのは、おそらく W_GROUP です。これは、Majordomo が実行されるグループの数値による gid で、そのグループに該当するのは、ほとんど必ずと言ってよいほどデーモンです。大抵のシステムでのデーモンの gid は 1 ですが、念のため、以下のコマンドを使用して確かめてください。

$ id daemon
uid=1(daemon) gid=1(daemon) groups=1(daemon)

Makefile ファイルに設定されている他の変数には、インタープリターのパスを指定する PERL、Majordomo のインストール先を指定する W_HOME などがあります。

新しく作成した majordomo.cf ファイルも、make install を実行する前に編集する必要があります。変更が必要な Perl 変数のほとんどは、ファイルの先頭近くに集まっています。必ず調整しなければならいのは、$whereami および $homedir です。他の変数が適切であるかどうかも確認してください。

Sendmail に Majordomo を使用するように指示する

インストールの最終ステップは、Sendmail に Majordomo と通信するように指示することです。そのためには、/etc/sendmail.cf ファイル内に以下のような行が必要です。

OA/path/to/majordomo/majordomo.aliases

M4 プロセッサーを使用して Sendmail 構成ファイルを生成している場合には、以下のような行を指定することができます。

define(`ALIAS_FILE',`/etc/aliases,/path/to/majordomo/majordomo.aliases')

以下の majordomo.aliases サンプルに値の例を示します。

リスト 1. majordomo.aliases サンプル
majordomo:  "|/usr/test/majordomo-1.94.5/wrapper majordomo"
majordomo-owner: you
owner-majordomo: you
test:           "|/usr/test/majordomo-1.94.5/wrapper resend -l test test-list"
test-list:      :include:/usr/test/majordomo-1.94.5/lists/test
owner-test:     you
test-owner:     you
test-request:   you

これらの値は当然、ユーザーそれぞれの具体的な設定に合わせてカスタマイズする必要があります。上記サンプルで「you」はリスト管理者の名前を意味します (システム全体の管理者である必要はありません)。

新規 Majordomo リストを作成する

上記サンプルの設定では、「test」という名前のリストを作成し、リストを管理するためのアドレスとして「test-owner」、「test-request」、その他を設定しています。実際に使用する際には、別の名前を指定したリストが必要になるでしょう。そのためには、以下の手順を行ってください。

  1. カレント・ディレクトリーを majordomo.cf に定義されているディレクトリー $listdir に変更します。
  2. my-list-name と my-list-name.info という名前 (適当に変更してください) のファイルを作成し、chmod でファイルのパーミッションを 664 に変更します。後者のファイルには、リストの説明が含まれます。
  3. majordomo.aliases ファイルに、「test」サンプルのパターンに従って、いくつかのエイリアスを作成します (例えば、「foo-owner」、「foo」、「foo-request」など)。
  4. リストのメンバーの subscribeunsubscribesignoff などを実行するための要求を送信します。
  5. $filedir および $filedir_suffix 変数で指定されたロケーションに、アーカイブ・ディレクトリーを作成します。
  6. $digest_work_dir の下にダイジェスト・サブディレクトリーを作成します。このディレクトリー名には、ダイジェスト・リストと同じ名前を使用してください (例えば、test-digest)。
  7. すべてのものが、majordomo グループのmajordomo ユーザーによって所有されていること、所有者とグループの両方に書き込みが許可されていること (つまり、ファイルのパーミッションが 664、ディレクトリーのパーミッションが 775 に設定されていること) を確認します。
  8. Majordomo に対してコマンド config <リスト名> <リスト名>.admin を実行します。これによって、リストのデフォルト構成ファイルが作成されて、返送されてくるはずです。

Sendmail の使用

Sendmail の役割

Sendmail は、メール転送エージェント (MTA) です。MTA は、メール・メッセージをルーティングし、変更し、さまざまな種類のメール・システムに配信します。メーリング・リスト・ソフトウェアの歴史と多少重なる歴史を持つ Sendmail には、Sendmail X という「永久ベータ」バージョンがあります。Sendmail X は安定版である Sendmail 8.x シリーズのアップグレード、あるいは Sendmail 8.x シリーズに置き換わるものとして意図されていますが、Majordomo が Mailman にその座を奪われつつあるのと同様に、Sendmail も他の MTA によって影がある程度薄くなっています。そのような新しい MTA の代表格は Postfix ですが、Qmail と Exim も広く使用されています。それでもなお、Sendmail は Linux システムで最も広く使用されている MTA として、かろうじて健在です。2005年 9月 16日の時点で、最新の Sendmail の安定版リリースは 8.13.5 となっています。

Sendmail について書かれた本は数多くあるので、「参考文献」で入手できる本のリストを参照してください。なかでも最も包括的に Sendmail を説明している本は、Bryan Costales 氏と Eric Allman 氏による共著書『sendmail 第 3 版』(オライリー・ジャパン、2002年) です。全 1,232 ページにも及ぶこの本では、このチュートリアルで説明する内容よりも遥かに多くの話題を網羅しています。

Sendmail は原則的に UUCP などの多数のメール転送プロトコルをサポートしていますが、圧倒的に普及しているのは SMTP (Simple Mail Transport Protocol) です (ここで言う SMTP には、MIME でエンコードされた高度なメッセージ本文に対応する ESMTP (Extended SMTP) も含まれます)。基本的に、他の SMTP ホストに転送されないメールは、メッセージがローカル・ファイルに入れられてローカル・システムに配信されます。ローカルのメール・ユーザー・エージェント (MUA: Mail User Agent) は、Sendmail (または別の MTA) がローカル・ファイルに取り込んだメッセージの読み取りを (そして多くの場合、POP3 や IMAP を使用してメールの取得も) 行いますが、送信メッセージの配送については Sendmail に依頼するのが通常です。ただし、一部の MUA はメッセージを後で処理するために Sendmail キューに入れることはせずに、SMTP サーバー (ローカル、あるいはリモートの Sendmail インスタンスなど) と直接通信します。通常、Sendmail キューは /var/spool/mqueue/ 内にあります。

Sendmail をインストールする

最初に行うべき作業は、sendmail.org (「参考文献」のリンクを参照) から、最新の Sendmail ソフトウェア (このチュートリアル作成時点では sendmail.8.13.5.tar.gz など) を入手することです。このファイルを通常どおりの方法で解凍してください。ただし、make; make install パターンを使用する多くのアプリケーションとは異なり、Sendmail をビルドするには sh Build を実行します。初期ビルドが完了したら、cd でカレント・ディレクトリーを cf/cf/ サブディレクトリーに変更し、該当する *.mc ファイルを sendmail.mc としてコピーして、この sendmail.mc をカスタマイズします。そして、以下のコマンドを実行して sendmail.cf ファイルを生成します。

$ m4 ../m4/cf.m4 sendmail.mc > sendmail.cf

あるいは、ショートカットとして sh Build sendmail.cf を実行することもできます。不思議に思えるかもしれませんが、これらのコマンドは両方とも M4 マクロ・プロセッサーを使用して、より読み取りやすいフォーマットから実際の Sendmail 構成を生成します。実際の sendmail.cf ファイルは編集可能な ASCII ではあるものの、かなり不可解なので、手作業による変更は最小限にとどめてください。

最後に、sendmail バイナリー・ファイル (例えば obj.Linux.2.6.10-5-386.i686/sendmail/sendmail のような場所に置かれています) をその最終ロケーション (通常は /usr/sbin/) にコピーし (既に sendmail バイナリー・ファイルがある場合には、そのファイルのバックアップを取るようにしてください)、sendmail.cf ファイルを /etc/mail/sendmail.cf にコピーします。後者のファイルについては、sh Build install-cf を実行して cf/cf/ サブディレクトリーにコピーしても構いません。おそらく、su または sudo を実行することにより、これらのディレクトリーに対するアクセス権を設定する必要があります。

makemap や mailstats など、多くのユーティリティーには、Sendmail が提供されています。それぞれのユーティリティーには、Sendmail 用のディレクトリーに README が置かれています。これらの Sendmail は、該当するサブディレクトリーから sh Build install を実行してインストールすることができます。

sendmail.cf ファイル

Sendmail で複雑な部分は主に sendmail.cf ファイルに含まれています。この構成ファイルには、Sendmail の主要な機能の設定の他に、Sendmail 環境の設定も多少含まれていますが、このファイルに主に含まれているのは、特定のメカニズムで書き換えや配信を行うアドレスのパターンです。

構成可能な書き換えメカニズムには、genericstablevirtusertable の 2 つがあります。これらのメカニズムを使用して、ローカル・ユーザーと外部アドレスとの間のマッピングを行うことができます。ローカル・ユーザーを外部アドレスにマッピングする場合も、その逆の場合も、最初にエイリアス・リストを記載したファイルをプレーン・テキストとして作成します。以下にマッピングの例を示します。

リスト 2. アウトバウンド・マッピング
david                     david.mertz@gmail.com
root                      root@gnosis.cx
dqm@gnosis.lan            david.mertz@gmail.com

以下は、着信メールをローカル・アカウントにマッピングする場合の例です。

リスト 3. インバウンド・マッピング
david@mail.gnosis.cx      david
david@smtp.gnosis.cx      david
david@otherdomain.net     david
@mail.gnosis.cx           %1@external-host.com
owner@list.gnosis.cx      owner%3
jax@bar.com               error:5.7.0:550 Address invalid

これらのエイリアスをコンパイルするには、以下のように makemap ユーティリティーを使用します。

$ makemap dbm /etc/mail/virtusertable < inbound
$ makemap hash /etc/mail/genericstable < outbound

これらのマップを使用可能にするための構成は、sendmail.cf (または使用する任意の構成ファイル) で M4 マクロを使用して行います。

リスト 4. sendmail.cf でのマッピングを有効にする
DOMAIN(gnosis.cx)dnl
FEATURE(`virtusertable', `dbm /etc/mail/virtusertable')dnl
FEATURE(`genericstable', `hash /etc/mail/genericstable')dnl
GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')dnl

上記では、さまざまなことが行われています。まず、DOMAIN マクロがさらに追加のマクロとして、cf/domain/gnosis.cx.m4 のようなファイルを使用するように指示します。これに続く FEATURE マクロは、virtusertable および genericstable をそれぞれ使用できるようにします。そして最後の GENERICS_DOMAIN_FILE マクロが、genericstable に含まれる名前の再マッピング対象とするドメインを定義します。

書き換えは、指定されたすべてのルールに従います。テスト・モード (sendmail -bt) で、特定のアドレスに対して行われる書き換え処理を確かめることができます。例えば、genericstable を使用すると、ローカル・ユーザー「david」宛てのメールは外部の david.mertz@gmail.com に配信されるはずです。localhost が /etc/mail/generics-domains に定義されていれば、david@localhost 宛てのメールはこれと同じ場所に配信されます。

この逆の方向では、david@mail.gnosis.cx 宛てに着信するメールは書き換えられて、ローカル・ユーザー「david」に配信されます。Sendmail では複数のドメインを同時に操作できるので、david@otherdomain.net も同じローカル・ユーザーに配信されます。

ワイルドカード記号を使用すると、さまざまなことが可能になります。例えば、特定のローカル・ユーザー宛てのメールを対象とするのではなく、mail.gnosis.cx に送信されるメールを external-host.com の同じユーザー名に転送することができます。しかし、これは単純なパターンに過ぎません。さらに興味深いのは、%3 を使用して複数の名前情報を追加できることです。その場合、owner-foo@list.gnosis.cx と owner-bar@list.gnosis.cx は、それぞれローカル・ユーザーの「owner-foo」、「owner-bar」に配信されます (ただし、さらに書き換えが行われない場合に限ります)。これらのローカル・ユーザーの代わりに、メーリング・リスト処理システムや、他の自動メッセージハンドラーを指定することもできます。特殊なケースとして、特定のアドレスに対しては、書き換えを行う代わりにエラーを発生させることも可能です。

これまで説明してきた内容は、Sendmail に追加できる書き換えルールの表面をかじっただけに過ぎませんが印象はつかめたはずです。さらに詳細を調べるには、この話題に関して詳しく説明している本を一冊購入してください。

Sendmail を実行する

Sendmail は、いくつかのモードで実行することができます。最もよく使われるモードは、デーモンとしてバックグラウンドで実行し、定期的にそのキューを処理するというモードです。その場合には、例えば以下のコマンドを実行します。

$ /usr/sbin/sendmail -bd -q10m

このコマンドによって Sendmail はデーモンとして動作し、10 分間隔でキューをチェックします。Sendmail をデーモンとして実行するのではなく、キューをまとめて処理するために、その都度 1 回だけ実行することもできます。その場合には、以下のコマンドを実行します。

$ /usr/sbin/sendmail -q

前述のとおり、Sendmail にはアドレスの書き換えルールを確認するためのテスト・モードがあります。以下のリストはその一例です (「Linux Network Administrators Guide」から引用。「参考文献」のリンクを参照)。

リスト 5. Sendmail テスト・モード
$ /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vstout.vbrew.com
rewrite: ruleset   3   input: isaac @ vstout . vbrew . com
rewrite: ruleset  96   input: isaac < @ vstout . vbrew . com >
rewrite: ruleset  96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset   3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset   0   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset  98   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset  98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset   0 returns: $# local $: isaac

e-メール・トラフィックの管理

Procmail の役割

Procmail はメール・プロセッサーです。基本的に、Sendmail や他の MTA がローカル・メール・ボックスにメールを配信した後は、ユーザーが MUA を使用して受信箱の中のメールを処理することができます。ユーザーは、例えば各種のフォルダーにメッセージを保存することもあれば、メッセージを削除したり、さまざまな関係者に転送したり、あるいはメッセージに返信したりすることもあるでしょう。MUA でこれらのタスクを行う場合、それは手動による対話プロセスであるため、時間がかかることもあります。

Procmail は、メールに必要な処理をルールに従って記述できる場合には、自動的にそのタスクを行うことができるプログラムです。例えば自分の母親からの私的な e-メールに返信するときには、もちろん個人的な配慮が必要ですが、他の大多数のメッセージについては、受信時の具体的な処理方法を前もって指定できると便利です。メッセージの自動処理内容を決定するルールには、具体的なパターンに基づくヘッダー・フィールドや、メッセージ本文に含まれる特定の内容などが必要になるでしょう。さらに、統計スパム・フィルターなどといった、より詳細で特化された外部プログラムが必要になる場合もあります。

Procmail を使用可能にする

お使いの Linux ディストリビューションには、Procmail がすでにインストールされている場合があります。インストールされていなければ、ソース・アーカイブを procmail.org (「参考文献」を参照) で入手してください。このチュートリアルを作成している時点では、バージョン 3.22 が最新です。あるいは、Linux ディストリビューションのインストール・システム (例えば、Debian では apt-get install procmail) を使って、Procmail をバイナリーとしてインストールすることもできます。ソースからビルドするには、単純な make install を使用します。Procmail を動作させるために必要なのは、procmail バイナリーと ~/.procmailrc 構成ファイル (場合によっては、グローバルな /etc/procmailrc ファイル) だけです。

Procmail がインストールされているとしても、そもそもローカル・メール・システムが Procmail を使用するように設定されていなければなりません。Procmail でメールを処理するために従来使用されている方法は、.forward ファイルを使用する方法です。この方法は、今でもユーザー単位では有効に機能します。一般に、ユーザーは以下のような行が記載された ~/.forward ファイルを作成することになります。

|/usr/local/bin/procmail

この設定は、各着信メッセージを Procmail にパイプ接続します。しかしながら、Procmail を使用するのに、さらに便利で一般的な方法は、最初から MTA に Procmail と直接対話するように指示することです。Sendmail の場合で言うと、それには、sendmail.mc ファイルに以下の行を含めて、local_procmail 機能を使用可能にします。

FEATURE(`local_procmail', `/usr/bin/procmail', `procmail -Y -a $h -d $u')

使用可能になった Procmail には、特定のメッセージを扱う際に適用するルール一式が含まれる ~/.procmailrc ファイルが必要です。Procmail はデーモンではありません。むしろ、STDIN を介して e-メールを 1 つずつ受け取るテキスト処理ツールです。

~/.procmailrc に設定するルール

本質的に、Procmail は正規表現による一連のレシピに過ぎません。シェル・スクリプトで定義するのと同じように環境変数を定義することもできます。処理は順番に実行されますが、フラグを使用して、前の条件が満たされた場合 (A)、または満たされなかった場合 (E) にのみ、特定の条件を実行することも可能です。Procmail のレシピには、配信用のレシピもあれば、配信以外のレシピもあります。前者のレシピは、c フラグで明示的に処理を続けるように指定されていない限り、指定されたメッセージの配信が完了すると処理を終了します。レシピのなかでも最もよく使われるアクションは、メッセージを指定のメール・ボックスに保管することですが、メッセージを別のプログラムにパイプ接続したり、メッセージをアドレスのリストに記載されている宛先に転送したりすることもできます。

レシピは一般に、ロック (オプションで特定のロック・ファイルを指定することができます。それ以外の場合は、自動的にロックが行われます) とフラグで始まり、その後にルール、そして 1 つに限定されたアクションの順に続きます。以下はその一例です。

:0 [フラグ] [ : [ローカル・ロック・ファイル] ]
<条件の指定なし、または 1 つ以上の条件 (1 行あたり 1 つの条件)>
<1 つに限定されたアクションの行>

特に注目に値するのは、ヘッダーと突き合わせるための H フラグと、本文と突き合わせるための B フラグです。フラグが指定されない場合には、暗黙的に H フラグが指定されます。通常、パターンでは大/小文字の区別がありませんが、D フラグによって、大/小文字を区別した突き合わせにすることができます。

条件は * で始まり、この文字に続くすべては egrep 式です。条件が < または > で始まる場合は、メッセージのサイズが指定のバイト数より小さいかどうか、または大きいかどうかがチェックされます。$ 接頭辞を使用すると、シェル変数が代入されるようになります。

アクションとしてファイル名だけが指定されている場合、メッセージはそのメール・ボックスに保存されます。メッセージを削除するには、特殊な擬似ファイル /dev/null を使用します。パイプ文字 (|) は、メッセージを別のプログラムに渡します。メッセージが渡されるプログラムの一例としては、Procmail に提供されている、メールのダイジェスト分割ユーティリティーが挙げられます。感嘆符の接頭辞 (!) はアクションとしてメッセージを転送します (ただし、これによってルールの条件は無効になります)。いくつかの例を以下に記載します。

リスト 6. ~/.procmailrc ファイルのサンプル
:0:
* ^Subject:.*Digest                 # split digests and save parts
* ^From:.*foo-digest
|formail +1 -ds cat >>mailing_lists_mailbox

:0:
* !(To|Cc).*mertz@gnosis.cx         # my main account here
* !(To|Cc).*david.mertz@gmail.com   # I get mail from here
* !From.*gnosis\.cx                 # I trust gnosis not to spam
* !From.*list.*@                    # don't trash mailing lists
* !From.*good-buddy                 # sometimes Bcc's me mail
spam

:0:
* ^Subject.*[MY-LIST]               # redistribute MY-LIST messages
! member@example.com, member2@example.net, member3@example.edu

:0:
* ^Cc.*joe@somewhere.org            # save to both inbox and JOE mbox
{
   :0 c
   $DEFAULT

   :0
   JOE
}

NNTP ニュースの提供

InterNetNews の役割

NNTP は、特定のトピックに関心を持つユーザーにメッセージを「プル」配信するための便利なプロトコルです。数千種類ものトピックに関する「ニュース・グループ」からなる Usenet は、NNTP を使用してメッセージを配信しています。プル型プロトコルの NNTP サーバーは、分散サーバー・ネットワークから現在収集可能なメッセージを集め、サイト管理者が含めることを選んだニュース・グループだけを選択します。新しいメッセージが特定のニュース・グループに投稿されると、その新規メッセージは NNTP サーバーから、その特定のニュース・グループを関心の対象として購読しているインターネット上の他のすべてのサーバーに直接的に伝播されます。

エンド・ユーザーの観点からは、メーリング・リストはニュース・グループと非常によく似ているものに見えるかもしれません。メーリング・リストにしても、ニュース・グループにしても、ユーザーがメッセージを作成して投稿し、他のユーザーが書いたメッセージを読むことに変わりはありません。以前の Usenet とインターネットでは、メーリング・リストは、現在のニュース・グループが自動的に行っているように、ディスカッション・トピックを「スレッド」形式で表示することはできませんでした。けれども、ここ何年かの間で、メール・クライアントは素晴らしいことにメーリング・リスト内のディスカッションのスレッドを推測できるようになっています。

ニュース・グループとメーリング・リストとの主な違いは、それぞれが使用しているネットワーク・プロトコルにあります。メーリング・リストは、今でも中央のメール・サーバーを利用します。中央のメール・サーバーは特定のリストに宛てられたメッセージをすべて受け取り、関心を示している (自動的に承認された、あるいは人間が仲介する購読メカニズムによって承認された) すべてのユーザーに、e-メールという手段でメッセージを配信します。それとは対照的に、NNTP は中央のサーバーを利用せず、すべてのノードを互いに接続します。つまり、それぞれの NNTP サーバーが直接「近隣」の他のサーバーと通信するため、比較的素早くメッセージを全世界に届けられるというわけです。

INN (InterNetNews) は、1992年に初めて作成された NTTP サーバーで、その誕生以来、活発な保守が続けられています。このチュートリアルを作成している時点で、INN の最新バージョンは 2.4.1 です。INN のホーム・ページに、リリースとドキュメントが用意されています (「参考文献」のリンクを参照)。

INN をセットアップする

最新のソース・リリースを入手して解凍した後は、./configure; make; make install のシーケンスで簡単に INN をビルドすることができます。INN をビルドするには、Perl と yacc (または bison) がインストールされている必要があります。ビルドによって多数のファイルが作成され、そのほとんどは /usr/local/news/ ディレクトリーに配置されます (INN を以前にインストールしたことがなければ、このディレクトリーはまだ作成されていないはずです)。

innd デーモンを (ユーザー「news」として) 実行する前に、いくつかの構成ファイルを変更する必要があります。その変更内容の詳細については、このチュートリアルでは説明しませんが、注意が必要な全ファイルについて説明している「Installing and Running a Usenet News Server with INN and FreeBSD」というタイトルの詳しいチュートリアルにオンラインでアクセスすることができます (「参考文献」のリンクを参照)。アクセス権とクォータの問題の多くは make システムによって対処されますが、上記のチュートリアルで説明している構成をダブルチェックすることをお勧めします。

特に注意が必要なファイルは、クォータをセットアップする /usr/local/news/etc/storage.conf です。このファイルは、購読対象のニュース・グループと、各ニュース・グループで保守する履歴の範囲を制御します。クォータに達すると、特定のニュース・グループ (全体としての Usenet からではなく、ローカル・サーバー上のニュース・グループ) から古いメッセージがパージされます。例えば、storage.conf は以下のような内容になっています。

リスト 7. storage.conf 構成サンプル
   method cnfs {
      newsgroups: alt.binaries.*
      class: 1
      size: 0,1000000
      options: BINARIES
   }

   method cnfs {
      newsgroups: *
      class: 2
      size: 0,100000
      options: NOTBINRY
   }

class の値が、各ルールを評価する順序を指定します。

各種の構成ファイルの調整が完了したら、innd をデーモンとして実行するだけで (場合によっては、初期化スクリプトとして起動)、/usr/local/news/etc/innfeed.conf、/usr/local/news/etc/incoming.conf、および /usr/local/news/etc/newsfeeds によって構成されたアップストリーム・サーバーの監視が開始されます。

参考文献

学ぶために

製品や技術を入手するために

  • Majordomo サイトで、Majordomo のダウンロードおよび情報を調べてください。
  • procmail.org から、Procmail の最新バージョンをダウンロードしてください。
  • sendmail.org から、Sendmail の最新バージョンをダウンロードしてください。
  • InterNetNews の情報およびダウンロードを入手するには、INN ホーム・ページにアクセスしてください。
  • Linux での次期開発プロジェクトの構築に、developerWorks から直接ダウンロードできる IBM の試用版ソフトウェアをご利用ください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=811121
ArticleTitle=LPI 試験対策: メールとニュース
publish-date=04262012