パート IV メールサービス (トピック)

このパートでは、メールサービスの概要、作業、およびリファレンス情報について説明します。

第 12 章 メールサービス (概要)

電子メールサービスの設定と維持管理には、ネットワークの日常の運用にとって不可欠な、複雑な作業が伴います。ネットワーク管理者は、既存のメールサービスを拡張しなければならない場合があります。または、新しいネットワークまたはサブネット上でメールサービスを設定しなければならないこともあります。メールサービスに関する各章では、ネットワークでメールサービスを計画したり設定したりするために必要な情報を提供します。この章では、sendmail の新機能の説明へのリンクを用意し、参考資料を紹介します。この章ではまた、メールサービスを確立するために必要なソフトウェアおよびハードウェアコンポーネントの概要を説明します。

• 「メールサービスの新機能」

• 「sendmail のその他の情報」

• 「メールサービスのコンポーネントの概要」

第 13 章メールサービス (手順)では、メールサービスの設定および管理方法の手順を説明します。詳細は、「メールサービス (作業マップ)」を参照してください。

メールサービスのコンポーネントについての詳細は、第 14 章メールサービス (リファレンス)を参照してください。この章では、メールサービスのプログラムとファイル、メールルーティング処理、ネームサービスを使った sendmail の対話型操作、sendmail version 8.13 の機能についても説明します。「sendmail の version 8.13 での変更点」を参照してください。

メールサービスの新機能

この節では、さまざまな Solaris リリースの新機能について説明します。

このリリースでの変更点

Solaris 10 7/10 リリース リリースでは、次の変更点が加えられました。

• sendmail のデフォルトバージョンが 8.14 に更新されました。

• 従来のデーモン (svc:/network/smtp:sendmail) およびクライアントキューランナー (svc:/network/smtp:sendmail-client) の管理を改善するため、sendmail インスタンスが 2 つのインスタンスに分割されました。

• sendmail.cf および submit.mc 構成ファイルが自動的に再構築されるように、システムを構成可能になりました。必要な手順については、「構成ファイルを自動的に再構築する方法」を参照してください。

• デフォルトでは、sendmail デーモンは新しいローカルデーモンモードで動作します。ローカル専用モードでは、ローカルホストやループバック SMTP 接続からの着信メールだけを受信します。たとえば、cron ジョブからのメールやローカルユーザー間のメールを受信します。発信メールの経路は変更されず、着信メールだけが変更されます。ローカル専用モードを選択する場合には、-bl (Become Local モードの略) オプションを使用します。このモードの詳細は、sendmail(1M) のマニュアルページを参照してください。-bd (Become Daemon モード) に戻す方法については、「オープンモードで sendmail を使用する方法」を参照してください。

Solaris 10 1/06 リリースでの変更点

Solaris 10 1/06 以降のリリースでは、sendmail は Transport Layer Security (TLS) を使用した SMTP をサポートしています。詳細については、次を参照してください。

• 「sendmail の version 8.13 で TLS を使用して SMTP を実行するためのサポート」

• 「TLS を使用するよう SMTP を構成する」

Solaris 06 10/9 リリースに含まれる新機能の完全な一覧については、『Oracle Solaris 10 9/10 の新機能』を参照してください。

Solaris 10 リリースでの変更点

Solaris 10 以降のリリースでは、sendmail version 8.13 がデフォルトになっています。version 8.13 に関する情報とほかの変更点については、次を参照してください。

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

• 「MILTER (sendmail のメールフィルタ API)」

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

• 「vacation ユーティリティーの拡張機能」

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

• 「sendmail の version 8.13 での変更点」

• 「sendmail の version 8.12 からの TCP ラッパーのサポート」

さらに、メールサービスは、サービス管理機能によって管理されています。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。サービスの状態は、svcs コマンドを使用して照会できます。サービス管理機能の詳細は、smf(5) のマニュアルページおよび『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。

sendmail のその他の情報

次に、上記以外の sendmail 関連の参考資料を示します。

• Costales、Bryan 著、『sendmail, Third Edition』、O'Reilly & Associates, Inc.、2002

• sendmail 関連のホームページ – http://www.sendmail.org

• sendmail 関連の FAQ – http://www.sendmail.org/faq

• 新しい sendmail 構成ファイルの README – http://www.sendmail.org/m4/readme.html

• sendmail の最新 Sun バージョンへの移行ガイド – http://www.sendmail.org/vendor/sun/

メールサービスのコンポーネントの概要

メールサービスを確立するためには、多くのソフトウェアコンポーネントおよびハードウェアコンポーネントが必要になります。次では、これらのコンポーネントについて簡単に紹介します。コンポーネントの説明で使用する用語についても紹介します。

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

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

次の表にメールシステムのソフトウェアコンポーネントを示します。ソフトウェアコンポーネントすべてに関する詳細については、「ソフトウェアコンポーネント」を参照してください。

ハードウェアコンポーネントの概要

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

• メールホスト – 解釈処理が困難なメールアドレスを扱うように構成されたシステム

• 少なくとも 1 台のメールサーバー – 1 つまたは複数のメールボックスを保持するように構成されたシステム

• メールクライアント – メールサーバーからメールにアクセスするシステム

ユーザーがドメイン外のネットワークと通信をするためには、4 番目の要素であるメールゲートウェイを追加する必要があります。

図 12–1 には、一般的な電子メール構成を示しますが、ここでは基本的な 3 つのメール要素とメールゲートウェイが使用されています。

図 12–1 一般的な電子メール構成

各要素については、「ハードウェアコンポーネント」を参照してください。

第 13 章 メールサービス (手順)

この章ではメールサービスを設定し、管理する方法について説明します。メールサービスの管理に詳しくない場合は、メールサービスのコンポーネントを紹介している第 12 章メールサービス (概要)を参照してください。この章では、一般的なメールサービス構成についても説明しています (図 12–1 を参照)。この章では、次の関連作業について説明します。

• 「メールサービス (作業マップ)」

• 「メールサービスの設定 (作業マップ)」

• 「sendmail 構成の変更 (作業マップ)」

• 「メール別名ファイルの管理 (作業マップ)」

• 「キューディレクトリの管理 (作業マップ)」

• 「.forward ファイルの管理 (作業マップ)」

• 「メールサービスの障害対処とヒント (作業マップ)」

メールサービスのコンポーネントについての詳細は、第 14 章メールサービス (リファレンス)を参照してください。また、この章では、メールサービスのプログラムとファイル、メールルーティング処理、ネームサービスを使った sendmail の対話型操作、sendmail(1M) のマニュアルページで十分に説明されていない sendmail の version 8.13 での機能についても説明します。

メールサービス (作業マップ)

次の表から、具体的な一連の手順を扱っているほかの作業マップがわかります。

メールシステムの計画

次に、メールシステムを計画するときに考慮すべき点を挙げます。

• 必要に応じてメール構成のタイプを決定します。この節では、メール構成の基本の 2 タイプについて説明し、各構成を設定するために必要なことがらについて簡単に説明します。新しいメールシステムを設定する必要がある場合、あるいは既存のメールシステムを拡張する場合は、この節の内容が役立つでしょう。「ローカルメール専用」では 1 番目の構成タイプについて、「ローカルメールとリモート接続」では 2 番目の構成タイプについて説明します。

• 必要に応じてメールサーバー、メールホスト、およびメールゲートウェイとして動作するシステムを選択します。

• サービスを提供するすべてのメールクライアントのリストを作成し、メールボックスの場所も含めます。このリストは、ユーザーのメール別名を作成するときに役立ちます。

• 別名の更新方法とメールメッセージの転送方法を決めます。ユーザーがメールの転送要求を送る場所として、 aliases メールボックスを設定できます。ユーザーはこのメールボックスを使って、デフォルトのメール別名の変更要求を送ることもできます。システムで NIS または NIS+ を使用する場合、メール転送の管理は、ユーザー自身ではなく、管理者が行うこともできます。「メール別名ファイルの管理 (作業マップ)」に、別名に関連する作業の一覧があります。「.forward ファイルの管理 (作業マップ)」に、.forward ファイルの管理に関連する作業の一覧があります。

メールシステムの計画を立てたら、サイトにシステムを設定し、「メールサービスの設定 (作業マップ)」で説明する機能を実行します。ほかの作業については、「メールサービス (作業マップ)」を参照してください。

ローカルメール専用

図 13–1 に示すように、もっとも単純なメール構成は、1 台のメールホストに 2 台以上のワークステーションが接続されている場合です。メールは完全にローカルです。すべてのクライアントがローカルのディスクにメールを格納し、すべてのクライアントがメールサーバーとして機能します。メールアドレスは /etc/mail/aliases ファイルを使って構文解析されます。

図 13–1 ローカルメール構成

この種類のメール構成を設定するには、次が必要です。

• 各メールクライアントシステム上に、デフォルトの /etc/mail/sendmail.cf ファイル。編集は不要です。

• メールホストとして指定されたサーバー。NIS または NIS+ を実行している場合に、この指定を行うには、メールホスト上の /etc/hosts ファイルに mailhost. domain-name を追加します。DNS や LDAP など、別のネームサービスを実行している場合は、/etc/hosts ファイルに追加情報を入力します。「メールホストを設定する方法」を参照してください。

• NIS や NIS+ 以外のネームサービスを使用している場合は、ローカルメールボックスのあるすべてのシステム上に、対応する /etc/mail/aliases ファイルが必要です。

• 各メールクライアントシステムの /var/mail に、メールボックスを格納できるだけの十分な領域。

メールサービスの設定の詳細については、「メールサービスを設定する」を参照してください。メールサービスの設定に関する特定の手順については、「メールサービスの設定 (作業マップ)」を参照してください。

ローカルメールとリモート接続

小規模のネットワークにおけるもっとも一般的なメール構成を図 13–2 に示します。1 つのシステムが、メールサーバー、メールホスト、およびリモート接続を行うメールゲートウェイを兼ねています。メールは、メールゲートウェイ上の /etc/mail/aliases ファイルを使って配布されます。ネームサービスは必要ありません。

図 13–2 UUCP 接続を使ったローカルメール構成

この構成では、メールクライアントがメールホスト上の /var/mail からメールファイルをマウントすると想定できます。この種類のメール構成を設定するには、次が必要です。

• 各メールクライアントシステム上に、デフォルトの /etc/mail/sendmail.cf ファイル。このファイルは編集不要です。

• メールホストとして指定されたサーバー。NIS または NIS+ を実行している場合に、この指定を行うには、メールホスト上の /etc/hosts ファイルに mailhost. domain-name を追加します。DNS や LDAP など、別のネームサービスを実行している場合は、/etc/hosts ファイルに追加情報を入力します。「メールホストを設定する方法」を参照してください。

• NIS や NIS+ 以外のネームサービスを使用している場合は、ローカルメールボックスのあるすべてのシステム上に、対応する /etc/mail/aliases ファイルが必要です。

• メールサーバーの /var/mail に、クライアントのメールボックスを格納できるだけの十分な領域。

メールサービスの設定の詳細については、「メールサービスを設定する」を参照してください。メールサービスの設定に関する特定の手順については、「メールサービスの設定 (作業マップ)」を参照してください。

メールサービスの設定 (作業マップ)

次の表では、メールサービスの設定の手順を説明します。

メールサービスを設定する

サイトが企業外の電子メールサービスに接続していないか、あるいは企業が 1 つのドメイン内にある場合は、メールサービスを比較的容易に設定できます。

ローカルメール用に 2 つのタイプの構成が必要です。これらの構成については、図 13–1の「ローカルメール専用」 を参照してください。ドメイン外のネットワークと通信するためには、さらに 2 つのタイプの構成が必要です。これらの構成については、図 12–1の「ハードウェアコンポーネントの概要」 または 図 13–2の「ローカルメールとリモート接続」 を参照してください。これらの構成は、同じシステムで組み合わせるか、または別のシステムで提供できます。たとえば、同じシステムにメールホストとメールサーバーの機能を持たせる場合は、この節の説明に従って、まずそのシステムをメールホストとして設定します。次に、この節の説明に従って、同じシステムをメールサーバーとして設定します。

