第 26 章 メールサービス (リファレンス)

sendmail プログラムは、構成ファイルを使用して「別名」変換と転送、ネットワークゲートウェイへの自動ルーティング、柔軟な構成を提供するメール転送エージェントです。Solaris オペレーティング環境では、ほとんどのサイトで使用できる標準構成ファイルが付属しています。第 24 章「メールサービス (概要)」では、メールサービスのコンポーネントと典型的なメールサービスの構成を紹介します。第 25 章「メールサービス (手順)」では、電子メールシステムをセットアップして管理する方法について説明します。この章では、以下のトピックについて説明します。

• Solaris 版の sendmail

• メールサービスのソフトウェアとハードウェアのコンポーネント

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

• メールアドレスとメールルーティング

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

この Solaris 9 の sendmail バージョン 8.12 に含まれる新しい機能については、第 27 章「メールサービスの新機能 (リファレンス)」を参照してください。 mail.local、mailstats、makemap に関する変更、および新しいメンテナンスユーティリティである editmap についてもお読みください。以上の章で説明されていない詳細については、sendmail(1M)、mail.local(1M)、mailstats(1)、makemap(1M)、および editmap(1M) のマニュアルページを参照してください。

Solaris 版の sendmail

ここでは、以下の項目について sendmail の Solaris 版と一般的な Berkeley バージョンを比較します。

• sendmail のコンパイルに使用できるフラグと使用できないフラグ

• sendmail の代替コマンド

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

sendmail のコンパイルに使用できるフラグと使用できないフラグ

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

次の表に、Solaris 9 に添付される sendmail のバージョンのコンパイルに使用されない一般的なフラグを示します。

sendmail のコンパイルに使用するフラグの一覧を参照するには、次のコマンドを使用します。

% /usr/lib/sendmail -bt -d0.10 < /dev/null

上記のコマンドでは、Sun 固有のフラグは表示されません。

sendmail の代替コマンド

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

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

Solaris 9 に含まれている sendmail の バージョンには、sendmail.cf ファイルのバージョンを定義するための構成オプションが含まれます。現在のバージョンの sendmail でも以前のバージョンの構成ファイルを使用できます。バージョンレベルには 0 から 10 の値を設定できます。また、ベンダーの定義もできます。Berkeley または Sun をベンダーとして選択できます。ベンダーを定義しないでバージョンレベルだけを設定した場合は、Sun がデフォルトとして使用されます。次の表に有効なオプションを示します。

V1/Sun は使用しないでください。詳細は、http://www.sendmail.org/vendor/sun/differences.html#4 を参照してください。

作業手順については、第 25 章「メールサービス (手順)」の sendmail.cf 構成ファイルの構築 (手順) を参照してください。

メールサービスのソフトウェアとハードウェアのコンポーネント

ここでは、メールシステムのソフトウェアとハードウェアの構成要素について説明します。

• ソフトウェアのコンポーネント

• ハードウェアコンポーネント

ソフトウェアのコンポーネント

各メールサービスには、少なくとも以下のどれかのソフトウェアコンポーネントが含まれます。

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

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

• ローカル配信エージェント

ここでは、以下のソフトウェアコンポーネントについても説明します。

• メールプログラム

• メールアドレス

• メールボックスファイル

• メール別名

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

メールユーザーエージェントは、ユーザーとメール転送エージェント間のインタフェースとして機能するプログラムです。sendmail プログラムは、メール転送エージェントです。Solaris のオペレーティング環境は、以下のメールユーザーエージェントを提供します。

• /usr/bin/mail

• /usr/bin/mailx

• $OPENWINHOME/bin/mailtool

• /usr/dt/bin/dtmail

メール転送エージェント

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

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

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

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

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

ローカル配信エージェント

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

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

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

第 27 章「メールサービスの新機能 (リファレンス)」では、以下の関連項目について説明します。

• 配信エージェントの新しいフラグ

• 配信エージェントの新しい等号 (=)

• mail.local の変更点

メールプログラム

「メールプログラム」は、sendmail 固有の用語です。メールプログラムは sendmail によって使用され、カスタマイズしたローカル配信エージェントまたはカスタマイズされたメール転送エージェントの特定のインスタンスを指定します。sendmail.cf ファイルに少なくとも 1 つのメールプログラムを指定する必要があります。作業手順については、第 25 章「メールサービス (手順)」の sendmail.cf 構成ファイルの構築 (手順) を参照してください。ここでは、2 種類のメールプログラムについて説明します。

