sendmail プログラムでは、メールルーティングに必要な 3 つのメカニズムをサポートしています。 適切なメカニズムは、変更の種類によって決まります。
サーバーの変更
ドメイン全体の変更
単独のユーザーの変更
さらに、選択する再ルーティングメカニズムによって必要な管理レベルが異なります。次のオプションを考慮してください。
再ルーティングメカニズムの 1 つは別名です。
別名を使用すれば、使用するファイルの種類に基づいて、サーバー全体またはネームサービス全体をベースにしてアドレス名をマップできます。
以下に、ネームサービスの別名の長所と短所を示します。
ネームサービス別名ファイルを使用すれば、メール再ルーティングの変更を単一のソースで管理できます。ただし、ネームサービスの別名指定では、再ルーティングの変更を伝達する際に遅延が起こります。
通常、ネームサービスの管理は、特定のシステム管理者グループに制限されます。一般ユーザーは、このファイルを管理しません。
以下に、サーバー別名ファイルを使用する際の長所と短所を示します。
サーバー別名ファイルを使用すれば、指定されたサーバーの root になることができる任意のユーザーが再ルーティングを管理できます。
サーバー別名指定は、再ルーティングの変更を伝達する際の遅延はほとんどありません。
変更はローカルサーバーだけに影響します。ほとんどのメールが単一のサーバーに送信される場合は、影響が少なくなります。ただし、この変更を多くのメールサーバーに伝達する必要がある場合は、ネームサービスの別名指定を使用します。
一般ユーザーは、この変更を管理しません。
詳細は、この章の メール別名ファイルを参照してください。 作業マップについては、第 25 章「メールサービス (手順)」の メール別名ファイルの管理 (作業マップ) を参照してください。
次のメカニズムは、転送です。
このメカニズムでは、ユーザーがメールの再ルーティングを管理できます。ローカルユーザーは、受信メールを以下の対象に再ルーティングできます。
別のメールボックス
別のメールプログラム
別のメールホスト
このメカニズムは、.forward ファイルによってサポートされます。.forward ファイルの詳細は、この章の .forward ファイルを参照してください。作業マップについては、第 25 章「メールサービス (手順)」の .forward ファイルの管理 (作業マップ)を参照してください。
最後のメカニズムは、取り込みです。
このメカニズムでは、root アクセス権を持たないユーザーも別名リストを保守できます。このメカニズムを提供するには、root ユーザーは、サーバー上の別名ファイル内に適切なエントリを作成する必要があります。このエントリが作成されると、ユーザーは必要に応じてメールをルーティングし直すことができるようになります。取り込みの詳細は、この章の /etc/mail/aliases ファイルを参照してください。 作業マップについては、第 25 章「メールサービス (手順)」の メール別名ファイルの管理 (作業マップ)を参照してください。
図 26–3 は、sendmail がユーザー別名をどのように使用するかを示します。/usr/bin/mailx のようなメールを読み取るプログラムは、プログラム自身の別名を持つことができ、それらはメッセージが sendmail に達する前に展開されます。sendmail の別名は、ローカルファイル、NIS、NIS+ など、さまざまなネームサービスソースからのものでもかまいません。検索順序は nsswitch.conf ファイルによって決定されます。nsswitch.conf(4) のマニュアルページを参照してください。