次のメールサーバーとメールクライアントの設定の手順は、メールボックスが NFS でマウントされているときに適用されます。ただし、メールボックスは通常、ローカルにマウントされた /var/mail ディレクトリで維持されるので、次の手順は必要ありません。

メールサーバーを設定する方法

メールサーバーはローカルユーザーにメールサービスを提供するだけなので、設定には特別な手順は必要ありません。ユーザーはパスワードファイルまたは名前空間にエントリが必要です。さらに、メールが配信されるためには、ユーザーはローカルのホームディレクトリを用意して、~/.forward ファイルを確認する必要があります。このため、ホームディレクトリサーバーがしばしばメールサーバーとして設定されます。メールサーバーについては、「ハードウェアコンポーネント」の 第 14 章メールサービス (リファレンス)でさらに詳しく説明します。

メールサーバーは、メールクライアント宛てにメールを経路指定します。このタイプのメールサーバーは、クライアントのメールボックス用に十分なスプール空間が必要です。

mail.local プログラムは、メッセージがはじめて配信された時に /var/mail ディレクトリでメールボックスを自動的に作成します。メールクライアントの個々のメールボックスを作成する必要はありません。

クライアントが自分のメールボックスにアクセスするには、/var/mail ディレクトリをリモートマウントに利用できなければなりません。または、POP (Post Office Protocol)、IMAP (Internet Message Access Protocol) などのサービスをサーバーから利用できなければなりません。次では、/var/mail ディレクトリを使ってメールサーバーを設定する方法を示します。このマニュアルでは、POP または IMAP の構成方法については説明しません。

次の作業のために、/var/mail ディレクトリがエクスポートされていることを /etc/dfs/dfstab ファイルで確認します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail を停止します。

   # svcadm disable -t network/smtp:sendmail

3. /var/mail ディレクトリをリモートアクセスに使用できるかどうかを確認します。

   # share

   /var/mail ディレクトリが表示された場合は、手順 5 に進みます。

   /var/mail ディレクトリが表示されない場合、あるいはリストが表示されない場合は、該当する手順に進みます。

   1. (省略可能) リストが表示されない場合は、NFS サービスを起動します。

      「ファイルシステム自動共有を設定する方法」の手順に従って、/var/mail ディレクトリを使用して NFS サービスを起動します。

   2. (省略可能) /var/mail ディレクトリがリストに含まれていない場合は、/var/mail ディレクトリを /etc/dfs/dfstab に追加します。

      /etc/dfs/dfstab ファイルに次のコマンド行を追加します。

      share -F nfs -o rw /var/mail

4. ファイルシステムをマウントできるようにします。

   # shareall

5. ネームサービスが起動されていることを確認します。

   1. (省略可能) NIS を実行している場合は、次のコマンドを使用します。

      # ypwhich

      詳細は、ypwhich(1) のマニュアルページを参照してください。

   2. (省略可能) NIS+ を実行している場合は、次のコマンドを使用します。

      # nisls

      詳細は、nisls(1) のマニュアルページを参照してください。

   3. (省略可能) DNS を実行している場合は、次のコマンドを使用します。

      # nslookup hostname

      hostname

      ホスト名を指定します。

      詳細は、nslookup(1M) のマニュアルページを参照してください。

   4. (省略可能) LDAP を実行している場合は、次のコマンドを使用します。

      # ldaplist

      詳細は、ldaplist(1) のマニュアルページを参照してください。

6. sendmail を再起動します。

   # svcadm enable network/smtp:sendmail

メールクライアントを設定する方法

メールクライアントは、メールサーバー上にメールボックスを持っている、メールサービスのユーザーです。メールクライアントにはさらに、/etc/mail/aliases ファイルで、メールボックスの位置を示すメール別名が設定されています。

POP (Post Office Protocol) または IMAP (Internet Message Access Protocol) のようなサービスを使ってメールクライアントを設定することもできます。ただし、POP または IMAP の構成方法については、このマニュアルでは説明していません。

1. メールクライアントシステム上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail を停止します。

   # svcadm disable -t network/smtp:sendmail

3. メールクライアントのシステムで /var/mail マウントポイントがあることを確認します。

   マウントポイントは、インストール過程で作成されています。ls を使用すると、ファイルシステムが存在するかどうかを確認できます。次の例はファイルシステムが作成されていない場合に受け取る応答を示しています。

   # ls -l /var/mail /var/mail not found

4. /var/mail ディレクトリにファイルが何もないことを確認します。

   メールファイルがこのディレクトリにある場合は、それらのファイルを移動させ、サーバーから /var/mail ディレクトリがマウントされるときにその対象とならないようにします。

5. メールサーバーから /var/mail ディレクトリをマウントします。

   メールディレクトリは自動的にマウントすることも、ブート時にマウントすることもできます。

   1. (省略可能) /var/mail を自動的にマウントします。

      次のようなエントリを /etc/auto_direct ファイルに追加します。

      /var/mail -rw,hard,actimeo=0 server:/var/mail

      server

      割り当てられているサーバー名を指定します。

   2. (省略可能) ブート時に /var/mail をマウントします。

      /etc/vfstab ファイルに次のエントリを追加します。このエントリにより、指定されたメールサーバー上の /var/mail ディレクトリがローカルの /var/mail ディレクトリをマウントできます。

      server:/var/mail - /var/mail nfs - no rw,hard,actimeo=0

      システムをリブートするたびに、クライアントのメールボックスが自動的にマウントされます。システムをリブートしない場合は、次のコマンドを入力すれば、クライアントのメールボックスをマウントできます。

      # mountall

      ---

      注意 –

      メールボックスのロックとメールボックスへのアクセスが適切に動作するには、NFS サーバーからメールをマウントするときに actimeo=0 オプションを入れる必要があります。

      ---

6. /etc/hosts を更新します。

   /etc/hosts ファイルを編集し、メールサーバーのエントリを追加します。ネームサービスを使用する場合、この手順は必要ありません。

   # cat /etc/hosts # # Internet host table # .. IP-address mailhost mailhost mailhost.example.com

   IP-address

   割り当てられている IP アドレスを指定します。

   example.com

   割り当てられているドメインを指定します。

   mailhost

   割り当てられているメールホストを指定します。

   詳細は、hosts(4) のマニュアルページを参照してください。

7. 別名ファイルの 1 つにクライアントのエントリを追加します。

   メール別名ファイルの管理に関する作業マップについては、「メール別名ファイルの管理 (作業マップ)」を参照してください。mail.local プログラムは、メッセージがはじめて配信された時に /var/mail ディレクトリでメールボックスを自動的に作成します。メールクライアントの個々のメールボックスを作成する必要はありません。

8. sendmail を再起動します。

   # svcadm enable network/smtp:sendmail

メールホストを設定する方法

メールホストは、電子メールアドレスを解決し、ドメイン内でメールを再度ルーティングします。メールホストに適しているのは、ネットワークにリモート接続を提供するシステム、または親ドメインにネットワークを接続するシステムです。次に、メールホストを設定する手順を示します。

1. メールホストシステム上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail を停止します。

   # svcadm disable -t network/smtp:sendmail

3. ホスト名の構成を確認します。

   次のように check-hostname スクリプトを実行し、sendmail が、このサーバーの完全指定のホスト名を識別できるかどうかを確認します。

   % /usr/sbin/check-hostname hostname phoenix OK: fully qualified as phoenix.example.com

   このスクリプトで完全指定ホスト名が識別できなかった場合は、完全指定ホスト名をホストの最初の別名として /etc/hosts 内に追加する必要があります。

4. /etc/hosts ファイルを更新します。

   次から、適切な手順を選択します。

   1. (省略可能) NIS または NIS+ を使用している場合は、新しいメールホストとなるシステムの /etc/hosts ファイルを編集します。

      メールホストシステムの IP アドレスとシステム名のあとに mailhost と mailhost.domain を追加します。

      IP-address mailhost mailhost mailhost.domain loghost

      IP-address

      割り当てられている IP アドレスを指定します。

      mailhost

      メールホストシステムのシステム名を指定します。

      domain

      拡張ドメイン名を指定します。

      これで、このシステムはメールホストとして指定されます。domain は、次のコマンドの出力にサブドメイン名として指定されている文字列と同じにする必要があります。

      % /usr/lib/sendmail -bt -d0 </dev/null Version 8.13.1+Sun Compiled with: LDAPMAP MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS NISPLUS QUEUE SCANF SMTP USERDB XDEBUG ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = phoenix (canonical domain name) $j = phoenix.example.com (subdomain name) $m = example.com (node name) $k = phoenix ========================================================

      以上の変更を行なったあとの hosts ファイルの例を次に示します。

      # cat /etc/hosts # # Internet host table # 172.31.255.255 localhost 192.168.255.255 phoenix mailhost mailhost.example.com loghost

   2. (省略可能) NIS または NIS+ を使用しない場合は、ネットワーク内の各システムにある /etc/hosts ファイルを編集します。

      次のようなエントリを作成します。

      IP-address mailhost mailhost mailhost.domain loghost

5. sendmail を再起動します。

   # svcadm enable network/smtp:sendmail

6. メール構成をテストします。

   手順については、「メール構成をテストする方法」を参照してください。

   ---

   注 –

   メールホストの詳細は、「ハードウェアコンポーネント」の 第 14 章メールサービス (リファレンス)を参照してください。

   ---

メールゲートウェイを設定する方法

メールゲートウェイは、ドメイン外のネットワークとの通信を管理します。送信側メールゲートウェイ上のメールプログラムは、受信側システムのメールプログラムと同じでなければなりません。

メールゲートウェイに適しているのは、Ethernet および電話回線に接続されているシステムです。インターネットへのルーターとして設定されているシステムも適しています。メールホストをメールゲートウェイとして設定するか、あるいは別のシステムをメールゲートウェイとして設定できます。複数のメールゲートウェイを自分のドメイン用として設定できます。UUCP (UNIX-to-UNIX Copy Program) 接続がある場合は、メールゲートウェイとして UUCP 接続を使ってシステムを構成します。

1. メールゲートウェイ上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail を停止します。

   # svcadm disable -t network/smtp:sendmail

3. ホスト名の構成を確認します。

   次のように check-hostname スクリプトを実行し、sendmail が、このサーバーの完全指定のホスト名を識別できるかどうかを確認します。

   # /usr/sbin/check-hostname hostname phoenix OK: fully qualified as phoenix.example.com

   このスクリプトで完全指定ホスト名が識別できなかった場合は、完全指定ホスト名をホストの最初の別名として /etc/hosts 内に追加する必要があります。この手順の詳細は、手順 4の「メールホストを設定する方法」 を参照してください。

4. ネームサービスが起動されていることを確認します。

   1. (省略可能) NIS を実行している場合は、次のコマンドを使用します。

      # ypwhich

      詳細は、ypwhich(1) のマニュアルページを参照してください。

   2. (省略可能) NIS+ を実行している場合は、次のコマンドを使用します。

      # nisls

      詳細は、nisls(1) のマニュアルページを参照してください。

   3. (省略可能) DNS を実行している場合は、次のコマンドを使用します。

      # nslookup hostname

      hostname

      ホスト名を指定します。

      詳細は、nslookup(1M) のマニュアルページを参照してください。

   4. (省略可能) LDAP を実行している場合は、次のコマンドを使用します。

      # ldaplist

      詳細は、ldaplist(1) のマニュアルページを参照してください。

5. sendmail を再起動します。

   # svcadm enable network/smtp:sendmail

6. メール構成をテストします。

   手順については、「メール構成をテストする方法」を参照してください。

   ---

   注 –

   メールゲートウェイの詳細は、「ハードウェアコンポーネント」の 第 14 章メールサービス (リファレンス)を参照してください。

   ---

sendmail で DNS を使用する方法