• SMTP (Simple Mail Transfer Protocol) メールプログラム

• UUCP (UNIX-to-UNIX Copy Program) メールプログラム

メールプログラムの詳細については、http://www.sendmail.org/m4/readme.html または /usr/lib/mail/README を参照してください。

SMTP (Simple Mail Transfer Protocol) メールプログラム

SMTP はインターネットで使用される標準のメールプロトコルです。このプロトコルが、メールプログラムを定義します。

• smtp は、他のサーバーへの通常 (従来の形式) の SMTP 転送機能を提供します。

• esmtp は、他のサーバーへの拡張 SMTP 転送機能を提供します。

• smtp8 は、8 ビットデータを MIME に変更することなく、他のサーバーに SMTP 転送機能を提供します。

• dsmtp は、F=% メールプログラムフラグを使ってオンデマンド配信機能を提供します。第 27 章「メールサービスの新機能 (リファレンス)」の MAILER() の宣言についての変更点と 配信エージェントの新しいフラグを参照してください。

UUCP (UNIX-to-UNIX Copy Program) メールプログラム

UUCP の使用は、できるだけ避けてください。説明については、http://www.sendmail.org/m4/uucp.html を参照するか、/usr/lib/mail/README で「UUCP メールプログラムの使用」の文字列を検索してください。

UUCP が、メールプログラムを定義します。

uucp-old

$=U クラスの名前が uucp-old に送られます。 uucp は、このメールプログラムの以前の名前です。uucp-old メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。

uucp-new

$=Y クラスの名前が uucp-new に送られます。受信側の UUCP メールプログラムが単一の転送で複数の受信者を管理できる場合は、このメールプログラムを使用します。suucp は、このメールプログラムの以前の名前です。uucp-new メールプログラムはヘッダーで感嘆符を用いるアドレスも使用します。

構成に MAILER(smtp) も指定されている場合は、さらに以下の 2 つのメールプログラムが定義されます。

uucp-dom

このメールプログラムは、ドメインスタイルアドレスを使用し、基本的に SMTP のリライトルールを適用します。

uucp-uudom

$=Z クラスの名前が uucp-uudom に送られます。uucp-uudom と uucp-dom は、ドメインスタイルアドレスという同じヘッダーアドレスフォーマットを使用します。

smtp メールプログラムは UUCP メールプログラムを変更するので、.mc ファイルの MAILER(uucp) の前に必ず MAILER(smtp) を記述します。

メールアドレス

「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。メールボックスを含む複数のシステムで構成されるメールシステム、または 1 つ以上のドメインで構成されるメールシステムを管理する場合は複雑になります。UUCP またはその他のメールシステムによって外部に接続する場合は、さらに複雑になります。以下の節で、メールアドレスの各部とその複雑さを説明しています。

• ドメインとサブドメイン

• ネームサービスドメイン名とメールドメイン名

• メールアドレスの一般的な書式

• 経路に依存しないメールアドレス

ドメインとサブドメイン

電子メールのアドレス指定には、ドメインが使用されます。「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。ドメインは 1 つ以上のサブドメインを持つことができます。アドレスのドメインとサブドメインは、ファイルシステムの階層と比較できます。サブディレクトリが上位のディレクトリに含まれるように、メールアドレスの各サブドメインもその右のドメインに含まれると考えられます。

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

ドメインには大文字と小文字の区別がありません。アドレスのドメイン部分には、大文字、小文字、またはその両方を区別なく混合して使用できます。

ドメインについての詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「ドメインネームシステム (概要)」を参照してください。

ネームサービスドメイン名とメールドメイン名

ネームサービスドメイン名とメールドメイン名を操作するときは、以下のことに注意します。

• sendmail プログラムは、デフォルトで NIS または NIS+ ドメイン名から最初の構成要素を取り除き、メールドメイン名とします。たとえば、NIS+ ドメイン名が bldg5.example.com の場合、メールドメイン名は example.com になります。

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

• DNS ドメイン名とメールドメイン名は同じでなければなりません。

詳細は、sendmail とネームサービスの相互作用を参照してください。

メールアドレスの一般的な書式

一般に、メールアドレスは次のような書式になります。詳細は、経路に依存しないメールアドレスを参照してください。

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

