sendmail とその再ルーティングメカニズム

sendmail プログラムでは、メールルーティングに必要な 3 つのメカニズムをサポートしています。 適切なメカニズムは、変更の種類によって決まります。

• サーバーの変更

• ドメイン全体の変更

• 単独のユーザーの変更

さらに、選択する再ルーティングメカニズムによって必要な管理レベルが異なります。次のオプションを考慮してください。

1. 再ルーティングメカニズムの 1 つは別名です。

   別名を使用すれば、使用するファイルの種類に基づいて、サーバー全体またはネームサービス全体をベースにしてアドレス名をマップできます。

   以下に、ネームサービスの別名の長所と短所を示します。

   • ネームサービス別名ファイルを使用すれば、メール再ルーティングの変更を単一のソースで管理できます。ただし、ネームサービスの別名指定では、再ルーティングの変更を伝達する際に遅延が起こります。

   • 通常、ネームサービスの管理は、特定のシステム管理者グループに制限されます。一般ユーザーは、このファイルを管理しません。

   以下に、サーバー別名ファイルを使用する際の長所と短所を示します。

   • サーバー別名ファイルを使用すれば、指定されたサーバーの root になることができる任意のユーザーが再ルーティングを管理できます。

   • サーバー別名指定は、再ルーティングの変更を伝達する際の遅延はほとんどありません。

   • 変更はローカルサーバーだけに影響します。ほとんどのメールが単一のサーバーに送信される場合は、影響が少なくなります。ただし、この変更を多くのメールサーバーに伝達する必要がある場合は、ネームサービスの別名指定を使用します。

   • 一般ユーザーは、この変更を管理しません。

   詳細は、この章の メール別名ファイルを参照してください。 作業マップについては、第 25 章「メールサービス (手順)」の メール別名ファイルの管理 (作業マップ) を参照してください。

2. 次のメカニズムは、転送です。

   このメカニズムでは、ユーザーがメールの再ルーティングを管理できます。ローカルユーザーは、受信メールを以下の対象に再ルーティングできます。

   • 別のメールボックス

   • 別のメールプログラム

   • 別のメールホスト

   このメカニズムは、.forward ファイルによってサポートされます。.forward ファイルの詳細は、この章の .forward ファイルを参照してください。作業マップについては、第 25 章「メールサービス (手順)」の .forward ファイルの管理 (作業マップ)を参照してください。

3. 最後のメカニズムは、取り込みです。

   このメカニズムでは、root アクセス権を持たないユーザーも別名リストを保守できます。このメカニズムを提供するには、root ユーザーは、サーバー上の別名ファイル内に適切なエントリを作成する必要があります。このエントリが作成されると、ユーザーは必要に応じてメールをルーティングし直すことができるようになります。取り込みの詳細は、この章の /etc/mail/aliases ファイルを参照してください。 作業マップについては、第 25 章「メールサービス (手順)」の メール別名ファイルの管理 (作業マップ)を参照してください。

図 26–3 は、sendmail がユーザー別名をどのように使用するかを示します。/usr/bin/mailx のようなメールを読み取るプログラムは、プログラム自身の別名を持つことができ、それらはメッセージが sendmail に達する前に展開されます。sendmail の別名は、ローカルファイル、NIS、NIS+ など、さまざまなネームサービスソースからのものでもかまいません。検索順序は nsswitch.conf ファイルによって決定されます。nsswitch.conf(4) のマニュアルページを参照してください。

図 26–3 sendmail が別名を使用する方法