DNS ネームサービスは、個別の別名をサポートしません。このネームサービスは、MX (メール交換局) レコードおよび CNAME レコードを使用するホストまたはドメインの別名をサポートします。ホスト名とドメイン名は両方またはいずれか一方を DNS データベースで指定できます。sendmail と DNS の詳細は、「sendmail とネームサービスの相互作用」の 第 14 章メールサービス (リファレンス)、または『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. DNS ホストルックアップ機能を有効にします (NIS+ のみ)。

   /etc/nsswitch.conf ファイルを編集し、dns フラグを含む hosts の定義から # を削除します。 DNS ホスト別名を使用するには、次の例に示すように、ホストエントリに dns フラグが含まれている必要があります。

   # grep hosts /etc/nsswitch.conf #hosts: nisplus [NOTFOUND=return] files hosts: dns nisplus [NOTFOUND=return] files

3. mailhost と mailhost.domain エントリを確認します。

   nslookup を使用して、mailhost と mailhost. domain のエントリが DNS データベースに存在することを確認します。詳細は、nslookup(1M) のマニュアルページを参照してください。

sendmail 構成の変更 (作業マップ)

sendmail 構成を変更する

「新しい sendmail.cf ファイルを構築する方法」で、構成ファイルの構築方法について説明します。sendmail.cf ファイルの以前のバージョンも引き続き使用できますが、新しい形式を使用することをお薦めします。

詳細は、次を参照してください。

• /etc/mail/cf/README。構成手順の詳細な説明です。

• http://www.sendmail.org。sendmail 構成に関するオンライン情報です。

• 「構成ファイルのバージョン」の 「sendmail 構成ファイル」 と 第 14 章メールサービス (リファレンス)。いくつかのガイダンスを示します。

• 「sendmail の version 8.12 から追加または改訂された m4 構成マクロ」

新しい sendmail.cf ファイルを構築する方法

次に、新しい構成ファイルを構築する手順を示します。

/usr/lib/mail/cf/main-v7sun.mc は、/etc/mail/cf/cf/sendmail.mc になりました。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail を停止します。

   # svcadm disable -t network/smtp:sendmail

3. 変更しようとする構成ファイルのコピーを作成します。

   # cd /etc/mail/cf/cf # cp sendmail.mc myhost.mc

   myhost

   .mc ファイルの新しい名前を指定します。

4. 必要に応じて、新しい構成ファイル (たとえば、myhost.mc) を編集します。

   たとえば、ドメインマスカレードを有効にするには、次のコマンド行を追加します。

   # cat myhost.mc .. MASQUERADE_AS(`host.domain')

   host.domain

   目的のホスト名とドメイン名を指定します。

   この例では、MASQUERADE_AS は、送信されたメールに、$j ではなく host.domain から送信されたものとしてラベルを付けます。

5. m4 を使って構成ファイルを構築します。

   # /usr/ccs/bin/make myhost.cf

6. -C オプションを使用して、新しい構成ファイルをテストし、新しいファイルを指定します。

   # /usr/lib/sendmail -C myhost.cf -v testaddr </dev/null

   このコマンドはメッセージを表示するとともに、メッセージを testaddr に送信します。システム上で sendmail サービスを再起動せずに、送信メールだけがテストできます。まだメールを処理していないシステムでは、「メール構成をテストする方法」で説明する完全なテスト手順を使用してください。

7. オリジナルのコピーを作成したあと、新しい構成ファイルをインストールします。

   # cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.save # cp myhost.cf /etc/mail/sendmail.cf

8. sendmail サービスを再起動します。

   # svcadm enable network/smtp:sendmail

仮想ホストを設定する

ホストに複数の IP アドレスを割り当てる必要がある場合は、http://www.sendmail.org/tips/virtualHosting の Web サイトを参照してください。このサイトでは、sendmail を使って仮想ホストを設定する方法を詳しく説明しています。ただし、「Sendmail Configuration」の節では、次に示す手順 3b は実行しないでください。

# cd sendmail-VERSION/cf/cf
# ./Build mailserver.cf
# cp mailserver.cf /etc/mail/sendmail.cf

代わりに、Solaris オペレーティングシステムでは、次の手順を実行してください。

# cd /etc/mail/cf/cf
# /usr/ccs/bin/make mailserver.cf
# cp mailserver.cf /etc/mail/sendmail.cf

mailserver

.cf ファイルの名前を指定します。

「sendmail 構成を変更する」では、構築手順の一部として、これと同じ 3 つの手順を説明しています。

/etc/mail/sendmail.cf ファイルを生成したら、次の手順に進み、仮想ユーザーテーブルを作成できます。

構成ファイルを自動的に再構築する方法

sendmail.cf または submit.cf のコピーを独自に構築済みであれば、アップグレード時に構成ファイルが置き換えられることはありません。次の手順は、sendmail.cf ファイルが自動的に再構築されるように sendmail サービスのプロパティーを構成する方法を示します。submit.cf 構成ファイルを自動的に再構築する方法については、例 13–1 を参照してください。両方のファイルの構築が必要な場合には、これらの手順を組み合わることもできます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail プロパティーを設定します。

   # svccfg -s sendmail svc:/network/smtp:sendmail> setprop config/path_to_sendmail_mc=/etc/mail/cf/cf/myhost.mc svc:/network/smtp:sendmail> quit

3. sendmail サービスの再表示と再起動を行います。

   最初のコマンドは、変更を実行中のスナップショット内に転送します。2 番目のコマンドは、新しいオプションを使って sendmail サービスを再起動します。

   # svcadm refresh svc:/network/smtp:sendmail # svcadm restart svc:/network/smtp:sendmail

例 13–1 submit.cf の自動再構築を設定する

この手順では、submit.mc 構成ファイルが自動的に再構築されるように sendmail サービスを構成します。

# svccfg -s sendmail-client:default
svc:/network/smtp:sendmail> setprop config/path_to_submit_mc=/etc/mail/cf/cf/submit-myhost.mc 
svc:/network/smtp:sendmail> exit
# svcadm refresh svc:/network/sendmail-client 
# svcadm restart svc:/network/sendmail-client

オープンモードで sendmail を使用する方法

Solaris 10 リリースでは、sendmail サービスがデフォルトでローカル専用モードで実行するように変更されました。ローカル専用モードとは、ローカルホストからのメールだけが受け入れられることを意味します。その他のシステムからのメッセージはすべて拒否されます。Solaris の以前のリリースは、すべてのリモートシステムからのメールを受け入れるように構成されていました。これはオープンモードとして知られています。オープンモードを使用するには、次の手順に従います。

ローカル専用モードでの sendmail の実行は、オープンモードでの実行よりもはるかに安全です。潜在的なセキュリティーの問題を確実に認識した上で、この手順を実行してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail プロパティーを設定します。

   # svccfg -s sendmail svc:/network/smtp:sendmail> setprop config/local_only = false svc:/network/smtp:sendmail> quit

3. sendmail サービスの再表示と再起動を行います。

   # svcadm refresh svc:/network/smtp:sendmail # svcadm restart svc:/network/smtp:sendmail

TLS を使用するよう SMTP を構成する

Solaris 10 1/06 以降のリリースでは、SMTP は sendmail の version 8.13 で Transport Layer Security (TLS) を使用できます。SMTP サーバーおよびクライアントに対するこのサービスは、インターネット上での機密性の高い認証された通信だけでなく、盗聴や攻撃からの保護も実現します。このサービスは、デフォルトでは有効になっていないことに注意してください。

次の手順では、サンプルデータを使用して、sendmail が TLS を使用できるようにする証明書を設定する方法を示します。詳細については、「sendmail の version 8.13 で TLS を使用して SMTP を実行するためのサポート」を参照してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail を停止します。

   # svcadm disable -t network/smtp:sendmail

3. sendmail が TLS を使用できるようにする証明書を設定します。

   1. 次の手順を行います。

      # cd /etc/mail # mkdir -p certs/CA # cd certs/CA # mkdir certs crl newcerts private # echo "01" > serial # cp /dev/null index.txt # cp /etc/sfw/openssl/openssl.cnf .

   2. 任意のテキストエディタを使用して openssl.cnf ファイルの dir の値を /etc/sfw/openssl から /etc/mail/certs/CA に変更します。

   3. openssl コマンド行ツールを使用して TLS を実装します。

      次のコマンド行は対話型テキストを生成することに注意してください。

      # openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 \ -config openssl.cnf Generating a 1024 bit RSA private key .....................................++++++ .....................................++++++ writing new private key to 'private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) []:US State or Province Name (full name) []:California Locality Name (eg, city) []:Menlo Park Organization Name (eg, company) [Unconfigured OpenSSL Installation]:Sun Microsystems Organizational Unit Name (eg, section) []:Solaris Common Name (eg, YOUR name) []:somehost.somedomain.example.com Email Address []:someuser@example.com

      req

      このコマンドは証明書要求を作成し、処理します。

      -new

      この req オプションを選択すると、新しい証明書要求が作成されます。

      -x509

      この req オプションを選択すると、自己署名付き証明書が作成されます。

      -keyout private/cakey.pem

      この req オプションを選択すると、新しく作成された秘密鍵のファイル名として private/cakey.pem を割り当てることができます。

      -out cacert.pem

      この req オプションを選択すると、出力ファイルとして cacert.pem を割り当てることができます。

      -days 365

      この req オプションを選択すると、証明書を 365 日間証明することができます。デフォルト値は 30 です。

      -config openssl.cnf

      この req オプションを選択すると、構成ファイルとして openssl.cnf を指定することができます。

      このコマンドは、次の内容を指定する必要があります。

      • Country Name (US など)。

      • State or Province Name (California など)。

      • Locality Name (Menlo Park など)。

      • Organization Name (Sun Microsystems など)。

      • Organizational Unit Name (Solaris など)。

      • Common Name (マシンの完全指定のホスト名)。詳細は、check-hostname(1M) のマニュアルページを参照してください。

      • Email Address (someuser@example.com など)。

4. (省略可能) セキュリティー保護された新しい接続が必要である場合、新しい証明書を作成し、認証局を使用して新しい証明書に署名します。

   1. 新しい証明書を作成します。

      # cd /etc/mail/certs/CA # openssl req -nodes -new -x509 -keyout newreq.pem -out newreq.pem -days 365 \ -config openssl.cnf Generating a 1024 bit RSA private key ..............++++++ ..............++++++ writing new private key to 'newreq.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) []:US State or Province Name (full name) []:California Locality Name (eg, city) []:Menlo Park Organization Name (eg, company) [Unconfigured OpenSSL Installation]:Sun Microsystems Organizational Unit Name (eg, section) []:Solaris Common Name (eg, YOUR name) []:somehost.somedomain.example.com Email Address []:someuser@example.com

      このコマンドでは、手順 3c で指定した情報と同じ情報を指定する必要があります。

      この例では、証明書と秘密鍵はファイル newreq.pem 内にあることに注意してください。

   2. 認証局を使用して新しい証明書に署名します。

      # cd /etc/mail/certs/CA # openssl x509 -x509toreq -in newreq.pem -signkey newreq.pem -out tmp.pem Getting request Private Key Generating certificate request # openssl ca -config openssl.cnf -policy policy_anything -out newcert.pem -infiles tmp.pem Using configuration from openssl.cnf Enter pass phrase for /etc/mail/certs/CA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Jun 23 18:44:38 2005 GMT Not After : Jun 23 18:44:38 2006 GMT Subject: countryName = US stateOrProvinceName = California localityName = Menlo Park organizationName = Sun Microsystems organizationalUnitName = Solaris commonName = somehost.somedomain.example.com emailAddress = someuser@example.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 93:D4:1F:C3:36:50:C5:97:D7:5E:01:E4:E3:4B:5D:0B:1F:96:9C:E2 X509v3 Authority Key Identifier: keyid:99:47:F7:17:CF:52:2A:74:A2:C0:13:38:20:6B:F1:B3:89:84:CC:68 DirName:/C=US/ST=California/L=Menlo Park/O=Sun Microsystems/OU=Solaris/\ CN=someuser@example.com/emailAddress=someuser@example.com serial:00 Certificate is to be certified until Jun 23 18:44:38 2006 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated # rm -f tmp.pem

      この例では、ファイル newreq.pem には未署名の証明書と秘密鍵が含まれています。ファイル newcert.pem には署名済みの証明書が含まれています。

      x509 ユーティリティー

      証明書の情報を表示し、証明書をさまざまな形式に変換し、証明書要求に署名します。

      ca アプリケーション

      さまざまな形式の証明書要求の署名と、CRL (Certificate Revocation List) の生成に使用されます。