アドレスの @ 記号より左の部分はローカルアドレスです。ローカルアドレスには、以下の内容を含めることができます。

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

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

受信側のメールプログラムでアドレスのローカル部分を解釈する必要があります。メールプログラムの詳細は、メールプログラムを参照してください。

アドレスの @ 記号より右の部分は、ローカルアドレスが位置するドメインレベルを示します。各サブドメインはドットで区切られます。アドレスのドメイン部分は、組織、物理的な場所、または地域を表すことができます。 さらに、ドメイン情報の順序は階層的で、ローカルなサブドメインほど @ 記号に近くなります。

経路に依存しないメールアドレス

メールアドレスは、経路に依存しないアドレス指定ができます。経路に依存しないアドレス指定では、電子メールメッセージの発信者は、受信者の名前と最終の宛先を指定する必要があります。インターネットなどの高速ネットワークでは、経路に依存しないアドレスを使用します。経路に依存しないアドレスは次のような書式になります。

user@host.domain

UUCP 接続の経路に依存しないアドレスは次のような書式になります。

host.domain!user

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

user@domain

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

メールボックスファイル

「メールボックス」は、電子メールメッセージの最終的な宛先となるファイルです。メールボックス名には、ユーザー名または postmaster などの特定の機能の名前を指定できます。メールボックスは、ユーザーのローカルシステムかリモートのメールサーバーのいずれかの /var/mail/username ファイルにあります。ただし、いずれの場合でも、メールボックスはメールが配信されるシステム上にあります。

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

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

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

sendmail バージョン 8 より、所有者の別名が存在する場合、グループの別名に送信されるメールの封筒の送信者は、所有者の別名から展開されるアドレスに変更されました。この変更によって、メールエラーは、送信者に返送されるのではなく、別名の所有者に送信されるようになりました。この変更によって、別名に送信されたメールは、別名の所有者から送信されたように見えます。次の別名の書式は、この変更に関連したいくつかの問題に対応します。

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

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

メール別名

別名 (alias) とは、もう 1 つの別の名前を指します。電子メールでは、メールボックスの場所を割り当てたり、メールリストを定義したりするために別名を使用できます。作業マップについては、第 25 章「メールサービス (手順)」の メール別名ファイルの管理 (作業マップ)を参照してください。この章の メール別名ファイルも参照してください。

大きなサイトでは通常、メール別名は、メールボックスの場所を定義します。メール別名を提供することは、複数の部屋を占有する大きな会社の個人のアドレスに部屋番号を含めるようなものです。部屋番号を提供しない場合は、メールは中央アドレスに配信されます。部屋番号がなければ、ビルの内部のどこにメールを配信するかを特定するために余分な労力が必要になり、誤りが発生する可能性も増加します。たとえば、同じ建物に Kevin Smith という名前の人が 2 人いる場合、一方だけがメールを受け取ることになる可能性があります。この問題を解決するには、それぞれの Kevin Smith のアドレスに部屋番号を追加する必要があります。

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

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

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

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

fred: fred@planets

ドメイン外のユーザーを含むメールリストを作成するときは、ユーザー名とドメイン名を持つ別名を作成してください。たとえば、example.com ドメインの privet システムに smallberries というユーザーが存在する場合は、smallberries@example.com という別名を作成します。送信者の電子メールアドレスは、メールがユーザードメイン外に発信されるときは、完全指定ドメイン名に自動的に変換されます。

以下に、メール別名のファイルを作成して管理する方法を示します。

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

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

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

ハードウェアコンポーネント

メールの構成に必要な 3 つの要素は、単一のシステムによって提供することも個別のシステムによって提供することもできます。

• メールホスト

• メールサーバー

• メールクライアント

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

メールホスト

「メールホスト」は、ネットワークのメインのメールマシンに指定するマシンです。メールホストはサイトにおいて、他のシステムでは配信できないメールを転送するためのマシンになります。hosts データベースにシステムをメールホストとして指定するには、ローカルの /etc/hosts ファイルか、ネームサービスのホストファイルで、IP アドレスの右に mailhost を追加します。メールホストシステムでは、main.cf ファイルもメール構成ファイルとして使用する必要があります。作業手順については、第 25 章「メールサービス (手順)」の メールホストを設定する方法を参照してください。

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

