ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris のシステム管理 (ネットワークサービス) Oracle Solaris 11 Information Library (日本語) |
パート II ネットワークファイルシステムへのアクセス (トピック)
6. ネットワークファイルシステムへのアクセス (リファレンス)
sendmail のコンパイルに使用できるフラグと使用できないフラグ
MILTER (sendmail のメールフィルタ API)
sendmail の version 8.13 で TLS を使用して SMTP を実行するためのサポート
TLS を使用して SMTP を実行するための構成ファイルのオプション
TLS を使用した SMTP の実行に関連するセキュリティーの検討事項
sendmail の version 8.13 で追加されたコマンド行オプション
sendmail の version 8.13 で追加または改訂された構成ファイルオプション
sendmail の version 8.13 で追加または改訂された FEATURE() の宣言
sendmail の version 8.12 からの変更点
sendmail の version 8.12 からの TCP ラッパーのサポート
sendmail の version 8.12 からの submit.cf 構成ファイル
sendmail.cf と submit.cf の機能の相違点
sendmail の version 8.12 からの機能の変更
sendmail の version 8.12 から追加されたまたは推奨されないコマンド行オプション
sendmail の version 8.12 から PidFile オプションおよび ProcessTitlePrefix オプションに追加された引数
sendmail の version 8.12 から追加定義されたマクロ
sendmail の version 8.12 から追加されたマクロ
sendmail の version 8.12 から追加された MAX マクロ
sendmail の version 8.12 から追加または改訂された m4 構成マクロ
sendmail の version 8.12 からの FEATURE() の宣言についての変更点
sendmail の version 8.12 からの MAILER() の宣言についての変更点
sendmail の version 8.12 から追加された配信エージェントのフラグ
sendmail の version 8.12 から追加された配信エージェントの設定
sendmail の version 8.12 から追加されたキューの機能
sendmail の version 8.12 からの LDAP の変更点
sendmail の version 8.12 からの組み込まれたメールプログラムの変更
sendmail の version 8.12 から追加されたルールセット
sendmail の version 8.12 からのファイルの変更点
sendmail version 8.12 と構成内の IPv6 アドレス
ここでは、 sendmail とネームサービスに適用されるドメイン名について説明します。さらに、ネームサービスを有効に利用するための規則、および sendmail とネームサービスの相互作用について説明します。詳細は、次のトピックを参照してください。
関連する作業については、「sendmail で DNS を使用する方法」の 「メール別名ファイルの管理 (作業マップ)」または 第 13 章メールサービス (手順)を参照してください。
標準の sendmail.cf ファイルは、メールドメインを使ってメールを直接配信するか、あるいはメールホストを経由して配信するかを決定します。ドメイン内メールは直接 SMTP 接続経由で配信され、ドメイン間メールはメールホストに送られます。
セキュリティーの高いネットワークでは、ほんの少数の選ばれたホストだけが、外部宛てのパケットを生成する権限を与えられています。ホストがメールドメインの外部のリモートホストの IP アドレスを持っている場合も、SMTP 接続の確立は保証されません。標準の sendmail.cf では次のことを仮定しています。
現在のホストは、パケットを直接メールドメイン外のホストに送信する権限がない。
メールホストは、パケットを外部ホストに直接送信できる認可されたホストにメールを転送できる。実際には、メールホストが認可されたホストになることがある。
このように仮定すると、ドメイン間メールの配信または転送はメールホスト側の責任です。
sendmail はさまざまな要件をネームサービスに課します。これらの要件の理解を深めるために、この節では、まずメールドメインからネームサービスドメインへの関係について説明します。その次に個々の要件について説明します。次を参照してください。
メールドメイン名はネームサービスドメイン名の接尾辞の 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 および 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 との相互作用について説明し、ガイドラインを示します。
メールドメイン名 – 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 ドメインでは無効になることがあります。
作業手順については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
次に、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 ドメインでは無効になることがあります。
作業手順については、「sendmail で DNS を使用する方法」の 「メール別名ファイルの管理 (作業マップ)」と 第 13 章メールサービス (手順)を参照してください。