第 35 章 メールサービスのリファレンス

sendmail プログラムは、構成ファイルを使用して「別名」変換と転送、ネットワークゲートウェイへの自動ルーティング、柔軟な構成を提供するメール転送エージェントです。Solaris オペレーティング環境では、ほとんどのサイトで使用できる標準構成ファイルが付属しています。第 34 章「メールサービスの設定と管理」では、標準のファイルを使用して電子メールシステムを設定する方法について説明しています。この章では、sendmail の汎用バージョンと Solaris バージョンのいくつかの相違点について説明します。

• 「Solaris sendmail の相違点」

• 「メールサービスの関連用語」

• 「メールサービスのプログラムとファイル」

• 「メールアドレス指定の動作」

• 「sendmail とネームサービスとの相互作用」

Solaris sendmail の相違点

この節では、sendmail の Solaris バージョンに組み込まれたいくつかの変更について、汎用 Berkeley バージョンと比較して説明します。

sendmail のコンパイル時に使用するフラグ

次に、Solaris 8 に添付されている sendmail のバージョンをコンパイルするときに使用するフラグを示します。構成に他のフラグが必要な場合は、そのソースをダウンロードし、バイナリにコンパイルし直してください。この処理については、http://www.sendmail.org に記載してあります。

sendmail の代替コマンド

Solaris リリースには、Berkley による汎用リリースで提供されているコマンドの同義語がすべて組み込まれているわけではありません。表 35-1 には、コマンドの別名のリストと それが Solaris リリースに組み込まれているかどうか、および sendmail を使用して同じ動作を生成する方法を示しています。

構成ファイルのバージョンの定義

sendmail の新版 (バージョン 8.9.3) には、sendmail.cf ファイルのバージョンを定義するための、新しい構成オプションがあります。このオプションを使用すれば、旧バージョンの構成ファイルをバージョン 8.9.3 の sendmail で使用できます。バージョンレベルには 0 から 8 の値を設定できます。また、ベンダーの定義もできます。Berkeley または Sun がベンダーとして選択できます。構成ファイルで V オプションが定義されていない場合は、V1/Sun がデフォルトの設定となります。ベンダーを定義せずに、バージョンレベルだけが設定されている場合は、Sun がデフォルトとして使用されます。表 35-2 に有効なオプションを示します。

メールサービスの関連用語

メールファイルとプログラムに加え、メールサービスを構築するには、その他多数の構成要素が必要です。次の節ではこれらの構成要素と、それらを説明するのに使用する用語の一部を定義します。

最初の節では、メール配信システムのソフトウェア部分を説明するのに使用する用語を定義します。その次の節では、メール構成におけるハードウェアシステムの機能について取り上げます。

メールサービスソフトウェアの関連用語

ここでは、メールシステムのソフトウェアの構成要素について説明します。サービスには次のものがあります。

• メールユーザーエージェント

• メール転送エージェント

• メール配信エージェント

それ以外のソフトウェアの構成要素には、ドメイン名、メールアドレス、メールボックス、そしてメールの別名があります。

メールユーザーエージェント

「メールユーザーエージェント」は、ユーザーと sendmail プログラムなどのメール転送エージェントとの間のインタフェースとして機能します。Solaris オペレーティング環境に搭載されているメールユーザーエージェントは、/usr/bin/mail、/usr/bin/mailx、$OPENWINHOME/bin/mailtool、および /usr/dt/bin/dtmail です。

メール転送エージェント

「メール転送エージェント」は、メールメッセージのルーティングとメールアドレスの解釈を行います。Solaris オペレーティング環境ソフトウェアの転送エージェントは sendmail です。転送エージェントは次の機能を実行します。

• メールユーザーエージェントからメッセージを受信する

• 宛先アドレスを認識する

• 適切な配信エージェントを選択してメールを配信する

• 他のメール転送エージェントからのメールを受信する

メール配信エージェント

「メール配信エージェント」は、メールの配信プロトコルを実行するプログラムです。Solaris オペレーティング環境に搭載されているメール配信エージェントについては以下に述べます。

• UUCP メール配信エージェントは uux を使用してメールを配信します。

• 標準の Solaris リリースでは mail.local である、ローカルメール配信エージェントを配信します。

メールプログラム

「メールプログラム」は sendmail 独自の用語です。メール配信エージェントはカスタマイズできます。メールプログラムは sendmail によって使用され、カスタマイズしたメール配信エージェントまたはメール転送エージェントの特定のインスタンスを指定します。

ネットワークのすべてのシステムの sendmail.cf ファイルには、1 つ以上のメールプログラムを指定する必要があります。

smtp メールプログラムは SMTP を使用してメッセージを転送します。SMTP はインターネットで使用される標準のメールプロトコルです。SMTP メールヘッダーは次のようになります。

To: paul@phoenix.stateu.edu
From: Iggy.Ignatz@eng.acme.com

同じドメインの 2 人のユーザー間でメールが送信されると、ヘッダーは次のようになります。

To: Irving.Who@eng.acme.com
From: Iggy.Ignatz@eng.acme.com

ドメイン外にメールを送信するとき、特にインターネット経由でメールボックスに送信する必要がある場合は、SMTP を使用してください。

uucp-old メールプログラムはメッセージの配信に uux を使用しますが、ヘッダーをドメイン形式のアドレスでフォーマットします。To: 行と Cc: 行は SMTP ヘッダーとほぼ同様にドメインによってフォーマットされます。uucp ヘッダーは次のようになります。

To: paul@phoenix.stateu.com
From: ignatz@eng.acme.com

ドメイン形式の名前を処理し、理解できるシステムへの UUCP メールには uucp-uudom を使用してください。また、発信者はドメイン形式の名前を処理し、インターネットからの返信を受信できるようにしておく必要があります。

uucp-old メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。これはオリジナルのメールプログラムの 1 つであり、ヘッダーは次のようになります。

To: edu!stateu!phoenix!paul
From: acme!ignatz

sendmail.cf ファイルにメールプログラム仕様を提供して、他のメール配信エージェントを定義できます。メールプログラムに関しては、/usr/lib/mail/README にも記載してあります。

ドメイン名

「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。電子メールのアドレスにもドメインが使用されています。電子メールのアドレスは、次のようなフォーマットになっています。

user@subdomain. ... .subdomain2.subdomain1.top-level-domain

アドレスの @ 記号より左の部分はローカルアドレスです。ローカルアドレスには次の情報が含まれます。

• 別のメールトランスポートを使用するルーティング (たとえば、bob::vmsvax@gateway または smallberries%mill.uucp@gateway )

• 別名 (たとえば、iggy.ignatz )

受信側のメールプログラムでアドレスのローカル部分を解釈する必要があります。

アドレスの @ 記号より右の部分は、ローカルアドレスが位置するドメインアドレスを示します。ドットはドメインアドレスの各部分を区切ります。ドメインは、組織、物理的なエリア、地理的な領域などを表します。