サイトの中には、タイムシェアリング構成でネットワークに接続されていないスタンドアロンのマシンを使用するものがあります。つまり、スタンドアロンのマシンが、シリアルポートに接続された端末として機能する場合です。このような構成では、スタンドアロンのシステムを 1 つのシステムネットワークのメールホストに指定することで、電子メールを設定できます。第 24 章「メールサービス (概要)」の ハードウェアコンポーネントの概要に、典型的な電子メール構成を示す図があります。

メールサーバー

「メールボックス」は、特定のユーザーの電子メールを含む単一のファイルです。メールは、ローカルマシンまたはリモートサーバーのユーザーのメールボックスが存在するシステムに配信されます。「メールサーバー」は、/var/mail ディレクトリにユーザーのメールボックスを保持しているいずれかのシステムになります。作業手順については、第 25 章「メールサービス (手順)」の メールサーバーを設定する方法を参照してください。

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

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

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

全メールボックス用に 1 台のメールサーバーを設定する利点の 1 つは、バックアップが簡単になることです。メールが多くのシステムに分散しているとバックアップ作業が困難になる場合があります。1 台のサーバーに多くのメールボックスを保存する場合の短所は、サーバーに障害が発生した場合に多くのユーザーが影響を受けることです。ただし、十分なバックアップ機能を提供すれば、1 台のサーバーを採用する価値があります。

メールクライアント

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

メールクライアントには、/etc/vfstab ファイルに適切なエントリがあり、メールサーバーからメールボックスをマウントするマウント先があることを確認する必要があります。またクライアントの別名の宛先が、クライアント名ではなく、メールサーバーのホスト名になっていることを確認してください。作業手順については、第 25 章「メールサービス (手順)」の メールクライアントを設定する方法を参照してください。

メールゲートウェイ

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

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

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

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

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

インターネットに接続できるマシンがある場合は、そのマシンをメールゲートウェイとして構成できます。メールゲートウェイを構成するときは、まずサイトのセキュリティ要件を慎重に考慮する必要があります。社内ネットワークを外部と接続するには、ファイアウォールゲートウェイを構築し、それをメールゲートウェイとして設定する必要がある場合があります。作業手順については、第 25 章「メールサービス (手順)」の メールゲートウェイを設定する方法を参照してください。

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

メールサービスには、相互に対応する数多くのプログラムやデーモンが含まれています。ここでは、電子メールの管理に関連するファイル、プログラム、用語、および概念について説明します。

• /usr/bin ディレクトリの内容

• /etc/mail ディレクトリの内容

• /usr/lib ディレクトリの内容

• メールサービスに使用するその他のファイル

• メールプログラム間の相互作用

• sendmail プログラム

• メール別名ファイル

• .forward ファイル

• /etc/default/sendmail ファイル

/usr/bin ディレクトリの内容

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

/etc/mail ディレクトリの内容

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

/usr/lib ディレクトリの内容

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

/usr/lib/mail ディレクトリの内容

/usr/lib ディレクトリには、sendmail.cf ファイルを構築するために必要なすべてのファイルを含む mail というサブディレクトリがあります。表 26–10 に mail ディレクトリの内容を示します。

メールサービスに使用するその他のファイル

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

メールプログラム間の相互作用

メールサービスは以下のプログラムで構成され、図 26–2 のように作用します。

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

さらに詳しい図については、sendmail プログラムの機能 を参照してください。

以下に、メールプログラムの相互作用について説明します。

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

2. メッセージは、メッセージを生成したプログラムにより収集され、sendmail デーモンに渡されます。

3. sendmail デーモンがメッセージのアドレスを識別可能な各部に分割して解析します。sendmail デーモンは、/etc/mail/sendmail.cf という構成ファイルの情報を使ってネットワーク名の構文、別名、転送情報、およびネットワークトポロジを決定します。sendmail はこの情報を使用して、メッセージが受信者に到達する経路を決定します。

4. sendmail デーモンはメッセージを適切なシステムに渡します。

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

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

sendmail プログラム

以下に、 sendmail プログラムの機能の一部を示します。

• sendmail は、TCP/IP や UUCP などの異なる通信プロトコルを使用できます。

• sendmail は、SMTP サーバー、メッセージキュー、メーリングリストを実装します。