5. .mc ファイルに次の行を追加することにより、sendmail が証明書を使用できるようにします。

   define(`confCACERT_PATH', `/etc/mail/certs')dnl define(`confCACERT', `/etc/mail/certs/CAcert.pem')dnl define(`confSERVER_CERT', `/etc/mail/certs/MYcert.pem')dnl define(`confSERVER_KEY', `/etc/mail/certs/MYkey.pem')dnl define(`confCLIENT_CERT', `/etc/mail/certs/MYcert.pem')dnl define(`confCLIENT_KEY', `/etc/mail/certs/MYkey.pem')dnl

   詳細は、「TLS を使用して SMTP を実行するための構成ファイルのオプション」を参照してください。

6. /etc/mail ディレクトリで sendmail.cf ファイルを再構築し、インストールします。

   手順の詳細は、「sendmail 構成を変更する」を参照してください。

7. openssl を使用して作成したファイルから、.mc ファイルで定義したファイルへの、シンボリックリンクを作成します。

   # cd /etc/mail/certs # ln -s CA/cacert.pem CAcert.pem # ln -s CA/newcert.pem MYcert.pem # ln -s CA/newreq.pem MYkey.pem

8. セキュリティーを高めるには、MYkey.pem に関して、グループなどに対して読み取り権を許可しないでください。

   # chmod go-r MYkey.pem

9. シンボリックリンクを使用して、confCACERT_PATH に割り当てられているディレクトリで CA 証明書をインストールします。

   # C=CAcert.pem # ln -s $C `openssl x509 -noout -hash < $C`.0

10. そのほかのホストとのメールのセキュリティーを保護するには、ホストの証明書をインストールします。

    1. ほかのホストの confCACERT オプションにより定義されたファイルを、/etc/mail/certs/host.domain.cert.pem にコピーします。

       host.domain を、ほかのホストの完全指定のホスト名に置き換えます。

    2. シンボリックリンクを使用して、confCACERT_PATH に割り当てられているディレクトリで CA 証明書をインストールします。

       # C=host.domain.cert.pem # ln -s $C `openssl x509 -noout -hash < $C`.0

       host.domain を、ほかのホストの完全指定のホスト名に置き換えます。

11. sendmail を再起動します。

    # svcadm enable network/smtp:sendmail

例 13–2 Received: メールヘッダー

次に、TLS を使用したセキュリティー保護されたメールの Received: ヘッダーの例を示します。

Received: from his.example.com ([IPv6:2001:db8:3c4d:15::1a2f:1a2b])
        by her.example.com (8.13.4+Sun/8.13.4) with ESMTP id j2TNUB8i242496
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
        for <janepc@her.example.com>; Tue, 29 Mar 2005 15:30:11 -0800 (PST)
Received: from her.example.com (her.city.example.com [192.168.0.0])
        by his.example.com (8.13.4+Sun/8.13.4) with ESMTP id j2TNU7cl571102
        version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
        for <janepc@her.example.com>; Tue, 29 Mar 2005 15:30:07 -0800 (PST)

verify の値が OK である、つまり認証が成功したことに注意してください。詳細は、「TLS を使用して SMTP を実行するためのマクロ」を参照してください。

参照

次の OpenSSL のマニュアルページも参照してください。

• openssl(1)

• req(1)

• x509(1)

• ca(1)

sendmail.cf の代替構成を使ってメール配信を管理する方法

送受信されるメールの転送を容易にするため、sendmail の新しいデフォルトの構成は、デーモンとクライアントキューランナーを使用します。クライアントキューランナーは、ローカルの SMTP ポートのデーモンにメールを送信できなければなりません。デーモンが SMTP ポート上で待機していない場合、メールはキューに留まります。この問題を避けるには、次の作業を行います。デーモンとクライアントキューランナーについての詳細、およびこの代替構成を使用する必要性を理解するには、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。

この手順を実行すると、デーモンは、ローカルホストからの接続を受け付けるためだけに動作するようになります。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail クライアントサービスを停止します。

   # svcadm disable -t sendmail-client

3. 変更しようとする構成ファイルのコピーを作成します。

   # cd /etc/mail/cf/cf # cp submit.mc submit-myhost.mc

   myhost

   .mc ファイルの新しい名前を指定します。

4. 新しい構成ファイル (たとえば、submit- myhost.mc) を編集します。

   待機中のホスト IP アドレスを msp 定義に変更します。

   # grep msp submit-myhost.mc FEATURE(`msp', `[#.#.#.#]')dnl

5. m4 を使って構成ファイルを構築します。

   # /usr/ccs/bin/make submit-myhost.cf

6. オリジナルのコピーを作成したあと、新しい構成ファイルをインストールします。

   # cp /etc/mail/submit.cf /etc/mail/submit.cf.save # cp submit-myhost.cf /etc/mail/submit.cf

7. sendmail クライアントサービスを再起動します。

   # svcadm enable sendmail-client

メール別名ファイルの管理 (作業マップ)

次の表では、メール別名ファイルの管理の手順を説明します。このトピックの詳細は、「メール別名ファイル」の 第 14 章メールサービス (リファレンス)を参照してください。

メール別名ファイルを管理する

メール別名はドメイン独自にする必要があります。この節では、メール別名ファイルを管理する手順を説明します。また、Solaris 管理コンソールの「メーリングリスト」機能を使って別名データベース上でこれらの作業を実行することもできます。

その他に、makemap を使ってローカルメールホストにデータベースファイルを作成することもできます。makemap(1M) のマニュアルページを参照してください。ローカルのデータベースファイルを使用しても、NIS や NIS+ のようなネームサービスを使用するほどの利点は得られません。しかし、ネットワークのルックアップは必要ないため、ローカルのデータベースファイルからの方がより早くデータを取り出すことができます。詳細は、「sendmail とネームサービスの相互作用」の 「メール別名ファイル」および 第 14 章メールサービス (リファレンス)を参照してください。

次の操作を行うことができます。

• 「NIS+ mail_aliases テーブルを作成する方法」

• 「NIS+ mail_aliases テーブルの内容を表示する方法」

• 「コマンド行から NIS+ mail_aliases テーブルへ別名を追加する方法」

• 「NIS+ mail_aliases テーブルを編集してエントリを追加する方法」

• 「NIS+ mail_aliases テーブルのエントリを編集する方法」

• 「NIS mail.aliases マップを設定する方法」

• 「ローカルメール別名ファイルを設定する方法」

• 「キー付きマップファイルの作成方法」

NIS+ mail_aliases テーブルを作成する方法

aliasadm コマンドを使用して、NIS+ テーブルのエントリを管理することができます。テーブルを作成するには、次の手順に従います。詳細は、aliasadm(1M) のマニュアルページを参照してください。

1. テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. NIS+ テーブルを作成します。

   # aliasadm -I

3. テーブルにエントリを追加します。

   • 2 つまたは 3 つの別名を追加する方法については、「コマンド行から NIS+ mail_aliases テーブルへ別名を追加する方法」を参照してください。

   • 多数の別名を追加する方法については、「NIS+ mail_aliases テーブルを編集してエントリを追加する方法」を参照してください。

NIS+ mail_aliases テーブルの内容を表示する方法

テーブルの全内容を表示するには、次の手順に従います。

1. テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 別名のアルファベット順に全エントリを表示します。

   # aliasadm -1

   詳細は、aliasadm(1M) のマニュアルページを参照してください。

例 13–3 NIS+ mail_aliases テーブルの個々のエントリを表示する

また、aliasadm コマンドを使用して、個々のエントリを表示することもできます。この手順の最初の手順が完了したら、次のように入力します。

# aliasadm -m ignatz
ignatz: ignatz@saturn # Alias for Iggy Ignatz

このコマンドは、完全に一致する別名のみ表示し、部分的に一致するエントリは表示しません。aliasadm -m オプションでは、メタキャラクタ (*、? など) は使用できません。

例 13–4 NIS+ mail_aliases テーブル内の部分一致エントリを表示する

また、aliasadm コマンドを使用して、部分一致エントリを表示することもできます。この手順の最初の手順が完了したら、次のように入力します。

# aliasadm -l | grep partial-string

partial-string は、検索に使用する文字列で置き換えます。

コマンド行から NIS+ mail_aliases テーブルへ別名を追加する方法

2 つまたは 3 つの別名をテーブルに追加するには、次の手順に従います。多数の別名を追加する場合は、「NIS+ mail_aliases テーブルを編集してエントリを追加する方法」を参照してください。

1. メールクライアント、メールボックスの場所、およびメールサーバーシステムの名前の各リストをコンパイルします。

2. テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

3. (省略可能) 必要な場合は、NIS+ テーブルを作成します。

   まったく新しい NIS+ mail_aliases テーブルを作成する場合は、最初に NIS+ テーブルを初期設定しなければなりません。テーブルの作成方法については、「NIS+ mail_aliases テーブルを作成する方法」を参照してください。

4. テーブルに別名を追加します。

   次に、一般的なエントリの例を示します。

   # aliasadm -a iggy iggy.ignatz@saturn "Iggy Ignatz"

   上記の例の入力内容を次に説明します。

   -a

   別名を追加するためのオプション

   iggy

   簡略別名

   iggy.ignatz@saturn

   拡張別名

   "Iggy Ignatz"

   引用符で囲んだ別名

5. 作成したエントリを表示し、エントリに間違いがないことを確認します。

   # aliasadm -m alias

   alias

   作成したエントリ

   詳細は、aliasadm(1M) のマニュアルページを参照してください。

NIS+ mail_aliases テーブルを編集してエントリを追加する方法

aliasadm コマンドを使用して、NIS+ テーブルのエントリを管理することができます。多数の別名をテーブルに追加するには、次の手順に従います。

1. メールクライアント、メールボックスの場所、およびメールサーバーシステムの名前の各リストをコンパイルします。

2. テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

3. 別名テーブルを表示して編集します。

   # aliasadm -e

   このコマンドは、テーブルを表示し、テーブルの編集を可能にします。使用するエディタは、$EDITOR 環境変数で設定されています。この変数が設定されていない場合、vi がデフォルトのエディタになります。

4. 次の形式で、1 行に 1 別名ずつ入力します。

   alias: expanded-alias # ["option" # "comments"]

   alias

   この列には、簡略別名を入力します。

   expanded-alias

   この列には、拡張別名を入力します。

   option

   この列は、将来の拡張のために予約されています。

   comments

   この列は、別名など、個々の別名に関するコメントに使用します。

   オプション列をブランクにする場合は、空の引用符 2 つ ("") を入力し、そのあとにコメントを追加します。

   NIS+ mail_aliases テーブルでは、エントリの順序は重要ではありません。aliasadm -l コマンドがリストをソートし、エントリをアルファベット順に表示します。

   詳細は、「メール別名ファイル」および aliasadm(1M) のマニュアルページを参照してください。

NIS+ mail_aliases テーブルのエントリを編集する方法

テーブル内のエントリを編集するには、次の手順に従います。

1. テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 別名エントリを表示します。

   # aliasadm -m alias

   alias は、割り当てられている別名で置き換えます。

3. 必要に応じて別名エントリを編集します。

   # aliasadm -c alias expanded-alias [options comments]

   alias

   必要な場合は、別名を編集します。

   expanded-alias

   必要な場合は、拡張別名を編集します。

   options

   必要な場合は、オプションを編集します。

   comments

   必要な場合は、このエントリのコメントを編集します。

   詳細は、aliasadm(1M) のマニュアルページおよび 「メール別名ファイル」を参照してください。

4. 編集したエントリを表示し、エントリに間違いがないことを確認します。

   # aliasadm -m alias

   詳細は、aliasadm(1M) のマニュアルページを参照してください。

例 13–5 NIS+ mail_aliases テーブルからエントリを削除する