ドメインアドレスは大文字と小文字を区別しません。アドレスのドメイン部分で大文字、小文字、またはそれらを混用しても相違はありません。

ドメイン情報の順序は階層的です。つまり、アドレスがローカルであるほど @ 記号に近づきます。

サブドメインの数が多いほど、宛先に関して提供される情報が詳細になります。ファイルシステム階層におけるサブディレクトリがその上のディレクトリの中にあると解釈されるのと同様に、メールアドレス内の各サブドメインは、その右にあるドメインの中にあると解釈されます。

表 35-3 に米国における最上位のドメインを示します。

Donnalyn Frey および Rick Adams による『A Directory of Electronic Mail Addressing and Networks』(O'Reilly & Associates, Inc., 1993) には、国際的な最上位のドメインアドレスリストが載っており、定期的に更新されています。

メールの配信においては、名前空間のドメイン名とメールドメイン名は一致しないことがあります。しかし、DNS ドメイン名とメールドメイン名は同じでなければなりません。sendmail プログラムは、デフォルトでドメイン名から最初の構成要素を取り除き、メールドメイン名とします。たとえば、NIS+ ドメイン名が bldg5.eng.acme.com であれば、そのメールドメイン名は eng.acme.com となります。

メールドメインアドレスは大文字と小文字の区別をしませんが、名前空間のドメイン名は異なります。メールと名前空間のドメイン名を設定するときは、小文字を使用するのが最善です。

メールアドレス

「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。

ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。

ただし、複数のメールボックスと、複数のドメインを持つ複数のメールシステムを管理する場合、または外部に UUCP (またはその他の) メール接続がある場合は、メールアドレス指定はもっと複雑になります。メールアドレスには「経路依存型」と「経路非依存型」があり、2 つの混用も可能です。経路依存のアドレス指定は、古い仕様に基づいており、ほとんどの場合は必要なく、また望ましくありません。

経路に依存しないアドレス指定

経路に依存しないアドレス指定では、電子メールメッセージの発信者は、受信者の名前と最終の宛先アドレスを指定する必要があります。経路に依存しないアドレスは通常インターネットのような高速ネットワークで使用されます。さらに、新しい UUCP 接続はドメイン形式の名前を頻繁に使用します。経路に依存しないアドレスは次のようなフォーマットになります。

user@host.domain

UUCP 接続は次のアドレスフォーマットで使用できます。

host.domain!user

コンピュータのドメイン階層命名方式が普及したため、経路に依存しないアドレスがより一般的になってきました。実際、次に示すように、最も一般的な経路に依存しないアドレスはホスト名を省略し、電子メールメッセージの最終宛先の識別をドメインネームサービスにまかせています。

user@domain

ルートに依存しないアドレスでは、まず @ 記号を検索し、ドメイン階層を右 (最上位) から左 (@ 記号の右側にある最も固有なアドレス) へと読み取ります。

経路依存のアドレス指定

経路依存のアドレス指定では、電子メールメッセージの発信者が、ローカルアドレス (通常はユーザー名) とその最終の宛先、および最終の宛先に到達するためにメッセージが通らなければならない経路を指定する必要があります。経路依存のアドレスは、UUCP ネットワーク上では一般的に使用され、フォーマットは次のとおりです。

path!host!user

電子メールアドレスの一部に感嘆符がある場合は、常に経路のすべて (またはその一部) が発信者によって指定されています。経路依存のアドレスは常に左から右に読みます。

この場合、電子メールアドレスは、次のようになります。

venus!acme!sierra!ignatz

これは、ignatz というユーザーに送信されたメールは、venus というシステムにまず送られ、それに引き続いて、acme、sierra に転送されることを示しています (これはあくまでも実在する経路ではないので注意してください)。 4 つのメールハンドラのいずれかが機能しないときは、メッセージは遅れるか、配信できないとして戻されます。

uucp メールプログラムを通してメールが送信される場合、アドレス指定は経路依存に制限されません。uucp メールプログラムによっては、経路に依存しないアドレス指定も処理します。

メールボックス

「メールボックス」は、電子メールメッセージの最終宛先であるメールサーバー内のファイルです。メールボックスの名前は、ユーザー名、またはポストマスターのような特定の職務を持つ人にメールを届ける場所の名前でもかまいません。メールボックスは、ユーザーのローカルシステムかリモートのメールサーバーのいずれかの /var/mail/username ファイルにあります。ただし、いずれの場合でも、メールボックスはメールが配信されるシステム上にあります。

ユーザーエージェントがメールスプールからメールを取り出し、ローカルメールボックスに容易に格納できるように、メールは常にローカルファイルシステムに配信される必要があります。ユーザーのメールボックスの宛先として、NFS でマウントされたファイルシステムを使用しないでください。特にリモートサーバーから /var/mail ファイルシステムをマウントしているメールクライアントには、直接メールを送信しないでください。この場合ユーザー宛のメールは、クライアントのホスト名ではなく、メールサーバーにアドレス指定する必要があります。 NFS でマウントされたファイルシステムは、メールの配信と処理に問題を起こすことがあります。/var/mail を NFS でマウントしたクライアントは「リモートモード」となり、サーバーにメールの送信と受信を行うように要求を出します。

/etc/mail/aliases ファイルと NIS や NIS+ といったネームサービスは、電子メールのアドレスに別名を作成するメカニズムを持っているため、ユーザーは、ユーザーのメールボックスの正確なローカル名を知る必要はありません。

表 35-4 に、特殊な目的のメールボックスに対する共通の命名規則をいくつか示します。

バージョン 8 から、所有者別名が存在する場合には、グループ別名に送信されたメールの封筒の送信者は、所有者別名から拡張されたアドレスに変更されるようになりました。この変更によって、メールエラーは、送信者に返送されるのではなく、別名の所有者に送信されるようになりました。別名に送信したメールは、配信時に、別名の所有者から来たようにみえます。つまり、別名宛てではなく、直接返信が必要な場合には、ユーザーは自らを識別するように注意する必要があります。次の別名のフォーマットは、この変更に関連したいくつかの問題に対応します。

mygroup: :include:/pathname/mygroup.list
owner-mygroup: mygroup-request
mygroup-request: sandys, ignatz

この例では、mygroup の別名が、このグループの実際のメール別名です。owner-mygroup の別名は、エラーメッセージを受信します。mygroup-request の別名は、管理の要求に使用してください。この構造は、mygroup の別名に送信されたメールでは、封筒の送信者が mygroup-request に変更されることを意味します。

メールの別名

別名 (alias) とは、もう 1 つの別の名前を指します。電子メールでは、メールボックスの位置を割り当てたり、メールリストを定義したりするために別名を使用できます。

大きなサイトでは通常、メール別名は、メールボックスの位置を定義します。メール別名を作成するのは、企業で個人のアドレスの一部としてメールストップを設定するのと似ています。メールストップを提供しない場合は、メールは中央アドレスに配信されます。建物内のどこにメールを配信するかを決定するには、別の作業が必要となり、ミスの可能性が増えます。たとえば、同じ建物に Kevin Smith という名前の人が 2 人いる場合、どちらの Kevin も、別の Kevin 宛のメールを受け取る可能性が高くなります。

メールリストを作成するときは、なるべくドメインの位置に依存しないアドレスを使用してください。別名ファイルの移植性と柔軟性を高めるため、別名エントリをできる限り一般的でシステムに依存しない形式にしてください。たとえば、システム mars のドメイン eng.acme.com に ignatz というユーザー名がある場合、別名は ignatz@mars ではなく、ignatz@eng としてください。ユーザー ignatz がシステム名を変更しても、eng ドメインには存在し続ける場合、システム名の変更を反映するように別名ファイルを更新する必要はありません。

別名エントリを作成するときは、1 行ごとに 1 つの別名を入力します。ユーザーのシステム名を含むエントリは 1 つだけにしてください。たとえば、ユーザー ignatz には、次のエントリを作成できます。

ignatz: iggy.ignatz
iggyi: iggy.ignatz
iggy.ignatz: ignatz@mars

ローカル名やドメインに別名を作成できます。たとえば、システム mars にメールボックスがあり、ドメイン planets 内のユーザー fred の別名エントリでは、 NIS+ 別名テーブルに次のエントリを作成できます。

fred: fred@planets

ドメイン外のユーザーを含むメールリストを作成するときは、ユーザー名とドメイン名を持つ別名を作成してください。たとえば、システム privet のドメイン mgmt.acme.com に smallberries というユーザー名がある場合、別名は smallberries@mgmt.acme.com とします。

送信者の電子メールアドレスは、メールがユーザードメイン外に発信されるときは、完全に修飾されたドメイン名に自動的に変換されます。

別名ファイルの使用

NIS+ mail_aliases テーブル、NIS aliases マップ、または、ローカルの /etc/mail/aliases ファイルでグローバルに使用するメール別名を作成します。また、同じ別名ファイルを使用してメールリストを作成して管理することができます。

メールサービスの構成に応じて、NIS または NIS+ ネームサービスを使用して別名を管理し、グローバル aliases データベースを維持したり、ローカルの /etc/mail/aliases ファイルをすべて同時に更新することにより、別名を同一にできます。

また、ユーザー自身が別名を作成して使用できます。ユーザーは、別名をユーザーだけが使用できるようにローカル ‾/.mailrc ファイルで作成することも、誰でも使用できるようにローカル /etc/mail/aliases ファイルで作成することもできます。ユーザーは通常は、NIS または NIS+ 別名ファイルを作成または管理できません。

メール構成のハードウェア要素

メール構成では次の 3 つの要素が必要ですが、これらは同じシステムで組み合わせることも、別のシステムで提供することもできます。

• メールホスト

• メールサーバー (1 つ以上)

• メールクライアント

ユーザーがドメイン外のネットワークと通信をするためには、4 番目の要素であるメールゲートウェイを追加する必要があります。次の節では各ハードウェアコンポーネントについて説明しています。

メールホスト

「メールホスト」は、ネットワーク上でメインのメールマシンとして指定するマシンです。これはサイトにおいて、他のシステムでは配信できないメールを転送するためのマシンになります。hosts データベースにシステムをメールホストとして指定するには、ローカルの /etc/hosts ファイルか、ネームサービスのホストファイルで、IP アドレスの右に mailhost を追加します。メールホストシステムでは、main.cf ファイルもメール構成ファイルとして使用する必要があります。

メールホストとして適切なのは、ローカルエリアネットワーク上のシステムで、電話回線に PPP または UUCP リンクを設定するためのモデムがあるものです。またネットワークからインターネットのグローバルネットワークへのルーターとして構成されたシステムも適しています (PPP、UUCP、およびルーターの詳細は、第 21 章「PPP の概要」、第 25 章「UUCP の概要」、「ルーターの構成」を参照)。ローカルネットワーク上のシステムにモデムがない場合は、システムの 1 つをメールホストに指定してください。

サイトの中には、タイムシェアリング構成でネットワークに接続されていないスタンドアロンのマシンを使用するものがあります。つまり、スタンドアロンのマシンが、シリアルポートに接続された端末として機能する場合です。このような構成では、スタンドアロンのシステムを 1 つのシステムネットワークのメールホストとして扱うことで、電子メールを設定できます。

メールサーバー

「メールボックス」は単独のファイルで、特定ユーザー用の電子メールが含まれています。メールはユーザーのメールボックスが置かれている場所のシステム、つまりローカルマシンかリモートサーバーに配信されます。「メールサーバー」は、/var/mail ディレクトリにユーザーのメールボックスを保持しているいずれかのシステムになります。

メールサーバーはクライアントからすべてのメールをルーティングします。クライアントがメールを送信するときに、メールサーバーは配信のためそのメールを待ち行列に入れます。メールが待ち行列に入れられたら、ユーザーはこれらのメールメッセージを失わずに、クライアントをリブートしたり、電源を切ったりすることができます。受信者がクライアントからメールを受けとると、メッセージの「From」行のパスには、メールサーバー名が含まれます。受信者が応答すると、その応答はユーザーのメールボックスに送られます。メールサーバーとして適しているのは、ユーザーにホームディレクトリを提供するシステムか、定期的にバックアップされるシステムです。

メールサーバーがユーザーのローカルシステムでない場合は、構成内で NFS ソフトウェアを使用するユーザーは、/etc/vfstab ファイル (ルートアクセスがある場合) を使用するか、オートマウンタを使用して、/var/mail ディレクトリをマウントできます。NFS サポートが利用できない場合、ユーザーはサーバーにログインしてメールを読み込めます。

ネットワーク上のユーザーが、PostScript ファイル、オーディオファイル、DTP システムからのファイルなど他の形式のファイルを送信する場合は、メールボックスのメールサーバーには、さらに多くの領域を割り当てる必要があります。

全メールボックス用に 1 台のメールサーバーを設定する利点の一つは、バックアップが簡単になることです。数多くのシステムにメールを分散すると、バックアップが難しくなります。 1 つのサーバーに多くのメールボックスを格納する際の欠点は、そのサーバーの故障が多くのユーザーに影響することですが、バックアップの簡便さは、この危険性を補って余りあります。

メールクライアント

「メールクライアント」は、メールサーバーでメールを受信し、ローカルの /var/mail のないシステムです。これはリモートモードとして知られています。リモートモードは、デフォルトでは /etc/mail/subsidiary.cf で使用することができます。

メールクライアントには、/etc/vfstab ファイルに適切なエントリがあり、メールサーバーからメールボックスをマウントするマウント先があることを確認する必要があります。またクライアントの別名の宛先が、クライアントではなく、メールサーバーのホスト名になっていることを確認してください。

メールゲートウェイ

「メールゲートウェイ」は、異なる通信プロトコルを実行するネットワーク間の接続を処理したり、同じプロトコルを使用する異なるネットワーク間の通信を処理したりするマシンです。たとえば、メールゲートウェイでは、Systems Network Architecture (SNA) プロトコルセットを実行するネットワークに、TCP/IP ネットワークを接続する場合もあります。

設定の最も簡単なメールゲートウェイは、同じプロトコルかメールプログラムを使用する 2 つのネットワークを接続するものです。このシステムでは、sendmail がドメインで受信者を見つけられないアドレスのあるメールを処理します。メールゲートウェイがある場合、sendmail はこれを使用して、ドメイン外でメールの送受信を行います。

2 つのネットワーク間には、図 35-1 に示すように内容の異なるメールプログラムを使用してメールゲートウェイを設定できます。これをサポートするには、メールゲートウェイシステムで sendmail.cf ファイルをカスタマイズする必要がありますが、これは困難で時間のかかる作業になる場合もあります。

図 35-1 異なる通信プロトコル間のゲートウェイ

メールゲートウェイを設定する場合に、必要とするものに最も近いゲートウェイ構成ファイルを見つけ、状況に合わせて修正する必要があります。

インターネットに接続できるマシンがある場合は、そのマシンをメールゲートウェイとして構成できます。メールゲートウェイを構成するときは、まずサイトのセキュリティ要件を慎重に考慮する必要があります。社内ネットワークを外部と接続するには、ファイアウォールゲートウェイを構築し、メールゲートウェイとして設定する必要がある場合があります。

メールサービスのプログラムとファイル

メールサービスには、相互に対応する数多くのプログラムやデーモンが含まれています。この節では、電子メールの管理に関するプログラムや用語、あるいは概念について述べます。表 35-5 には、メールサービスに使用する /usr/bin ディレクトリの内容を示します。

表 35-6 に、/etc/mail ディレクトリの内容を示します。

表 35-7 にメールサービスに使用する /usr/lib ディレクトリの内容を示します。

/usr/lib ディレクトリ内は、sendmail.cf ファイルの構築に必要なファイルをすべて含むサブディレクトリです。このディレクトリの内容は、表 35-8 に示すとおりです。

メールサービスは、その他のいくつかのファイルおよびディレクトリを使用します。これらを表 35-9 に示します。

これらのプログラムの組み合わせによるメールサービスが提供されていますが、その相互作用を図 35-2 に簡略に示します。

図 35-2 メールプログラムの相互作用

ユーザーは、mailx や mailtool などのプログラムを使用してメッセージを送信します。これらのプログラムについては、mailx(1) または mailtool(1) のマニュアルページを参照してください。

メッセージは、メッセージを生成するのに使用されたプログラムにより収集され、sendmail デーモンに渡されます。sendmail デーモンは、メッセージのアドレスを「解釈」し (識別可能なセグメントに分割)、構成ファイル /etc/mail/sendmail.cf からの情報を使用して、ネットワークの名前構文、別名、転送情報、およびネットワークトポロジを決定します。sendmail はこの情報を使用して、メッセージが受信者に到達する経路を決定します。

sendmail デーモンはメッセージを適切なシステムに渡します。ローカルシステムの /usr/lib/mail.local プログラムは、メッセージの受信者の /var/mail/username ディレクトリのメールボックスにメールを配信します。

受信者は、メールが届いたことが通知されるので、mail、mailx、mailtool などのプログラムを使用してこれを受け取ります。

sendmail プログラム

sendmail プログラムは、TCP/IP や UUCP などの異なる通信プロトコルを使用できます。また SMTP サーバー、メッセージキュー、メーリングリストも実装します。名前の解釈は、ドメインベースのネーミングとその環境で指定されている規則の両方を処理できるパターンマッチングシステムで制御されます。

sendmail プログラムは、ドメインベースのネーミングと任意の (古い) 名前構文を受け入れて、指定されている補完方法を使用して曖昧さを解決します。sendmail は共通点のないネーミングスキーマ間でメッセージを変換することもできます。ドメインの手法は、物理的なネーミング対論理的なネーミングの問題を分離します。インターネットドメインのネーミングの規則の詳細は、「ドメイン名」を参照してください。

他のネットワーク上のホストに対してローカルのように見えるネットワーク名を提供するなど、その環境で指定されている技法によって特殊な場合を処理できます。

Solaris オペレーティング環境では、sendmail プログラムをメールルーターとして使用します。sendmail は、電子メールメッセージの受信と配信を担当します。これは、mail、mailx、mailtool といったメール読み取りプログラムと、uucp のようなメールトランスポートプログラムの間のインタフェースです。sendmail プログラムは、ユーザーが送った電子メールメッセージを制御し、受信者のアドレスを判断し、適切な配信プログラムを選び、配信エージェントが処理できるフォーマットにアドレスを書き直し、必要に応じてメールヘッダーをフォーマットし直し、最後に変換したメッセージを配信のためのメールプログラムに渡します。

Solaris 2.4 以前の旧リリース版には、sendmail.mx と呼ばれるバイナリが含まれていました。現在このプログラムは sendmail プログラムに含まれており、これを有効にするには、/etc/nsswitch.conf のホストエントリに dns フラグを追加します。詳細は、「sendmail で DNS を使用する方法」 を参照してください。

sendmail プログラムでは、メールルーティングに必要な 3 つのメカニズムをサポートしています。どのメカニズムを選択するかは、サーバーまたはドメイン全体の変更なのか、または単に 1 人のユーザーの変更であるかによって決まります。また、異なる再ルーティングメカニズムを選択することにより、必要な管理レベルに変更できます。

1 つ目の再ルーティングメカニズムはエイリアシングです。エイリアシングとは、使用するファイルのタイプに基づいて、サーバー全体、または名前空間全域ごとに名前をアドレスに対応させるメカニズムです。名前空間の別名ファイルを使用すると、メール再ルーティングの変更を単一のソースで管理できますが、この変更が伝達されるときに、遅延時間が発生する可能性があります。また、名前空間管理は、通常、システム管理者の選択グループに限定されるため、一般ユーザーが実行できる変更ではありません。サーバーの別名ファイルを通じて処理された再ルーティングは、そのサーバーのスーパーユーザーによって管理されます。通常、この変更の伝達に関連した遅延時間はほとんどみられませんが、この変更はローカルサーバーにしか反映されません。この制約事項は、メールのほとんどが 1 つのサーバーに送信される場合には問題ありませんが、この変更を多数のメールサーバーに配信する場合には、ネームサービスを使用した方が簡単です。これも一般ユーザーが実行できる変更ではありません。

次のメカニズムは、転送と取り込みです。このメカニズムを使用すると、ユーザーはメールの再ルーティングを実行できます。転送を使用すると、ローカルユーザーは、着信メールを他のメールボックス、別のメールプログラム、あるいは他のメールホストにルーティングし直すことができます。このメール再ルーティングの形式は、.forward ファイルを使用することによりサポートされます。これらのファイルの詳細は、「.forward ファイル」を参照してください。

最後の再ルーティングメカニズムは取り込みで、これを使用すると、別名リストを、ルートアクセスを要求する代わりに、ユーザーによって保守できます。このメカニズムを提供するには、スーパーユーザーは、サーバー上の別名ファイル内に適切なエントリを作成する必要があります。このエントリが作成されると、ユーザーは必要に応じてメールをルーティングし直すことができるようになります。取り込みの詳細は、「/etc/mail/aliases」を参照してください。

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

図 35-3 sendmail が別名を使用する方法

sendmail プログラムの機能

sendmail プログラムには、次のような機能があります。

• sendmail には高い信頼性があります。すべてのメッセージを正しく配信するように設計されています。どんなメッセージも完全に失われることはありません。

• sendmail は、既存のソフトウェアを配信に随時使用します。

• sendmail は、1 つのネットワークタイプ (UUCP や Ethernet など) に複数の接続を行う場合なども含め、複雑な環境を処理するように構成できます。sendmail は、名前とその構文を確認し、どのメールプログラムを使用するかを判断します。

• 構成情報をコードにコンパイルする代わりに、構成ファイルを使用してメール構成を制御します。

• ユーザーは独自のメーリングリストを管理できます。各ユーザーは、ドメイン全体で有効な別名ファイル (通常、NIS または NIS+ によって管理されるドメイン全体の別名の中にある) を修正することなく自分自身のメール転送を指定できます。

• 各ユーザーはカスタムメールプログラムを指定して着信メールを処理することができます。こうすると、たとえば、「I am on vacation」というメッセージを返すといった機能を設定できます。 vacation(1) のマニュアルページを参照してください。

• 1 つのホストでアドレスを処理し、ネットワークトラフィックを削減します。

図 35-4 には、sendmail がメールシステムで他のプログラムと対話する方法を示します。

図 35-4 sendmail と他のメールプログラムとの相互作用

ユーザーは、メール生成プログラムおよび送信プログラムと対話します。メール送信が依頼されると、メール生成プログラムは sendmail を呼び出し、sendmail は適切なメールプログラムにメッセージを送ります。発信者の一部はネットワークサーバーであったり、またメールプログラムの一部はネットワーククライアントであるため、sendmail は、インターネットメールゲートウェイとしても使用できます。

sendmail 構成ファイル

「構成ファイル」は、sendmail がその機能を実行する方法を制御します。構成ファイルにより、配信エージェント、アドレスの変換の規則、およびメールヘッダーのフォーマットが選択されます。

sendmail プログラムは、/etc/mail/sendmail.cf ファイルの情報を使用して、その機能を実行します。各システムには、/etc/mail ディレクトリにインストールされたデフォルトの sendmail.cf ファイルがあります。メールサーバーまたはメールクライアントのためにデフォルト構成ファイルを編集または変更する必要はありません。カスタマイズされた構成ファイルを必要とするシステムは、メールホストとメールゲートウェイだけです。

Solaris オペレーティング環境には、以下に示すように、/etc/mail ディレクトリに 2 つのデフォルト構成ファイルがあります。

1. メールホストまたはメールゲートウェイとして使用する 1 つのシステム (または複数のシステム) を指定するための main.cf という名前の構成ファイル

2. subsidiary.cf という名前の構成ファイル (デフォルト sendmail.cf ファイルの複製コピー)

システムで使用する構成ファイルは、システムがメールサービスで果たす役割によって異なります。

• メールクライアントまたはメールサーバーについては、デフォルト構成ファイルを設定または編集する必要はありません。

• メールホストやゲートウェイを設定するには、main.cf ファイルをコピーし、それを (/etc/mail ディレクトリで) sendmail.cf と名称変更します。次に、sendmail.cf ファイルを再構成して、リレーメールプログラムを設定して、メール設定に必要なホストパラメータをリレーします。

次に、サイトの要求に応じて変更が可能な構成パラメータをいくつか説明します。

• 時間値の指定

  • 読み取りのタイムアウトを指定します。

  • メッセージが待ち行列内にあり送信者に戻されるまでの未配信状態の時間を指定します。

• 配信 (delivery) モードは、メールが配信される速さを指定します。

• 長いメッセージ、多くの受信者へのメッセージ、および長時間ダウンしているサイトへのメッセージを配信しないことにより、ロードを制限してロード時間内の無駄を省きます。

• ログレベルは、どのような種類の問題をログするかを指定します。

メール別名ファイル

下記の任意のファイルを使用して、別名を管理できます。使用するファイルのタイプは、別名を使用する人と別名を変更する必要がある人によって決まります。別名ファイルのタイプにはそれぞれ固有の形式要件があります。これについては、以下で定義します。

.mailrc の別名

.mailrc ファイルのリストに入っている別名には、ファイルを所有するユーザーだけしかアクセスできません。これにより、ユーザーは自分で制御し、所有者だけが使用できる別名を作成できます。.mailrc ファイルの別名は、次のようになります。

alias aliasname value value value ...

aliasname は、ユーザーがメールの送信時に使用する名前であり、value は有効な電子メールアドレスです。

ユーザーが scott に個人的な別名を作成し、それが名前空間の scott の電子メールアドレスと一致しない場合、そのユーザーが作成したメールに他のユーザーが返信しようとするときに、メールが間違ったユーザーに転送されることになります。これを回避するには、別の別名命名方式を使用する以外にありません。

/etc/mail/aliases

/etc/mail/aliases ファイルで作成したいずれの別名も、その別名の名前とファイルを含んでいるシステムのホスト名を知っているユーザーなら誰でも使用できます。ローカルの /etc/mail/aliases ファイルの配布リストは、以下のようになります。

aliasname: value,value,value...

aliasname は、ユーザーがこの別名にメールを送信するときに使用する名前で、value は有効な電子メールアドレスになります。

ご使用のネットワークがネームサービスを実行していない場合は、各システムの /etc/mail/aliases ファイルにすべてのメールクライアントのエントリを入れておく必要があります。各システムのファイルを編集するか、1 つのシステムのファイルを編集してからそのファイルを他のシステムに個々にコピーします。

/etc/mail/aliases ファイルの別名は、テキスト形式で保存されます。/etc/mail/aliases ファイルを編集するときに、newaliases プログラムを実行してデータベースを再コンパイルし、sendmail プログラムでその別名がバイナリ形式で使用できるようにします。あるいは Administration Tool の Database Manager を使用して、ローカルの /etc ファイルに保存されているメール別名を管理できます。

エイリアスを作ることができるのは、ローカル名、つまり現在のホスト名に対してのみ、またはホスト名は指定できません。たとえば、システム saturn 上にメールボックスを持っているユーザー ignatz に対するエイリアスエントリは、下記エントリを /etc/mail/aliases ファイル内に持っています。

ignatz: ignatz@saturn

各メールサーバー上で管理用アカウントを作ると便利です。このアカウントを作成する場合は、メールサーバー上にメールボックスのルートを割り当て、ルートについての /etc/mail/aliases ファイルにエントリを追加します。たとえば、システム saturn がメールボックスサーバーの場合は、エントリ root: sysadmin@saturn を /etc/mail/aliases ファイルに追加します。

通常、このファイルを編集できるのはスーパーユーザーだけです。admintool を使用する場合は、sysadmin グループであるグループ 14 のすべてのユーザーが、ローカルファイルを変更できます。別のオプションとしては、以下のようなエントリが作成できます。

aliasname: :include:/path/aliasfile

aliasname は、ユーザーがメールを送信するときに使用する名前であり、/path/aliasfile は別名リストを含むファイルへの完全なパスになります。別名ファイルには、各行に 1 つの電子メールエントリを入れ、その他の表記は付けないでください。

user1@host1
user2@host2

/etc/mail/aliases に追加のメールファイルを定義して、ログやバックアップコピーの管理もできます。以下のエントリでは、filename の aliasname に送信されるすべてのメールを格納します。

aliasname: /home/backup/filename

また、メールを他のプロセスにルーティングすることもできます。次のように入力すると、メールメッセージのコピーが filename 内に格納され、コピーが出力されます。

aliasname: "|tee -a /home/backup/filename |lp"

NIS 別名マップ

NIS 別名マップに含まれているエントリは、ローカルドメインのすべてのユーザーが利用できます。sendmail プログラムは、ローカルの /etc/mail/aliases ファイルの代わりに NIS 別名マップを使用して、メールアドレスを決定できます。詳細は、nsswitch.conf(4) のマニュアルページを参照してください。

NIS 別名 マップの別名は、以下のようになります。

aliasname: value,value,value...

aliasname は、ユーザーがメールを送信するときに使用する名前であり、value は有効な電子メールアドレスです。

NIS 別名マップには、すべてのメールクライアント用のエントリを含めてください。一般にこれらのエントリを変更できるのは、NIS マスターのスーパーユーザーだけです。このタイプの別名は、頻繁に変更される別名としては適していないかもしれませんが、次の構文例のように、別名が他の別名ファイルを指している場合は便利です。

aliasname: aliasname@host

aliasname はユーザーがメールを送信するときに使用する名前であり、host は /etc/mail/alias ファイルを含むサーバー用のホスト名です。

NIS+ mail_aliases テーブル

NIS+ mail_aliases テーブルには名前が含まれていて、それによってローカルドメインにおけるシステムや個人が登録されています。sendmail プログラムは、ローカルの /etc/mail/aliases ファイルの代わりに NIS+ mail_aliases テーブルを使用して、メールアドレスを決定できます。詳細は、aliasadm(1M) と nsswitch.conf(4) のマニュアルページを参照してください。

NIS+ mail_aliases テーブルの別名は次のようになります。

alias:			expansion					[options		# "comments"]

表 35-10 に 4 つの列を記載します。

NIS+ mail_aliases テーブルには、すべてのメールクライアントのエントリを含めてください。NIS+ aliases テーブルでは、aliasadm コマンドで、エントリの表示、作成、変更、および削除ができます。あるいは admintool の Database Manager を使用して、NIS+ メール別名を管理できます。

新規の NIS+ 別名テーブルを作成する場合は、エントリを作成する前にテーブルを初期設定する必要があります。テーブルが存在するときは、初期設定は不要です。

aliasadm コマンドを使用するには、別名テーブルを所有する NIS+ グループのメンバーか、テーブルを作成したユーザーでなければなりません。

.forward ファイル

ユーザーは、システム管理者の手を借りることなくプログラムのカスタムセットにメールをリダイレクトまたは送信するために、ホームディレクトリに、sendmail が使用する .forward ファイルを作成できます。メールの問題、特に所定のアドレスに配信されないメールに関する問題の解決の際、ユーザーのホームディレクトリに .forward ファイルがあるかどうかを常に確認してください。

よくある間違いは、host1 上のホームディレクトリの .forward ファイルに、user@host2 にメールを転送する設定を入れてしまうことです。メールが host2 に送られると、sendmail は NIS や NIS+ 別名で user を検索し、user@host1 にメッセージを送り返すので、ループが発生し、メールは返送されてしまいます。

root および bin アカウントは、.forward ファイルを所有できません。.forward ファイルを作成すると、セキュリティ上の問題が生じます。必要な場合には、代わりに別名ファイルを使用してメールを転送してください。

メールの配信中に .forward ファイルを調べるためには、このファイルを、ファイルの所有者によってのみ書き込み可能な状態にしておく必要があります。これにより、他のユーザーによるファイルへのアクセスを防ぎます。また、ホームディレクトリのパスは、root だけが所有し、書き込める状態にしておく必要があります。特に、.forward ファイルが /export/home/terry 内にある場合には、/export と /export/home は root だけが所有し、書き込める状態にしておかなければなりません。また実際のホームディレクトリに書き込めるのは、そのユーザーだけである必要があります。.forward ファイルにはこの他にも制約があります。このファイルはシンボリックリンクにすることはできず、また複数のハードリンクも実行できません。

標準の .forward ファイルに加えて、.forward.hostname ファイルを作成し、特定のホストに送信されたメールを転送できます。たとえば、ユーザーの別名を sandy@phoenix.eng.acme.com から sandy@eng.acme.com に変更した場合、sandy のホームディレクトリ内に .forward.phoenix ファイルがあると便利です。

% cat .forward.phoenix
sandy@eng.acme.com
"|/usr/bin/vacation sandy"
% cat .vacation.msg
From: sandy@eng.acme.com (via the vacation program)
Subject: my alias has changed

My alias has changed to sandy@eng.acme.com.
Please use this alias in the future.
The mail that I just received from you
has been forwarded to my new address.

Sandy

こうすることにより、メールを適切な場所に転送すると同時に、別名の変更を送信者に通知できます。vacation プログラムではメッセージファイルは 1 つしか使用できないため、この場合 1 回につき 1 つのメッセージしか実行できません。ただし、メッセージがホスト固有のものではない場合には、1 つの vacation メッセージファイルを、複数のホストの .forward ファイルで使用できます。

転送メカニズムの拡張機能にはこの他に、.forward+detail ファイルがあります。detail は、オペレータ文字以外の文字を自由に並べることができます。オペレータ文字とは、.:%&!^[]+ です。このようなファイルを使用すると、第三者によって自分の電子メールアドレスが使用されたかどうかを判別することが可能になります。たとえば、あるユーザーが、誰かに電子メールアドレス sandy+test1@eng.acme.com を使用するように指示した場合、ユーザーは、この別名に配信されるメールを、アドレスに送信されるメールの中から識別できます。デフォルトにより、sandy+test1@eng.acme.com の別名に送信されたメールはすべて、この別名と .forward+detail ファイルと突き合わせて検査されます。ここで一致しない場合は、そのメールは最終的に sandy@eng.acme.com に配信されますが、ユーザーは、これらのメールの To: ヘッダー内の変更箇所を調べることができます。

/etc/default/sendmail

このファイルは sendmail のための初期設定用オプションを保存し、ホストをアップグレードしたときに除去されないようにするために使用します。次の変数を使用することができます。

MODE=-bd

sendmail を起動するためのモードを選択します。-bd オプションを使用するか、未定義のままにしておきます。

QUEUEINTERVAL=#

実行するメールキューのための間隔を設定します。# は正の整数とし、その後に秒の場合は s、分の場合は m、時の場合は h、日の場合は d、週の場合は w を付けます。この構文は sendmail の起動前に確認されます。この間隔が負の場合、またはエントリの最後の文字が不適当な場合、この間隔は無視され、sendmail は 15 分のキュー間隔で起動します。

OPTIONS=string

sendmail コマンドで使用する追加のオプションを選択します。構文の確認は行われないため、この変数を変更するときは間違えないように注意してください。

メールアドレス指定の動作

配信時にメールメッセージが辿る経路は、クライアントシステムの設定とメールドメインのトポロジによって異なります。メールホストやメールドメインの各追加レベルでは、別名の解釈をさらに 1 回追加できますが、ルーティングプロセスは基本的にほとんどのホストで同じになります。

クライアントシステムを設定してメールをローカルで受信したり、リモートでクライアントシステムのためのメールを受信したりできます。メールをローカルで受信することは、ローカルモードでの sendmail の実行として知られています。すべてのメールサーバーと一部のクライアントでは、ローカルがデフォルトモードです。クライアントがサーバーから /var/mail をマウントしている場合、クライアントはリモートモードで sendmail を実行します。

sendmail.cf ファイルで設定したデフォルト規則を使用している場合の、電子メールメッセージが辿る経路を以下に示します。

リモートモードのメールクライアントでは、メールメッセージは以下のルーティングプロセスを経由して送信されます。

1. 可能な場合メール別名を展開し、ローカルのルーティングプロセスを再起動します。

   /etc/nsswitch.conf のエントリに応じて、名前空間でメール別名を検索し、新しい値が見つかった場合に置換することで、メールアドレスが展開されます。この新しい別名が次に再度確認されます。

2. アドレスを展開できない場合、メールサーバーに転送します。

   メールアドレスを展開できない場合、アドレスに問題があるか、アドレスがローカルでない可能性があります。どちらの場合も、メールサーバーで問題を解決する必要があります。

3. 展開した別名が元の宛先にループバックすると、メールはメールサーバーに転送されます。

   このプロセスでは検索のすべての履歴が維持され、元の別名が再生成されると、メールはメールサーバーに転送されて解釈が行われます。

ローカルモードのメールサーバーやメールクライアント上で、メールメッセージは以下のルーティングプロセスを経由して送信されます。

1. 可能な場合はメール別名を展開し、ローカルのルーティングプロセスを再起動します。

   名前空間でメール別名を検索し、見つかった場合に新しい値と置換することで、メールアドレスが展開されます。次にこの新しい別名が再度確認されます。

2. メールがローカルの場合、/usr/lib/mail.local に配信されます。

   メールはローカルのメールボックスに配信されます。

3. メールアドレスがこのメールドメインにホストを含んでいると、そのホストにメールを配信します。

4. アドレスがこのドメインにホストを含んでいない場合、メールホストにメールを転送します。

   メールホストはメールサーバーと同じルーティングプロセスを使用しますが、メールホストはホスト名に加え、ドメイン名が宛先になっているメールも受信できます。

sendmail とネームサービスとの相互作用

「メールドメイン」は、標準の sendmail.cf ファイルによって使用される概念で、メールを直接配信するか、またはメールホストによって配信するかを判断します。ドメイン内メールは直接 SMTP 接続経由で配信され、ドメイン間メールはメールホストに送られます。

セキュリティの高いネットワークでは、ほんの少数の選ばれたホストだけが、外部宛てのパケットを生成する権限を与えられています。ホストがメールドメイン外のリモートホストの IP アドレスを持っていても、これで SMTP 接続が確立できるとは限りません。標準の sendmail.cf では次のことを仮定しています。

• 現在のホストは、パケットを直接メールドメイン外のホストに送信する権限がない

• メールホストは、パケットを直接外部ホストに送信することが可能な認定ホストにメールを転送できる (実際には、メールホスト自身が認定ホストとなりうる)

このように仮定すると、ドメイン間メールの配信または転送はメールホスト側の責任です。

ネームサービスに対する sendmail 要件を設定する方法

sendmail は各種の要件をネームサービスに課します。次の節で、これらの要件とその要件を満たす方法を説明します。詳細は、in.named(1M)、nis+(1)、 nisaddent(1M)、および nsswitch.conf(4) のマニュアルページを参照してください。

ネームサービスによるメールドメイン名の設定

メールドメイン名はネームサービスドメイン名の接尾辞の 1 つでなければなりません。たとえば、ネームサービスのドメイン名が「A.B.C.D」ならば、メールドメイン名は次のうちのいずれかです。

• A.B.C.D

• B.C.D

• C.D

• D

メールドメイン名は、最初に設定されたときには、多くの場合ネームサービスドメインと同じになります。ネットワークが大きくなれば、ネームサービスドメインを小さく分割してネームサービスを管理しやすくすることができます。ただし、メールドメインは、一貫した別名を提供するために分割されないまま残ることがあります。

ホスト名前空間データ

ネームサービスにおけるホストテーブルまたはマップは、次の 3 種類の gethostbyname() による問い合わせをサポートするように設定しなければなりません。

• mailhost - いくつかのネームサービスの構成では、自動的にこの要件を満たします。

• 完全なホスト名 (たとえば、smith.admin.acme.com) - 多くのネームサービスの構成がこの要件を満たします。

• 短いホスト名 (たとえば、smith) - sendmail はメールホストに接続し、外部へのメールを転送します。メールアドレスが現在のメールドメイン内であるかどうかを判定するために、gethostbyname() が完全なホスト名で呼び出されます。エントリが見つかると、アドレスは内部にあるとみなされます。

  NIS、NIS+、および DNS はすべて、短いホスト名を引数にする gethostbyname() をサポートします。したがって、この要件は自動的に満たされます。

名前空間内で sendmail サービスを適切に確立するには、さらにホスト名空間に関する以下の 2 つのルールに従う必要があります。

1. 完全なホスト名による gethostbyname() と短いホスト名による gethostbyname() で、一致した結果を生じるようにします。たとえば、両関数がメールドメイン admin.acme.com から呼び出される限り、gethostbyname (smith.admin.acme.com) と gethostbyname (smith) は同じ結果になるようにします。

2. 共通のメールドメイン下のすべてのネームサービスドメインに対しては、短いホスト名による gethostbyname() で同じ結果を生じるようにします。たとえば、メールドメイン smith.admin.acme.com があるとして、gethostbyname(smith) は、ebb.admin.acme.com または esg.admin.acme.com のいずれのドメインから呼び出されても同じ結果になるようにします。主なメールドメイン名は通常ネームサービスドメインより短く、このために各種ネームサービスにとって特別な意味のあるものになっています。

NIS と sendmail を使用する場合の設定の問題点

ネームサービスとして NIS だけを使用するときは、sendmail 使用時に事前に解決しておかなければならない設定項目を以下に示します。

メールドメイン名 - NIS をプライマリネームサービスとして設定している場合に、sendmail は、自動的に NIS ドメイン名の最初の構成要素を取り除いた結果をメールドメイン名として使用します。たとえば、ebs.admin.acme.com は、admin.acme.com となります。




mailhost ホスト名 - NIS のホストマップには、mailhost エントリが必要になります。




完全なホスト名 - 通常の NIS の設定では、完全なホスト名は認識されません。NIS に完全なホスト名を認識させようとするよりは、sendmail.cf ファイルを編集し %l を %y で置き換えて、sendmail 側からこの要件をなくしてください。こうすることによって、sendmail のドメイン間のメール検出機能をオフにできます。ターゲットとするホストの IP アドレスを取得できれば、SMTP による直接配信が試みられます。NIS のホストマップに現在のメールドメインの外部のホストのエントリが含まれていないことを確認してください。もし、そのエントリがあれば、さらに sendmail.cf ファイルをカスタマイズする必要があります。




ホストの完全名および短縮名のマッチング - 前述した手順を参考にして、完全なホスト名による gethostbyname() をオフにしてください。




1 つのメールドメイン内の複数の NIS ドメイン - 共通のメールドメインの NIS のホストマップは、ホストのエントリは同じである必要があります。たとえば、ebs.admin.acme.com ドメインのホストマップは、esg.admin.acme.com のホストマップと同じものにします。異なる場合には、ある NIS ドメインで有効なアドレスが他の NISドメインでは無効になることがあります。

sendmail と同時に NIS と DNS を使用する場合の設定の問題

ネームサービスとして NIS と DNS を同時に使用する場合に、sendmail を使用する前に解決しておかなければならない設定上の問題を以下に示します。

メールドメイン名 - NIS をプライマリネームサービスとして設定している場合には、sendmail は、自動的に NIS ドメイン名の最初の構成要素を取り除いた結果をメールドメイン名として使用します。たとえば、ebs.admin.acme.com は、admin.acme.com となります。




mailhost ホスト名 - DNS の転送機能がオンになっていれば、NIS で解決できない照会は DNS に転送されるため、NIS ホストマップに mailhost エントリは必要ありません。




完全なホスト名 - NIS が完全なホスト名を認識できなくても、DNS が認識します。NIS と DNS の通常の設定手順を踏んでいる場合には、完全なホスト名の要件は満たされます。




ホストの完全名および短縮名のマッチング - NIS のホストテーブルにおけるすべてのホストエントリに対して、DNS にも対応するホストエントリが必要です。




1 つのメールドメイン内の複数の NIS ドメイン - 共通のメールドメインの NIS のホストマップ中のホストのエントリは同じである必要があります。たとえば、ebs.admin.acme.com ドメインのホストマップは、esg.admin.acme.com のホストマップと同じものにします。異なる場合には、ある NIS ドメインで有効なアドレスが他の NIS ドメインでは無効になることがあります。

NIS+ と sendmail を使用する場合の設定の問題点

使用するネームサービスが NIS+ だけの場合、sendmail を使用する前に解決しておかなければならない設定上の問題点を以下に記します。

メールドメイン名 - プライマリネームサービスとして、NIS+ を設定していれば、sendmail は、NIS+ の sendmailvars テーブル (キーと値から構成される 2 列の NIS+ テーブル) からメールドメインを検索します。メールドメインを設定するには、このテーブルにエントリを 1 つ追加する必要があります。このエントリは、キーの列に文字列 maildomain が、値の列には自分のドメイン名 (たとえば、admin.acme.com) が設定されている必要があります。NIS+ では、sendmailvars テーブルにどのような文字列でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomail エントリを sendmailvars テーブルに追加できます。たとえば、次のようになります。

nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

メールドメインは NIS+ ドメインの接尾辞となることに注意してください。




mailhost ホスト名 - NIS+ ホスト名には、mailhost エントリが必要です。




完全なホスト名 - NIS+ は、完全なホスト名を認識することができます。通常の NIS+ の設定手順を行えば、この完全なホスト名の要件は満たされます。




ホストの完全名および短縮名のマッチング - この要件を満たすには、すべてのホストテーブルでエントリをコピーするか、ユーザーネームサービスのドメイン中の全ホストのエントリをメールドメインレベルのマスターホストテーブルに入力する必要があります。




1 つのメールドメイン内の複数の NIS ドメイン - この項目を満たすには、すべてのホストテーブルのエントリをコピーするか、ユーザーネームサービスのドメイン中の全ホストのエントリをメールドメインレベルのマスターホストテーブルに入力する必要があります。これは、(論理的または物理的に) 複数のホストテーブルを 1 つのホストテーブルに結合することになるので、メールドメインを共有する複数のネームサービスドメインで同じホスト名を再使用することはできません。

sendmail と同時に NIS+ と DNS を使用する場合の設定の問題点

ネームサービスとして NIS+ と DNS を同時に使用する場合に、sendmail 使用前に解決しておかなければならない設定上の問題点を以下に記します。

メールドメイン名 - プライマリネームサービスとして、NIS+ を設定していれば、sendmail は、NIS+ の sendmailvars テーブル (キーと値から構成される 2 列の NIS+ テーブル) からメールドメインを検索します。メールドメインを設定するには、 1 つのエントリをこのテーブルに追加する必要があります。このエントリは、キーの列に文字列 maildomain が、値の列に自分のドメイン名 (たとえば、admin.acme.com) が設定されている必要があります。NIS+ では、sendmailvars テーブルに、どのような文字でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomail エントリを sendmailvars テーブルに追加できます。たとえば、次のようになります。

nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

メールドメインは NIS+ ドメインの接尾辞となることに注意してください。




mailhost ホスト名 - ネットワークがホストデータベースのソースとして NIS+ と DNS の両方を使用しているときは、mailhost エントリを NIS+ あるいは DNS ホストテーブルのいずれかに置くことができます。NIS+ と DNS をホストデータベースのソースとして /etc/nsswitch.conf ファイルで指定するようにしてください。




完全なホスト名 - NIS+ も DNS も完全なホスト名を認識します。通常の NIS+ と DNS の設定手順を踏めば、この項目の要件は満たされます。




ホストの完全名および短縮名のマッチング - NIS+ ホストテーブルの全ホストエントリに対して、対応するエントリが DNS に必要です。




1 つのメールドメイン内の複数の NIS ドメイン - この要件を満たすには、全ホストテーブルエントリをコピーするか、ネームサービスのドメイン中の全ホストのエントリをメールドメインレベルのマスターホストテーブルに入力する必要があります。