• sendmail は、以下の命名規則に準拠したパターンマッチングシステムを使って名前の解釈を制御します。

  • ドメインベースの命名規則ドメインの手法は、物理的なネーミング対論理的なネーミングの問題を分離します。詳細は、メールアドレスを参照してください。

  • 他のネットワークのホストからローカルに見えるネットワーク名を提供するなどの即席のテクニック

  • 任意 (以前) の命名構文

  • 異種の命名スキーム

Solaris オペレーティング環境では、sendmail プログラムをメールルーターとして使用します。以下に、機能の一部を示します。

• sendmail は、電子メールメッセージの受信と配信を担当します。

• sendmail は、mail、mailx、 mailtool などのメール読み出しプログラムと uucp などのメール転送プログラムとのインタフェースです。

• sendmail は、次の要領でユーザーが送信する電子メールメッセージを制御します。

  • 受信者のアドレスを確認します。

  • 適切な配信プログラムを選択します。

  • アドレスを配信エージェントが処理できるフォーマットに書き換えます。

  • 必要に応じて、メールヘッダーをフォーマットし直します。

  • 最後に転送されたメッセージをメール配信プログラムに渡します。

sendmail の詳細は、以下のトピックを参照してください。

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

• sendmail プログラムの機能

• sendmail 構成ファイル

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

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

• サーバーの変更

• ドメイン全体の変更

• 単独のユーザーの変更

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

1. 別名再ルーティングメカニズム

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

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

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

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

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

   • サーバー別名ファイルを使用すれば、指定されたサーバーの 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 が別名を使用する方法

sendmail プログラムの機能

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

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

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

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

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

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

• 各ユーザーは、受信メールを処理するカスタムメールプログラムを指定できるので、「I am on vacation. (私は休暇中です)」のようなメッセージを返すこともできます。詳細は、vacation(1) マニュアルページを参照してください。

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

図 26–4 には、sendmail がメールシステムで他のプログラムと相互作用する方法を示します。

図 26-4 sendmail と他のメールプログラムとの対話

図 26–4 に示すように、ユーザーはメール作成プログラムおよびメール送信プログラムと対話できます。メール送信が依頼されると、メール生成プログラムは sendmail を呼び出し、sendmail は適切なメールプログラムにメッセージを送信します。発信者の一部はネットワークサーバーであったり、またメールプログラムの一部はネットワーククライアントであるため、sendmail は、インターネットメールゲートウェイとしても使用できます。このプロセスの詳細は、メールプログラム間の相互作用を参照してください。

sendmail 構成ファイル

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

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

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

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

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

3. デーモンモードの代わりにメール送信プログラムモードで sendmail を実行するために使用する submit.cf という名前の構成ファイルの詳細は、新しい構成ファイル submit.cfを参照してください。

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

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

• メールホストやメールゲートウェイを設定するには、main.cf ファイルをコピーし、それを /etc/mail ディレクトリで sendmail.cf と名称変更します。次に、 sendmail の構成ファイルを再構成して、メールリレープログラムを設定して、メール設定に必要なホストパラメータをリレーします。 作業手順については、第 25 章「メールサービス (手順)」の メールサービスの設定 (作業マップ)または sendmail.cf 構成ファイルの構築 (手順) を参照してください。

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

• 以下の情報を指定する時間値

  • 読み取りのタイムアウト。Timeout オプションの変更点を参照してください。

  • メッセージが送信者に返送されるまで、配信されずにキューに置かれる時間。キューの新しい機能を参照してください。作業マップについては、キューディレクトリの管理 (作業マップ)を参照してください。

• メール配信の速度を指定する配信 (delivery) モード

• 長いメッセージ、多くの受信者へのメッセージ、および長時間ダウンしているサイトへのメッセージを配信しないことにより、ビジー期間中の効率を高めるためのロード制限

• ログ出力する問題の種類を指定するログレベル

メール別名ファイル

別名を保守するには、以下のファイル、マップ、またはテーブルを使用します。

• .mailrc の別名

• /etc/mail/aliases ファイル

• NIS aliases マップ

• NIS+ mail_aliases テーブル

別名を保守する方法は、誰が使用し、誰が変更するかによって決まります。別名のタイプにはそれぞれ固有の形式要件があります。

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

.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 プログラムでその別名がバイナリ形式で使用できるようにします。作業手順については、第 25 章「メールサービス (手順)」の ローカルメール別名ファイルを設定する方法を参照してください。それ以外の場合、Solaris 管理コンソールの「メーリングリスト」機能を使ってローカルの /etc ファイルに保存されているメール別名を管理できます。

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