テーブルからエントリを削除するには、この手順の最初の手順の完了後、次の構文を入力します。

# aliasadm -d alias

alias は、削除するエントリの別名で置き換えます。

NIS mail.aliases マップを設定する方法

次の手順によって、NIS の mail.aliases マップを使って別名の設定を容易に行うことができます。

1. メールクライアント、メールボックスの場所、およびメールサーバーシステムの名前の各リストをコンパイルします。

2. NIS マスターサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

3. /etc/mail/aliases ファイルを編集し、次のようなエントリを作成します。

   1. メールクライアントごとにエントリを追加します。

      # cat /etc/mail/aliases .. alias:expanded-alias

      alias

      簡略別名を指定します。

      expanded-alias

      拡張別名 (user@host.domain.com) を指定します。

   2. Postmaster: root エントリがあることを確認します。

      # cat /etc/mail/aliases .. Postmaster: root

   3. root の別名を追加します。ポストマスターとして指定された個人のメールアドレスを使用します。

      # cat /etc/mail/aliases .. root: user@host.domain.com

      user@host.domain.com

      指定されたポストマスターに割り当てられているアドレスを指定します。

4. NIS マスターサーバーがネームサービスを実行中で、各メールサーバーのホスト名を解釈処理できることを確認します。

5. /var/yp ディレクトリに移動します。

   # cd /var/yp

6. make コマンドを適用します。

   # make

   /etc/hosts および /etc/mail/aliases ファイルの変更は、NIS スレーブシステムに伝達されます。変更は、遅くとも数分後には有効になります。

ローカルメール別名ファイルを設定する方法

ローカルメール別名ファイルで別名を解釈処理するには、次の手順に従います。

1. ユーザーとメールボックスの場所の各リストをコンパイルします。

2. メールサーバーのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

3. /etc/mail/aliases ファイルを編集し、次のようなエントリを作成します。

   1. ユーザーごとにエントリを追加します。

      user1: user2@host.domain

      user1

      新しい別名を指定します。

      user2@host.domain

      新しい別名の実際のアドレスを指定します。

   2. Postmaster: root エントリがあることを確認します。

      # cat /etc/mail/aliases .. Postmaster: root

   3. root の別名を追加します。ポストマスターとして指定された個人のメールアドレスを使用します。

      # cat /etc/mail/aliases .. root: user@host.domain.com

      user@host.domain.com

      指定されたポストマスターに割り当てられているアドレスを指定します。

4. 別名データベースを再構築します。

   # newaliases

   /etc/mail/sendmail.cf の AliasFile オプションの構成によって、このコマンドがバイナリ形式で、/etc/mail/aliases.db ファイルを 1 つ生成するか、または /etc/mail/aliases.dir と /etc/mail/aliases.pag の 1 組のファイルを生成するかが決まります。

5. 次の手順のどちらかを実行して、生成されたファイルをコピーします。

   1. (省略可能) /etc/mail/aliases、/etc/mail/aliases.dir、および /etc/mail/aliases.pag ファイルをほかの各システムにコピーします。

      rcp または rdist コマンドを使用して 3 つのファイルをコピーできます。詳細は、rcp(1) のマニュアルページまたは rdist(1) のマニュアルページを参照してください。また、この目的のためのスクリプトを作成することもできます。

      これらのファイルをコピーしたら、newaliases コマンドをほかの各システムで実行する必要はありません。ただし、メールクライアントを追加または削除するたびにすべての /etc/mail/aliases ファイルを更新する必要があるので注意してください。

   2. (省略可能) /etc/mail/aliases および /etc/mail/aliases.db ファイルをほかの各システムにコピーします。

      rcp または rdist コマンドを使用してこれらのファイルをコピーできます。詳細は、rcp(1) のマニュアルページまたは rdist(1) のマニュアルページを参照してください。また、この目的のためのスクリプトを作成することもできます。

      これらのファイルをコピーしたら、newaliases コマンドをほかの各システムで実行する必要はありません。ただし、メールクライアントを追加または削除するたびにすべての /etc/mail/aliases ファイルを更新する必要があるので注意してください。

キー付きマップファイルの作成方法

キー付きマップファイルを作成するには、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 入力ファイルを作成します。

   エントリには、次の構文を使用できます。

   old-name@newdomain.com new-name@newdomain.com old-name@olddomain.com error:nouser No such user here @olddomain.com %1@newdomain.com

   old_name@newdomain.com

   新たに割り当てたドメインでこれまで割り当てられていたユーザー名を指定します。

   new_name@newdomain.com

   新たに割り当てるアドレスを指定します。

   old_name@olddomain.com

   これまで割り当てられていたドメインでこれまで割り当てられていたユーザー名を指定します。

   olddomain.com

   これまで割り当てられていたドメインを指定します。

   newdomain.com

   新たに割り当てるドメインを指定します。

   1 番目のエントリにより、メールは新しい別名に転送されます。2 番目のエントリにより、不適切な別名が使用された時にメッセージが作成されます。最後のエントリにより、すべての着信メールは olddomain から newdomain へ転送されます。

3. データベースファイルを作成します。

   # /usr/sbin/makemap maptype newmap < newmap

   maptype

   dbm、btree、hash などのデータベースタイプを選択します。

   newmap

   入力ファイル名とデータベースファイル名の最初の部分を指定します。dbm データベースタイプを選択すると、データベースファイルは接尾辞に .pag または .dir を使って作成されます。ほかの 2 つのデータベースタイプの場合、ファイル名には .db が付きます。

postmaster 別名の管理

各システムは postmaster メールボックスにメールを送信できなければなりません。 postmaster の NIS または NIS+ 別名を作成できます。あるいは、ローカルの /etc/mail/aliases ファイルそれぞれに別名を作成することもできます。次の手順を参照してください。

• 「ローカルの各 /etc/mail/aliases ファイルに postmaster 別名を作成する方法」

• 「postmaster 用に別のメールボックスを作成する方法」

• 「postmaster メールボックスを /etc/mail/aliases ファイルの別名に追加する方法」

ローカルの各 /etc/mail/aliases ファイルに postmaster 別名を作成する方法

postmaster 別名をローカルの各 /etc/mail/aliases ファイルに作成する場合は、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/mail/aliases エントリを表示します。

   # cat /etc/mail/aliases # Following alias is required by the mail protocol, RFC 2821 # Set it to the address of a HUMAN who deals with this system's # mail problems. Postmaster: root

3. 各システムの /etc/mail/aliases ファイルを編集します。

   root をポストマスターに指定する個人のメールアドレスに変更します。

   Postmaster: mail-address

   mail-address

   ポストマスターとして指定された個人に割り当てられたアドレスを使用します。

4. (省略可能) ポストマスター用に別のメールボックスを作成します。

   ポストマスターがポストマスターメールと個人メールとを区別するために、別のメールボックスを作成できます。別のメールボックスを作成する場合は、/etc/mail/aliases ファイルを編集するときに、ポストマスターの個人メールアドレスではなくメールボックスアドレスを使用してください。詳細は、「postmaster 用に別のメールボックスを作成する方法」を参照してください。

postmaster 用に別のメールボックスを作成する方法

postmaster 用に別のメールボックスを作成する場合は、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. postmaster として指定された個人のアカウントを作成します。パスワードフィールドにアスタリスク (*) を入力します。

   ユーザーアカウントの追加の詳細については、『Solaris のシステム管理 (基本編)』の第 5 章「ユーザーアカウントとグループの管理 (手順)」を参照してください。

3. メールが配信されたら、mail プログラムがメールボックス名に読み書きできるようにします。

   # mail -f postmaster

   postmaster

   割り当てられているアドレスを指定します。

postmaster メールボックスを /etc/mail/aliases ファイルの別名に追加する方法

postmaster メールボックスを /etc/mail/aliases ファイル内の別名に追加する場合は、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. root の別名を追加します。ポストマスターとして指定された個人のメールアドレスを使用します。

   # cat /etc/mail/aliases .. root: user@host.domain.com

   user@host.domain.com

   ポストマスターとして指定された個人に割り当てられたアドレスを使用します。

3. ポストマスターのローカルシステムで、/etc/mail/aliases ファイルに別名の名前を定義するエントリを作成します。sysadmin が 1 例です。ローカルメールボックスへのパスも指定します。

   # cat /etc/mail/aliases .. sysadmin: /usr/somewhere/somefile

   sysadmin

   新しい別名の名前を作成します。

   /usr/somewhere/somefile

   ローカルメールボックスのパスを指定します。

4. 別名データベースを再構築します。

   # newaliases

キューディレクトリの管理 (作業マップ)

次の表では、メールキューの管理の手順を説明します。

キューディレクトリの管理

この節では、キューの管理に役立つ作業について説明します。クライアント専用のキューの詳細については、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。ほかの関連情報については、「sendmail の version 8.12 から追加されたキューの機能」を参照してください。

次を参照してください。

• 「メールキュー /var/spool/mqueue の内容を表示する方法」

• 「メールキュー /var/spool/mqueue でメールキューを強制処理する方法」

• 「メールキュー /var/spool/mqueue のサブセットを実行する方法」

• 「メールキュー /var/spool/mqueue を移動する方法」

• 「古いメールキュー /var/spool/omqueue を実行する方法」

メールキュー /var/spool/mqueue の内容を表示する方法

1. キューにあるメッセージの数とそれらのメッセージがキューから消去されるのにかかる時間を表示します。

   次の行を入力します。

   # /usr/bin/mailq | more

   このコマンドは、次の情報を表示します。

   • キュー ID

   • メッセージのサイズ

   • メッセージがキューに入った日付

   • メッセージの状態

   • 送信者と受信者

   さらに、このコマンドは、承認属性 solaris.admin.mail.mailq を確認します。確認が取れると、sendmail で -bp フラグを指定するのと同じ処理が実行されます。確認ができない場合は、エラーメッセージが表示されます。デフォルトでは、この承認属性はすべてのユーザーで使用できるようになっています。承認属性は、prof_attr 内のユーザーエントリを変更することにより無効にできます。詳細は、prof_attr(4) および mailq(1) のマニュアルページを参照してください。

メールキュー /var/spool/mqueue でメールキューを強制処理する方法

たとえば、以前にメッセージを受信できなかったシステムへのメッセージを処理するには、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. キューを強制処理し、キューが消去されるとジョブの進捗状況を表示します。

   # /usr/lib/sendmail -q -v

メールキュー /var/spool/mqueue のサブセットを実行する方法

たとえば、ホスト名など、アドレスの部分文字列を強制的に処理するには、次の手順に従います。また、特定のメッセージをキューから強制的に処理するにも、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. -qRstring を使用して、いつでもメールキューのサブセットを実行できます。

   # /usr/lib/sendmail -qRstring

   string

   受信者の別名または user@host.domain の部分文字列 (ホスト名など) を指定

   代わりに、-qInnnnn を使ってメールキューのサブセットを実行することもできます。

   # /usr/lib/sendmail -qInnnnn

   nnnnn

   キュー ID を指定します。

メールキュー /var/spool/mqueue を移動する方法

メールキューを移動する場合は、次の手順に従います。

1. メールホストのスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. sendmail デーモンを終了します。

   # svcadm disable network/smtp:sendmail

   これで、sendmail はキューディレクトリを処理しなくなります。

3. /var/spool ディレクトリに移動します。

   # cd /var/spool

4. mqueue ディレクトリとディレクトリ内のすべての内容を omqueue ディレクトリに移動します。次に、mqueue という名前の新しい空のディレクトリを作成します。

   # mv mqueue omqueue; mkdir mqueue

5. ディレクトリのアクセス権を所有者は読み取り/書き込み/実行に、またグループは読み取り/実行に設定します。また、所有者とグループを daemon に設定します。

   # chmod 750 mqueue; chown root:bin mqueue

6. sendmail を起動します。

   # svcadm enable network/smtp:sendmail

古いメールキュー /var/spool/omqueue を実行する方法