ignatz: ignatz@saturn

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

通常は、root ユーザーだけがこのファイルを編集できます。ただし、Administration を使用する場合は、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"

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

NIS aliases マップ

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

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

aliasname: value,value,value ...

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

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

aliasname: aliasname@host

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

作業手順については、第 25 章「メールサービス (手順)」の NIS mail.aliases マップを設定する方法を参照してください。

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"]

表 26–12 に、NIS+ mail_aliases テーブルの 4 つの列を示します。

NIS+ mail_aliases テーブルには、すべてのメールクライアントのエントリを含めてください。NIS+ aliases テーブルでは、aliasadm コマンドで、エントリの表示、作成、変更、および削除ができます。aliasadm コマンドを使用するには、aliases テーブルを所有する NIS+ グループのメンバーでなければなりません。作業手順については、第 25 章「メールサービス (手順)」の NIS+ mail_aliases テーブルの別名エントリを管理する方法を参照してください。Solaris 管理コンソールの「メーリングリスト」機能を使用して NIS+ メール別名を管理することもできます。

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

.forward ファイル

ホームディレクトリに .forward ファイルを作成すれば、sendmail およびその他のプログラムは、メールのリダイレクトや送信にこのファイルを使用できます。以下の節を参照してください。

• 回避すべき状況

• .forward ファイルの内容

• .forward.hostname ファイル

• .forward+detail ファイル

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

回避すべき状況

以下に、容易に回避または修復できる状況を示します。

• メールが宛先のアドレスに配信されない場合は、ユーザーの .forward ファイルをチェックします。ユーザーが host1 のホームディレクトリに .forward ファイルを置いている場合があります。この場合、メールは user@host2 に転送されます。host2 にメールが着信すると、sendmail は NIS または NIS+ 別名に user があるかどうかを確認し、メッセージを user@host1 に返送します。これによってループが発生し、メールのバウンスが増加します。

• セキュリティの問題を予防するために、.forward ファイルは決して root または bin アカウントに入れないでください。必要な場合は、代わりに aliases ファイルを使ってメールを転送してください。

.forward ファイルの内容

メール配信で .forward ファイルを有効に使用するために、アクセス権などの以下の設定が正しく適用されていることを確認します。

• .forward ファイルへの書き込みは、ファイルの所有者に制限されます。この制限によって、他のユーザーに対するセキュリティを確保できます。

• ホームディレクトリのパスは root だけが所有し、root だけが書き込めるようにする必要があります。たとえば、.forward ファイルが /export/home/terry にある場合、 /export および /export/home は root が所有し、root だけが書き込めるようにします。

• また実際のホームディレクトリに書き込めるのは、そのユーザーだけでなければなりません。

• .forward ファイルをシンボリックリンクにすることはできません。また、複数のハードリンクを持つこともできません。

.forward.hostname ファイル

.forward.hostname ファイルを作成すれば、特定のホストに送信されるメールをリダイレクトできます。たとえば、ユーザーの別名が sandy@phoenix.example.com から sandy@example.com に変更された場合は、sandy のホームディレクトリに .forward.phoenix ファイルを置きます。

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

My alias has changed to sandy@example.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 つのメッセージしか実行できません。ただし、メッセージが特定のホストに限定されない場合、.forward ファイルで複数のホストに同じ休暇メッセージファイルを使用できます。

.forward+detail ファイル

転送メカニズムの拡張機能にはこの他に、.forward+detail ファイルがあります。detail 文字列には、演算子文字を除く任意の文字を使用できます。演算子文字とは、.:%&!^[]+ です。この種のファイルを使用すれば、他のユーザーが電子メールアドレスを無断で使用しているかどうかを確認できます。たとえば、あるユーザーが、誰かに電子メールアドレス sandy+test1@example.com を使用するように指示した場合、ユーザーは、この別名に配信されるメールを、アドレスに送信されるメールの中から識別できます。デフォルトにより、sandy+test1@example.com の別名に送信されたメールはすべて、この別名と .forward+detail ファイルと突き合わせて検査されます。ここで一致しない場合は、そのメールは最終的に sandy@example.com に配信されますが、ユーザーは、これらのメールの To: ヘッダ内の変更箇所を調べることができます。