古いメールキューを実行するには、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 古いメールキューを実行します。

   # /usr/lib/sendmail -oQ/var/spool/omqueue -q

   -oQ フラグで、代替キューディレクトリを指定します。-q フラグで、キューのすべてのジョブを実行するように指示します。画面に冗長出力を表示する場合は、-v フラグを使用します。

3. 空のディレクトリを削除します。

   # rmdir /var/spool/omqueue

.forward ファイルの管理 (作業マップ)

次の表では、.forward ファイルを管理するための手順を説明します。詳細は、「.forward ファイル」の 第 14 章メールサービス (リファレンス)を参照してください。

.forward ファイルを管理する

この節では、.forward ファイルの管理に関する複数の手順を説明します。これらのファイルはユーザーが編集できるので、ファイルが問題の原因になる場合があります。詳細は、「.forward ファイル」の 第 14 章メールサービス (リファレンス)を参照してください。

次を参照してください。

• 「.forward ファイルを無効にする方法」

• 「.forward ファイルの検索パスを変更する方法」

• 「/etc/shells の作成および生成方法」

.forward ファイルを無効にする方法

自動転送を禁止し、特定のホストの .forward ファイルを無効にするには、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/mail/cf/domain/solaris-generic.m4 またはサイト固有のドメイン m4 ファイルのコピーを作成します。

   # cd /etc/mail/cf/domain # cp solaris-generic.m4 mydomain.m4

   mydomain

   選択するファイル名を指定します。