/etc/default/sendmail ファイル

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

CLIENTOPTIONS="string"

クライアントデーモンで使用する追加オプションを選択します。クライアントデーモンは、クライアントだけのキュー (/var/spool/clientmqueue) の内容を確認し、クライアントキューランナーとして動作します。構文の確認は行われないため、この変数を変更するときは間違えないように注意してください。

CLIENTQUEUEINTERVAL=#

CLIENTQUEUEINTERVAL には、QUEUEINTERVAL オプションと同様に、メールキューの実行間隔を設定します。ただし、CLIENTQUEUEINTERVAL オプションは、マスターデーモンではなくクライアントデーモンを制御します。一般に、マスターデーモンはすべてのメッセージを SMTP ポートに配信できます。ただし、メッセージ負荷が高すぎる場合、またはマスターデーモンが実行されていない場合、メッセージはクライアントだけのキューである /var/spool/clientmqueue に入ります。次に、クライアントだけのキューをチェックするクライアントデーモンがクライアントキューを処理します。

ETRN_HOSTS="string"

SMTP クライアントとサーバーが、定期的なキューの実行を待たずに即座に対話を実行できるようにします。サーバーは、指定されたホストに送信されるキューを即座に配信できます。詳細は、etrn(1M) のマニュアルページを参照してください。

MODE=-bd

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

OPTIONS=string

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

QUEUEINTERVAL=#

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

QUEUEOPTIONS=p

キューを実行するたびに新しいキューランナーを作成する代わりに、各実行の間に休止する単一の永続的なキューランナーを使用できるようにします。このオプションに設定可能な値は p だけです。p 以外に設定すると、このオプションは無効になります。

メールアドレスとメールルーティング

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

クライアントシステムは、メールをローカルに受信できるようにセットアップできます。メールをローカルで受信することは、ローカルモードでの sendmail の実行として知られています。すべてのメールサーバーと一部のクライアントでは、ローカルモードがデフォルトです。ローカルモードのメールサーバーまたはクライアントでは、メッセージは以下の要領でルーティングされます。

次の例では、sendmail.cf ファイルに設定されたデフォルトの規則を使用することを前提にしています。

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

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

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

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

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

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

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

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

ここでは、sendmail とネームサービスに適用されるドメイン名、ネームサービスを有効に利用するための規則、および sendmail とネームサービスの対話について説明します。詳細は、以下のトピックを参照してください。

• sendmail.cf とメールドメイン

• sendmail とネームサービス

• sendmail と NIS との相互作用

• sendmail と NIS および DNS との相互作用

• sendmail と NIS+ との相互作用

• sendmail と NIS+ および DNS との相互作用

関連する作業については、第 25 章「メールサービス (手順)」の sendmail で DNS を使用する方法または メール別名ファイルの管理 (作業マップ)を参照してください。

sendmail.cf とメールドメイン

標準の 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

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

ホストネームサービスデータ

ここでは、sendmail がネームサービスに必要とする要件について説明します。

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

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

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

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

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

ネームサービス内に有効な sendmail サービスを確立するために、ホストネームサービスに追加された以下の 2 つの規則に従う必要があります。

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

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

gethostbyname() 関数については、gethostbyname(3NSL) のマニュアルページを参照してください。

sendmail と NIS との相互作用

以下に、sendmail と NIS との相互作用について説明し、ガイドラインを示します。

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

• メールホスト名 – 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 ドメインでは無効になることがあります。

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

sendmail と NIS および DNS との相互作用

以下に、sendmail と NIS および DNS との相互作用について説明し、ガイドラインを示します。

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

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

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

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

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

作業手順については、第 25 章「メールサービス (手順)」の sendmail で DNS を使用する方法と メール別名ファイルの管理 (作業マップ)を参照してください。

sendmail と NIS+ との相互作用

以下に、sendmail と NIS+ との相互作用について説明し、ガイドラインを示します。

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

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

• メールホスト名 – NIS+ ホスト名には、mailhost エントリが必要です。

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

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

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

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

sendmail と NIS+ および DNS との相互作用

以下に、sendmail と NIS+ および DNS との相互作用について説明し、ガイドラインを示します。

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

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

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

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

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

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

作業手順については、第 25 章「メールサービス (手順)」の メール別名ファイルの管理 (作業マップ)と sendmail で DNS を使用する方法を参照してください。