3. 次の行を作成したファイルに追加します。

   define(`confFORWARD_PATH',`')dnl

   m4 ファイルに confFORWARD_PATH の値がすでに存在する場合は、NULL 値に置き換えます。

4. 新しい構成ファイルを構築してインストールします。

   この手順の詳細については、「新しい sendmail.cf ファイルを構築する方法」を参照してください。

   ---

   注 –

   .mc ファイルを編集する場合は、忘れずに、DOMAIN(`solaris-generic') を DOMAIN(`mydomain ') に変更してください。

   ---

.forward ファイルの検索パスを変更する方法

たとえば、すべての .forward ファイルを共通ディレクトリに入れる場合は、次の手順に従います。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/mail/cf/domain/solaris-generic.m4 またはサイト固有のドメイン m4 ファイルのコピーを作成します。

   # cd /etc/mail/cf/domain # cp solaris-generic.m4 mydomain.m4

   mydomain

   選択するファイル名を指定します。

3. 次の行を作成したファイルに追加します。

   define(`confFORWARD_PATH',`$z/.forward:/var/forward/$u')dnl

   m4 ファイルに confFORWARD_PATH の値がすでに存在する場合は、新しい値に置き換えます。

4. 新しい構成ファイルを構築してインストールします。

   この手順の詳細については、「新しい sendmail.cf ファイルを構築する方法」を参照してください。

   ---

   注 –

   .mc ファイルを編集する場合は、忘れずに、DOMAIN(`solaris-generic') を DOMAIN(`mydomain ') に変更してください。

   ---

/etc/shells の作成および生成方法

このファイルは標準リリースには含まれていません。.forward ファイルを使用してプログラムまたはファイルにメールを転送することをユーザーに許可する場合は、このファイルを追加する必要があります。grep を使用して、パスワードファイルに一覧表示されたすべてのシェルを特定し、ファイルを手動で作成することができます。これにより、シェルをファイルに入力できます。しかし、次に示す、ダウンロード可能なスクリプトを使用する手順の方が簡単です。

1. スクリプトをダウンロードします。

   http://www.sendmail.org/vendor/sun/gen-etc-shells.html

2. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

3. シェルのリストを作成するために、gen-etc-shells を実行します。

   # ./gen-etc-shells.sh > /tmp/shells

   このスクリプトでは、getent コマンドを使用して、/etc/nsswitch.conf 内に一覧表示されたパスワードファイルソースに組み込まれたシェルの名前を収集します。

4. /tmp/shells 内のシェルのリストを調べて編集します。

   選択したエディタを使用し、組み込まないシェルを削除します。

5. ファイルを /etc/shells に移動します。

   # mv /tmp/shells /etc/shells

メールサービスの障害対処とヒント (作業マップ)

次の表では、メールサービスのトラブルシューティング手順とヒントを説明します。

メールサービスのトラブルシューティング手順とヒント

この節では、メールサービスの問題解決に使用できる手順とヒントをいくつか示します。

メール構成をテストする方法

構成ファイルに対して行なった変更をテストするには、次の手順に従います。

1. 変更した構成ファイルがあるシステムで sendmail を再起動します。

   # svcadm refresh network/smtp:sendmail

2. 各システムからテストメッセージを送信します。

   # /usr/lib/sendmail -v names </dev/null

   names

   受信者の電子メールアドレスを指定します。

   このコマンドは、指定された受信者に NULL メッセージを送信し、画面にメッセージの動作を表示します。

3. メッセージを通常のユーザー名に送ることによって、メールを自分自身またはローカルシステム上のほかの人に送信します。

4. (省略可能) ネットワークに接続している場合は、別のシステムの個人宛に次の 3 方向でメールを送信します。

   • メインシステムからクライアントシステムへ

   • クライアントシステムからメインシステムへ

   • クライアントシステムから別のクライアントシステムへ

5. (省略可能) メールゲートウェイがある場合、メールホストから別のドメインにメールを送信して、中継メールプログラムおよびホストが適切に設定されていることを確認します。

6. (省略可能) 電話回線上で別のホストへの UUCP 接続を設定している場合は、そのホストのだれかにメールを送信します。メッセージを受信した時点で、メールを返信してもらうか、電話してもらいます。

7. UUCP 接続を介してメールを送信するようにほかの人に頼みます。

   sendmail プログラムは、メッセージが配信されたかどうかは検出しません。これは、配信のためにプログラムがメッセージを UUCP に渡すためです。

8. 異なるシステムからメッセージを postmaster 宛てに送信し、ポストマスターのメールボックスにそのメッセージが配信されたことを確認します。

メール別名を確認する方法

次の例は、別名を確認する方法を示します。

% mconnect
connecting to host localhost (127.0.0.1), port 25
connection open
220 your.domain.com ESMTP Sendmail 8.13.6+Sun/8.13.6; Tue, 12 Sep 2004 13:34:13 -0800 (PST)
expn sandy
250 2.1.5 <sandy@phoenix.example.com>
quit
221 2.0.0 your.domain.com closing connection
% 

この例では、mconnect プログラムがローカルホスト上のメールサーバーとの接続を確立し、接続をテストできるようにします。プログラムは対話式で実行されるので、さまざまな診断コマンドを実行できます。詳細は、mconnect(1) のマニュアルページを参照してください。expn sandy のエントリに、展開されたアドレス sandy@phoenix.example.com が示されています。したがって、別名 sandy でメールを配信できることが確認されました。

ローカルおよびドメインの両方で別名を使用する場合は、ループやデータベースの不整合が生じないようにしてください。あるシステムから別のシステムにユーザーを移動するときは、別名のループが生じないよう特に注意してください。

sendmail ルールセットをテストする方法

sendmail ルールセットの入力と戻りを確認するには、次の手順に従います。

1. アドレステストモードに変更します。

   # /usr/lib/sendmail -bt

2. メールアドレスをテストします。

   最後のプロンプト (>) で次の数値とアドレスを入力します。

   > 3,0 mail-sraddress

   mail-address

   テストするメールアドレスを指定します。

3. セッションを終了します。

   Control-D キーを押します。

例 13–6 アドレステストモードの出力

次にアドレステストモードの出力例を示します。

% /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 sandy@phoenix
canonify           input: sandy @ phoenix
Canonify2          input: sandy < @ phoenix >
Canonify2        returns: sandy < @ phoenix . example . com . >
canonify         returns: sandy < @ phoenix . example . com . >
parse              input: sandy < @ phoenix . example . com . >
Parse0             input: sandy < @ phoenix . example . com . >
Parse0           returns: sandy < @ phoenix . example . com . >
ParseLocal         input: sandy < @ phoenix . example . com . >
ParseLocal       returns: sandy < @ phoenix . example . com . >
Parse1             input: sandy < @ phoenix . example . com . >
MailerToTriple     input: < mailhost . phoenix . example . com > 
     sandy < @ phoenix . example . com . >
MailerToTriple   returns: $# relay $@ mailhost . phoenix . example . com 
     $: sandy < @ phoenix . example . com . >
Parse1           returns: $# relay $@ mailhost . phoenix . example . com 
     $: sandy < @ phoenix . example . com . >
parse            returns: $# relay $@ mailhost . phoenix . example . com 
     $: sandy < @ phoenix . example . com . >

ほかのシステムへの接続を調べる方法

mconnect プログラムは、指定したホスト上のメールサーバーへの接続を開き、接続をテストできるようにします。プログラムは対話式で実行されるので、さまざまな診断コマンドを実行できます。詳細は、mconnect(1) のマニュアルページを参照してください。次の例では、ユーザー名 sandy へのメールが配信可能かどうかを調べます。

% mconnect phoenix

connecting to host phoenix (172.31.255.255), port 25
connection open
220 phoenix.example.com ESMTP Sendmail 8.13.1+Sun/8.13.1; Sat, 4 Sep 2004 3:52:56 -0700
expn sandy
250 2.1.5 <sandy@phoenix.example.com>
quit

mconnect を使用して SMTP ポートに接続できない場合は、次の条件を確認してください。

• システム負荷が高すぎないか

• sendmail デーモンが動作しているか

• システムに適切な /etc/mail/sendmail.cf ファイルがあるか

• sendmail が使用するポート 25 がアクティブであるか

エラーメッセージの記録

メールサービスは、syslogd プログラムを使って大部分のエラーメッセージを記録します。デフォルトでは、syslogd プログラムはこれらのメッセージを /etc/hosts ファイルで指定されている loghost というシステムに送信します。loghost が NIS ドメイン全体のすべてのログを保持するように定義できます。loghost を指定しなければ、syslogd からのエラーメッセージはレポートされません。

/etc/syslog.conf ファイルは、syslogd プログラムがメッセージをどこに転送するかを制御します。/etc/syslog.conf ファイルを編集することにより、デフォルト構成を変更できます。変更内容を有効にするには、syslog デーモンを再起動する必要があります。メールに関する情報を収集するために、ファイルに次の選択を追加できます。

• mail.alert – ここで訂正する必要のある状態に関するメッセージ

• mail.crit – クリティカルメッセージ

• mail.warning – 警告メッセージ

• mail.notice – エラーではないが注意すべきメッセージ

• mail.info – 情報メッセージ

• mail.debug – デバッグメッセージ

/etc/syslog.conf ファイルの次のエントリは、クリティカルメッセージ、通知メッセージ、デバッグメッセージをすべて /var/log/syslog に送信します。

mail.crit;mail.info;mail.debug			/var/log/syslog

システムログの各行には、タイムスタンプ、そのログ行を生成したシステム名、およびメッセージが入っています。syslog ファイルは、大量の情報を記録できます。

ログは、連続したレベルとして並べられます。最下位レベルでは、異常なイベントだけが記録されます。最上位レベルでは、もっとも必須なイベントと注目する必要のないイベントが記録されます。通常、10 以下のログレベルが「有用」とみなされます。10 を超えるログレベルは通常、デバッグに使用されます。loghost および syslogd プログラムの詳細については、 『Solaris のシステム管理 (上級編)』の「システムのメッセージ記録のカスタマイズ」を参照してください。

メール診断情報のその他の情報源

その他の診断情報については、次の情報源を確認してください。

• メッセージのヘッダーの Received 行を調べます。これらの行は、メッセージが中継されるときにとった経路を追跡できます。時間帯の違いを考慮するのを忘れないでください。

• MAILER-DAEMON からのメッセージを調べます。これらのメッセージは通常、配信上の問題をレポートします。

• ワークステーショングループの配信上の問題を記録するシステムログを確認します。sendmail プログラムは常に、その処理内容をシステムログに記録します。crontab ファイルを修正して、シェルスクリプトを夜間に実行できます。このスクリプトは、ログで SYSERR メッセージを検索し、検出したメッセージをポストマスターにメールで送信します。

• mailstats プログラムを使ってメールタイプをテストし、着信メッセージと発信メッセージの数を判定します。

エラーメッセージの解釈

この節では、sendmail 関連のエラーメッセージを解釈し対処する方法について説明します。http://www.sendmail.org/faq/ も参照してください。

次のエラーメッセージには、次の種類の情報が含まれます。

• 原因 : メッセージ発生の原因となった可能性があるもの

• 説明 : エラーメッセージが発生した時にユーザーが行なっていた操作

• 対処方法 : 問題を解決するため、あるいは作業を続けるための操作

451 timeout waiting for input during source

原因:

タイムアウトの可能性があるソース (SMTP 接続など) から読み取るとき、sendmail は、読み込みを開始する前にさまざまな Timeout オプションの値をタイマーに設定します。タイマーが期限切れになる前に読み取りが完了しなかった場合、このメッセージが表示され、読み取りが停止します。通常、この状況は RCPT 時に発生します。メールメッセージはキューに入れられて、あとで配信されます。

対処方法:

このメッセージが頻繁に表示される場合は、/etc/mail/sendmail.cf ファイルの Timeout オプションの値を大きくします。タイマーがすでに大きな値に設定されている場合は、ネットワークの配線や接続などハードウェアの問題点を探します。

550 hostname... Host unknown

原因:

この sendmail のメッセージは、単価記号 (@) のあとのアドレス部分で指定されている受信先のホストマシンが、ドメインネームシステム (DNS) ルックアップ時に見つからなかったことを示します。

対処方法:

nslookup コマンドを使用して、受信先ホストが、そのドメインまたはほかのドメインにあることを確認します。スペルが間違っている可能性があります。あるいは、受信者に連絡して正しいアドレスを確認します。

550 username... User unknown

原因:

この sendmail のメッセージは、単価記号 (@) の前のアドレス部分で指定されている受信者を受信先ホストマシンで検出できなかったことを示します。

対処方法:

電子メールアドレスを確認し、再度送信してみます。スペルが間違っている可能性があります。これで解決しない場合は、受信者に連絡して正しいアドレスを確認します。

554 hostname... Local configuration error

原因:

この sendmail メッセージは通常、ローカルホストがメールを自分宛に送信しようとしていることを示します。

対処方法:

/etc/mail/sendmail.cf ファイル内の $j マクロの値が完全指定ドメイン名になっていることを確認します。

説明:

送信側のシステムが SMTP の HELO コマンドで受信側のシステムに自身のホスト名を示すと、受信側のシステムはそのホスト名を送信者の名前と比較します。これらの名前が同じ場合、受信側のシステムはこのエラーメッセージを発行し、接続を閉じます。HELO コマンドで提供される名前は、$j マクロの値です。

追加情報については、http://www.sendmail.org/faq/section4#4.5 を参照してください。

config error: mail loops back to myself.

原因:

このエラーメッセージが生成されるのは、MX レコードを設定し、ホスト bar をドメイン foo のメール交換局にした場合です。ただし、ホスト bar 自身がドメイン foo のメール交換局であることを認識するように設定されていません。

また、送信側システムと受信側システムの両方が同じドメインとして識別される場合にも、このメッセージを受け取ります。

対処方法:

手順については、http://www.sendmail.org/faq/section4#4.5 を参照してください。

host name configuration error

説明:

これは sendmail の古いメッセージで、「I refuse to talk to myself」というメッセージから置き換えられたもので現在は、「Local configuration error」メッセージに置き換えられています。

対処方法:

次のエラーメッセージの対処方法で説明されている手順に従います。554 hostname... Local configuration error.

user unknown

原因:

メールをユーザー宛てに送信しようとすると、「Username... user unknown」のエラーが表示されます。ユーザーが同じシステム上にいます。

対処方法:

入力した電子メールアドレスに誤字がないか確認します。あるいは、ユーザーが、/etc/mail/aliases またはユーザーの .mailrc ファイルに存在しない電子メールアドレスに別名を割り当てられている可能性があります。また、ユーザー名の大文字も確認してください。できれば、電子メールアドレスは大文字と小文字が区別されないようにします。

追加情報については、http://www.sendmail.org/faq/section4#4.17 を参照してください。

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

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

• 「Solaris 版の sendmail」

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

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

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

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

• 「sendmail の version 8.13 での変更点」

• 「sendmail の version 8.12 からの変更点」

上記の章で説明されていない内容については、次のマニュアルページを参照してください。

• sendmail(1M)

• mail.local(1M)

• mailstats(1)

• makemap(1M)

• editmap(1M)

Solaris 版の sendmail

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

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

• 「MILTER (sendmail のメールフィルタ API)」

• 「sendmail の代替コマンド」

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

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

Solaris 10 以降のリリースで sendmail のコンパイルに使用されるフラグは、次のとおりです。構成にほかのフラグが必要な場合は、そのソースをダウンロードし、バイナリにコンパイルし直してください。このプロセスについては、http://www.sendmail.org を参照してください。

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

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

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

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

MILTER (sendmail のメールフィルタ API)

MILTER (sendmail のメールフィルタ API ) によって、サードパーティー製のプログラムが、メタ情報と本文にフィルタをかけるために処理されるときに、メールメッセージにアクセスできるようになります。フィルタを作成する必要や、作成したフィルタを使用するように sendmailを構成する必要はありません。この API は、sendmail の version 8.13 ではデフォルトで有効になっています。

詳細は、次を参照してください。

• http://www.sendmail.org

• https://www.milter.org/

sendmail の代替コマンド

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

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

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

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

作業手順については、第 13 章メールサービス (手順)の 「sendmail 構成を変更する」を参照してください。

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

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

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

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

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

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

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

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

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

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

• 「メールプログラムと sendmail」

• 「メールアドレス」

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

• 「メール別名」

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

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

• /usr/bin/mail

• /usr/bin/mailx

• /usr/dt/bin/dtmail

メール転送エージェント

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

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

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

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

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

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

「ローカル配信エージェント」は、メールの配信プロトコルを実行するプログラムです。Solaris オペレーティングシステムには、次のローカル配信エージェントが提供されています。

• UUCP ローカル配信エージェント (uux を使ってメールを配信する)

• ローカル配信エージェント (標準の Solaris リリースでは mail.local)

「sendmail の version 8.12 からの変更点」 では、次の関連項目について説明します。

• 「sendmail の version 8.12 から追加された配信エージェントのフラグ」

• 「sendmail の version 8.12 から追加された配信エージェントの設定」

メールプログラムと sendmail

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

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

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

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

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

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

• smtp は、ほかのサーバーへの標準 SMTP 転送機能を提供します。

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

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

• dsmtp は、F=% メールプログラムフラグを使ってオンデマンド配信機能を提供します。「sendmail の version 8.12 からの MAILER() の宣言についての変更点」と 「sendmail の version 8.12 から追加された配信エージェントのフラグ」を参照してください。

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

UUCP の使用は、できるだけ避けてください。説明については、http://www.sendmail.org/m4/uucp_mailers.html を参照するか、/etc/mail/cf/README で USING UUCP MAILERS という文字列を検索してください。

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

uucp-old

$=U クラスの名前が uucp-old に送られます。suucp は、このメールプログラムの以前の名前です。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 つ以上の「サブドメイン」を持つことができます。アドレスのドメインとサブドメインは、ファイルシステムの階層と比較できます。サブディレクトリが上位のディレクトリに含まれるように、メールアドレスの各サブドメインもその右のドメインに含まれると考えられます。

次の表に最上位のドメインを示します。

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

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

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

• 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)

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

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

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

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

user@host.domain

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

host.domain!user

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

user@domain

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

メールボックスファイル

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

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

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

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

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

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

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

メール別名

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

大きなサイトでは通常、メール別名は、メールボックスの場所を定義します。メール別名を提供することは、複数の部屋を占有する大きな会社の個人のアドレスに部屋番号を含めるようなものです。部屋番号を提供しない場合は、メールは中央アドレスに配信されます。部屋番号がなければ、ビルの内部のどこにメールを配信するかを特定するために余分な労力が必要になります。そして、誤りが発生する可能性も増加します。たとえば、同じ建物に 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 を追加します。または、ネームサービスのホストファイルに mailhost を同じように追加することもできます。作業手順については、「メールホストを設定する方法」の 第 13 章メールサービス (手順)を参照してください。

メールホストの候補は、ネットワークからグローバルなインターネットネットワークへのルーターとして構成されたシステムです。詳細は、第 15 章Solaris PPP 4.0 (概要)、第 24 章UUCP (概要)、および『Solaris のシステム管理 (IP サービス)』の「IPv4 ルーターの構成」を参照してください。ローカルネットワークのどのシステムにもモデムがない場合は、システムの 1 つをメールホストに指定します。

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

メールサーバー

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

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

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

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

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

メールクライアント

「メールクライアント」は、メールサーバー上にメールボックスを持っている、メールサービスのユーザーです。メールクライアントにはさらに、/etc/mail/aliases ファイルで、メールボックスの位置を示すメール別名が設定されています。作業手順については、「メールクライアントを設定する方法」の 第 13 章メールサービス (手順)を参照してください。

メールゲートウェイ

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

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

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

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

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

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

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

• 「vacation ユーティリティーの拡張機能」

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

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

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

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

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

• 「sendmail プログラム」

• 「メール別名ファイル」

• 「.forward ファイル」

• 「/etc/default/sendmail ファイル」

vacation ユーティリティーの拡張機能

Solaris 10 以降のリリースでは、vacation ユーティリティーが機能強化され、自動生成された応答をどの着信メッセージが受けるかをユーザーが指定できるようになりました。この拡張機能により、ユーザーは、知らない人と機密情報や連絡先を共有せずにすみます。スパマーや知らない人からのメッセージは、応答を受け取りません。

この拡張機能は、着信電子メールの送信者のアドレスを .vacation.filter ファイル内のドメインまたは電子メールアドレスのリストと付き合わせることによって機能します。このファイルは、ユーザーによって作成され、ユーザーのホームディレクトリにあります。ドメインまたは電子メールアドレスで一致するものがあると、応答が送られます。一致するものがなければ、応答は送られません。

.vacation.filter には、次のようなエントリが含まれます。

company.com
mydomain.com
onefriend@hisisp.com
anotherfriend@herisp.com

各行には、1 つのドメインまたは 1 つの電子メールアドレスが含まれます。1 つのエントリを 1 行に入力する必要があります。送信者の電子メールアドレスが電子メールアドレスエントリと一致するには、大文字と小文字の違いを除いて、完全に一致している必要があります。送信者のアドレスの文字が小文字であるか大文字であるかは無視されます。送信者の電子メールアドレスがドメインエントリと一致するには、一覧表示されているドメインに送信者のアドレスが含まれている必要があります。たとえば、somebody@dept.company.com と someone@company.com の両方が、company.com のドメインエントリと一致します。

詳細は、vacation(1) のマニュアルページを参照してください。

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

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

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

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

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

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

Solaris 10 以降のリリースでは、読み取り専用の /usr ファイルシステムをサポートするために、/usr/lib/mail ディレクトリの内容が /etc/mail/cf ディレクトリに移動されました。ただし、例外があります。シェルスクリプト /usr/lib/mail/sh/check-hostname および /usr/lib/mail/sh/check-permissions は、/usr/sbin ディレクトリに置かれるようになりました。「メールサービスに使用するその他のファイル」を参照してください。下位互換性を確保するために、シンボリックリンクが各ファイルの新しい位置を示します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sendmail プログラム

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

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

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

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

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

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

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

  • 異種の命名スキーム。

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

• sendmail は、mail.local や procmail などのローカル配信エージェントとの間で、電子メールメッセージの受信や配信を行う役割を果たします。

• sendmail はメール転送エージェントであり、mailx や Mozilla Mail などのユーザーエージェントからメッセージを受け取り、そのメッセージをインターネット経由でその宛先までルーティングします。

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

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

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

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

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

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

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

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

• 「sendmail プログラムの機能」

• 「sendmail 構成ファイル」

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

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

• サーバーの変更

• ドメイン全体の変更

• 単独のユーザーの変更

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • 別のメールボックス

   • 別のメールプログラム

   • 別のメールホスト

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

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

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

   ---

   注 –

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

   ---

sendmail プログラムの機能

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

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

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

• sendmail は、複数のネットワークなど、複雑な環境を処理するように構成できます。sendmail は、アドレスとその構文の内容を確認し、どのメールプログラムを使用するかを判断します。

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

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

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

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

sendmail 構成ファイル

「構成ファイル」は、sendmail がその機能を実行する方法を制御します。構成ファイルにより、配信エージェント、アドレスの変換の規則、およびメールヘッダーのフォーマットが選択されます。sendmail プログラムは、/etc/mail/sendmail.cf ファイルの情報を使用して、その機能を実行します。

Solaris オペレーティングシステムには、/etc/mail ディレクトリに次の 2 つのデフォルト構成ファイルがあります。

1. デーモンモードで sendmail を実行するために使用する sendmail.cf 構成ファイル。

2. デーモンモードの代わりにメール配信プログラムモードで sendmailを実行するために使用する submit.cf 構成ファイル。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。

メールクライアント、メールサーバー、メールホスト、メールゲートウェイを設定するときは、次を考慮してください。

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

• メールホストやメールゲートウェイを設定するには、メール設定に必要な中継メールプログラムおよび中継ホストのパラメータを設定します。作業手順については、「メールサービスの設定 (作業マップ)」の 「sendmail 構成を変更する」または 第 13 章メールサービス (手順)を参照してください。sendmail version 8.13 では、main.cf ファイルは必要ありません。

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

• 次の情報を指定する時間値。

  • 読み取りのタイムアウト。

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

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

• ビジー期間中の効率を高めるためのロード制限。これらのパラメータは、sendmail が、長いメッセージ、多くの受信者へのメッセージ、および長時間ダウンしているサイトへのメッセージを配信しないようにします。

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

メール別名ファイル

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

• 「.mailrc の別名」

• 「/etc/mail/aliases ファイル」

• 「NIS aliases マップ」

• 「NIS+ mail_aliases テーブル」

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

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

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

現在のホスト名やホスト名なしなどのローカル名のみに別名を作成できます。たとえば、システム saturn にメールボックスのあるユーザー ignatz の別名エントリには、/etc/mail/aliases ファイルの次のエントリが入ります。

ignatz: ignatz@saturn

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

通常は、root ユーザーだけがこのファイルを編集できます。ただし、Solaris 管理コンソールを使用する場合は、sysadmin グループであるグループ 14 のすべてのユーザーが、ローカルファイルを変更できます。または、次のエントリを作成します。

aliasname: :include:/path/aliasfile

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

user1@host1
user2@host2

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

aliasname: /home/backup/filename

また、ほかのプロセスにメールを回送することもできます。次の例のように入力すると、メールメッセージのコピーが filename 内に格納され、コピーがプリントされます。

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

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

NIS aliases マップ

ローカルドメインのすべてのユーザーは、NIS aliases マップのエントリを使用できます。sendmail プログラムは、ローカルの /etc/mail/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 ファイルを含むサーバー用のホスト名です。

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

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

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

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

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

.forward ファイル

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

• 「回避すべき状況」

• 「.forward ファイルの制御」

• 「.forward.hostname ファイル」

• 「.forward+detail ファイル」

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

回避すべき状況

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

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

• セキュリティーの問題を予防するために、root または bin アカウントに .forward ファイルを決して置かないでください。必要な場合は、代わりに 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 とネームサービス」

• 「NIS と sendmail との相互作用」

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

• 「NIS+ と sendmail との相互作用」

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

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

sendmail.cf とメールドメイン

標準の sendmail.cf ファイルは、メールドメインを使ってメールを直接配信するか、あるいはメールホストを経由して配信するかを決定します。ドメイン内メールは直接 SMTP 接続経由で配信され、ドメイン間メールはメールホストに送られます。

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

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

• メールホストは、パケットを外部ホストに直接送信できる認可されたホストにメールを転送できる。実際には、メールホストが認可されたホストになることがある。

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

sendmail とネームサービス

sendmail は各種の要件をネームサービスに課します。これらの要件の理解を深めるために、この節では、まずメールドメインからネームサービスドメインへの関係について説明します。その次に個々の要件について説明します。次を参照してください。

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

• 「ネームサービスの要件」

• 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) のマニュアルページを参照してください。

NIS と sendmail との相互作用

次に、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 との相互作用

次に、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 章メールサービス (手順)を参照してください。

NIS+ と sendmail との相互作用

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

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

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

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

• 完全なホスト名 – NIS+ は完全なホスト名を「理解」します。通常の NIS+ の設定手順を行えば、この完全なホスト名の要件は満たされます。

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

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

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

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

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

• メールドメイン名 – プライマリネームサービスとして NIS+ を設定していれば、sendmail は NIS+ の sendmailvars テーブルからメールドメインを確認できます。この NIS+ テーブルには、キー列と値列が 1 つずつあります。メールドメインを設定するには、 1 つのエントリをこのテーブルに追加する必要があります。このエントリは、キー列に文字列 maildomain が、値列には自分のメールドメイン名が設定されている必要があります。たとえば、admin.acme.com です。NIS+ では、sendmailvars テーブルにどのような文字列でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomain エントリを 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 ドメイン – この要件を満たすには、すべてのホストテーブルのエントリをコピーします。または、ユーザーネームサービスのドメイン中の全ホストのエントリを、メールドメインレベルのマスターホストテーブルに入力します。

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

sendmail の version 8.13 での変更点

sendmail のこの新しいバージョンには多くの新機能が用意されていますが、FallBackSmartHost オプションがもっとも重要な追加機能です。このオプションにより、main.cf ファイルおよび subsidiary.cf ファイルを使用する必要がなくなります。main.cf ファイルは、MX レコードをサポートする環境で使用されていました。subsidiary.cf ファイルは、完全に動作する DNS がない環境で使用されていました。そのような環境では、スマートホストが MX レコードの代わりに使用されていました。FallBackSmartHost オプションは、統一された構成を提供します。このオプションは、すべての環境でもっとも優先順位の低い MX レコードのように動作します。このオプションは、有効である場合、メールが確実にクライアントに配信されるように、失敗した MX レコードのバックアップ (フェイルオーバー) として担う接続が保たれた (スマート) ホストを提供します。

version 8.13 の詳細については、次の各節を参照してください。

• 「sendmail の version 8.13 で追加されたコマンド行オプション」

• 「sendmail の version 8.13 で追加または改訂された構成ファイルオプション」

• 「sendmail の version 8.13 で追加または改訂された FEATURE() の宣言」

さらに、Solaris 10 1/06 以降のリリースでは、TLS (Transport Layer Security) を使用して SMTP を実行できます。次に説明します。

sendmail の version 8.13 で TLS を使用して SMTP を実行するためのサポート

SMTP サーバーとそのクライアント間の通信は通常、どちらの側でも制御されたり信頼されたりしません。このようにセキュリティーが存在しないことにより、第三者は、サーバーとクライアントの間の通信を監視し、変更することさえ可能です。Solaris 10 1/06 以降のリリースでは、SMTP は sendmail の version 8.13 で Transport Layer Security (TLS) を使用して、この問題を解決できます。これにより SMTP サーバーおよびクライアントに対するサービスが拡張され、次の機能が実現されます。

• インターネットでの機密性の高い認証された通信

• 盗聴や攻撃からの保護

TLS の実装は Secure Sockets Layer (SSL) プロトコルに基づいています。

STARTTLS は、TLS を使用して、セキュリティー保護された SMTP 接続を開始する SMTP キーワードです。このセキュリティー保護された接続は、2 台のサーバーの間、またはサーバーとクライアントの間で行われます。セキュリティー保護された接続は、次のように定義されます。

• 発信元電子メールアドレスと宛先電子メールアドレスが暗号化される。

• 電子メールメッセージの内容が暗号化される。

クライアントが STARTTLS コマンドを発行すると、サーバーは次のいずれかを使用して応答します。

• 220 Ready to start TLS

• 501 Syntax error (no parameters allowed)

• 454 TLS not available due to temporary reason

220 応答では、クライアントが TLS ネゴシエーションを開始する必要があります。501 応答は、クライアントが STARTTLS コマンドを正しく発行しなかったことを示します。STARTTLS はパラメータなしで発行されます。454 応答では、クライアントがルールセットの値を適用して、接続を受け入れるか維持するかどうかを決定する必要があります。

インターネットの SMTP インフラストラクチャーを維持するため、公的に使用されるサーバーは TLS ネゴシエーションを要求してはならないことに注意してください。ただし、私的に使用されるサーバーは、クライアントが TLS ネゴシエーションを実行するよう要求しても構いません。このような場合、サーバーは次のような応答を返します。

530 Must issue a STARTTLS command first

530 応答は、 STARTTLS コマンドを発行して接続を確立するようクライアントに指示します。

認証とプライバシーのレベルが不十分である場合、サーバーまたはクライアントは接続を拒否できます。また、多くの SMTP 接続はセキュリティー保護されていないため、サーバーとクライアントはセキュリティー保護されていない接続を維持する場合があります。接続を維持するか拒否するかどうかは、サーバーとクライアントの構成により決まります。

TLS を使用して SMTP を実行するためのサポートは、デフォルトでは有効になっていません。TLS が有効になるのは、SMTP クライアントが STARTTLS コマンドを発行した場合です。SMTP クライアントがこのコマンドを発行する前に、sendmail が TLS を使用できるようにする証明書を設定する必要があります。「TLS を使用するよう SMTP を構成する」を参照してください。この手順には、新しい構成ファイルのオプションの定義と、sendmail.cf ファイルの再構築が含まれることに注意してください。

TLS を使用して SMTP を実行するための構成ファイルのオプション

次の表で、TLS を使用して SMTP を実行するために使用される構成ファイルのオプションを説明します。これらのオプションを宣言する場合は、次の構文のどれかを使用します。

• O OptionName=argument # 構成ファイル用

• -O OptionName=argument # コマンド行用

• define(`m4Name',argument) # m4 構成用

sendmail で SMTP による TLS の使用をサポートできるようにするには、次のオプションを定義してください。

• CACertPath

• CACertFile

• ServerCertFile

• ClientKeyFile

そのほかのオプションは必須ではありません。

TLS を使用して SMTP を実行するためのマクロ

次の表で、STARTTLS コマンドにより使用されるマクロを説明します。

TLS を使用して SMTP を実行するためのルールセット

次の表で、TLS を使用する SMTP 接続を、受け入れるか、継続するか、拒否するかを決定するルールセットを説明します。

詳細は、http://www.sendmail.org/m4/starttls.html を参照してください。

TLS を使用した SMTP の実行に関連するセキュリティーの検討事項

インターネットで動作するメールプログラムを定義する標準メールプロトコルとしては、SMTP はエンドツーエンドのメカニズムではありません。このプロトコルの制限により、SMTP を介した TLS のセキュリティーにはメールユーザーエージェントは含まれていません。メールユーザーエージェントは、ユーザーと (sendmail などの) メール転送エージェントの間のインタフェースとして動作します。

また、メールは複数のサーバーを経由してルーティングされる場合があります。SMTP のセキュリティーを完全にするには、SMTP 接続のチェーン全体に TLS のサポートが必要です。

最終的には、サーバーの各ペア、またはクライアントとサーバーのペアの間でネゴシエーションされる認証と機密性のレベルを考慮すべきです。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「認証サービス」を参照してください。

sendmail の version 8.13 で追加されたコマンド行オプション

次の表に、sendmail の version 8.13 で追加されたコマンド行オプションを示します。コマンド行のほかのオプションについては、sendmail(1M) のマニュアルページを参照してください。

sendmail の version 8.13 で追加または改訂された構成ファイルオプション

次の表に、追加または改訂された構成ファイルオプションを示します。これらのオプションを宣言する場合は、次の構文のどれかを使用します。

O OptionName=argument          # for the configuration file
-O OptionName=argument         # for the command line
define(`m4Name',argument)     # for m4 configuration