このパートでは、メールサービスの概要、作業、およびリファレンス情報について説明します。
電子メールサービスの設定と維持管理には、ネットワークの日常の運用にとって不可欠な、複雑な作業が伴います。ネットワーク管理者は、既存のメールサービスを拡張しなければならない場合があります。または、新しいネットワークまたはサブネット上でメールサービスを設定しなければならないこともあります。メールサービスに関する各章では、ネットワークでメールサービスを計画したり設定したりするために必要な情報を提供します。この章では、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 以降のリリースでは、sendmail は Transport Layer Security (TLS) を使用した SMTP をサポートしています。詳細については、次を参照してください。
Solaris 06 10/9 リリースに含まれる新機能の完全な一覧については、『Oracle Solaris 10 9/10 の新機能』を参照してください。
Solaris 10 以降のリリースでは、sendmail version 8.13 がデフォルトになっています。version 8.13 に関する情報とほかの変更点については、次を参照してください。
さらに、メールサービスは、サービス管理機能によって管理されています。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。サービスの状態は、svcs コマンドを使用して照会できます。サービス管理機能の詳細は、smf(5) のマニュアルページおよび『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。
次に、上記以外の 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/
メールサービスを確立するためには、多くのソフトウェアコンポーネントおよびハードウェアコンポーネントが必要になります。次では、これらのコンポーネントについて簡単に紹介します。コンポーネントの説明で使用する用語についても紹介します。
最初の節 「ソフトウェアコンポーネントの概要」では、メール配信システムのソフトウェア部分を説明するのに使用する用語を定義します。その次の節 「ハードウェアコンポーネントの概要」では、メール構成におけるハードウェアシステムの機能について取り上げます。
次の表にメールシステムのソフトウェアコンポーネントを示します。ソフトウェアコンポーネントすべてに関する詳細については、「ソフトウェアコンポーネント」を参照してください。
コンポーネント |
説明 |
---|---|
.forward ファイル |
ユーザーのホームディレクトリ内で設定して、メールを自動的にリダイレクトしたり、プログラムに送ったりすることができるファイル |
メールボックス |
メールサーバー上にあり、電子メールメッセージの最終受信先であるファイル |
メールアドレス |
メールメッセージが配信される受信者とシステムの名称を含むアドレス |
メール別名 |
メールアドレス内で使用されている代替名 |
メールキュー |
メールサーバーによる処理を必要とするメールメッセージの集まり |
ポストマスター |
メールサービスについての問題を報告し質問を出すために使用される特別なメール別名 |
sendmail 構成ファイル |
メールのルーティングに必要なすべての情報の入ったファイル |
メール構成では次の 3 つの要素が必要ですが、これらは同じシステムで組み合わせることも、別のシステムで提供することもできます。
メールホスト – 解釈処理が困難なメールアドレスを扱うように構成されたシステム
少なくとも 1 台のメールサーバー – 1 つまたは複数のメールボックスを保持するように構成されたシステム
メールクライアント – メールサーバーからメールにアクセスするシステム
ユーザーがドメイン外のネットワークと通信をするためには、4 番目の要素であるメールゲートウェイを追加する必要があります。
図 12–1 には、一般的な電子メール構成を示しますが、ここでは基本的な 3 つのメール要素とメールゲートウェイが使用されています。
各要素については、「ハードウェアコンポーネント」を参照してください。
この章ではメールサービスを設定し、管理する方法について説明します。メールサービスの管理に詳しくない場合は、メールサービスのコンポーネントを紹介している第 12 章メールサービス (概要)を参照してください。この章では、一般的なメールサービス構成についても説明しています (図 12–1 を参照)。この章では、次の関連作業について説明します。
メールサービスのコンポーネントについての詳細は、第 14 章メールサービス (リファレンス)を参照してください。また、この章では、メールサービスのプログラムとファイル、メールルーティング処理、ネームサービスを使った sendmail の対話型操作、sendmail(1M) のマニュアルページで十分に説明されていない sendmail の version 8.13 での機能についても説明します。
次の表から、具体的な一連の手順を扱っているほかの作業マップがわかります。
作業 |
説明 |
参照先 |
---|---|---|
メールサービスの設定 |
メールサービスの各コンポーネントを設定する手順。メールサーバー、メールクライアント、メールホスト、およびメールゲートウェイの設定方法について説明します。sendmail で DNS を利用する方法について説明します。 | |
sendmail 構成ファイルの変更 |
構成ファイルまたはサービスプロパティーを変更する手順。 | |
メール別名ファイルの管理 |
ネットワークで別名を提供するための手順。NIS+ テーブルのエントリの管理方法を説明します。また、NIS マップ、ローカルメール別名、キー付きマップファイル、およびポストマスター別名の設定方法も説明します。 | |
メールキューの管理 |
スムーズなキュー処理を提供するための手順。メールキューを表示したり移動したりする方法、強制的なメールキュー処理方法、およびメールキューのサブセットの実行方法について説明します。古いメールキューの実行方法についても説明します。 | |
.forward ファイルの管理 |
.forward ファイルを無効にしたり、.forward ファイルの検索パスを変更したりする手順。/etc/shells を作成し生成することにより、.forward ファイルの使用をユーザーに許可する方法も説明します。 | |
メールサービスのトラブルシューティング手順とヒント |
メールサービスで発生した問題を解決するための手順とヒント。メール構成のテスト、メール別名の確認、sendmail ルールセットのテスト、ほかのシステムへの接続の確認、メッセージの記録などの方法について学びます。ほかのメール診断情報の情報源も紹介します。 | |
エラーメッセージの解釈処理 |
メール関連のエラーメッセージを解釈処理するための情報。 |
次に、メールシステムを計画するときに考慮すべき点を挙げます。
必要に応じてメール構成のタイプを決定します。この節では、メール構成の基本の 2 タイプについて説明し、各構成を設定するために必要なことがらについて簡単に説明します。新しいメールシステムを設定する必要がある場合、あるいは既存のメールシステムを拡張する場合は、この節の内容が役立つでしょう。「ローカルメール専用」では 1 番目の構成タイプについて、「ローカルメールとリモート接続」では 2 番目の構成タイプについて説明します。
必要に応じてメールサーバー、メールホスト、およびメールゲートウェイとして動作するシステムを選択します。
サービスを提供するすべてのメールクライアントのリストを作成し、メールボックスの場所も含めます。このリストは、ユーザーのメール別名を作成するときに役立ちます。
別名の更新方法とメールメッセージの転送方法を決めます。ユーザーがメールの転送要求を送る場所として、 aliases メールボックスを設定できます。ユーザーはこのメールボックスを使って、デフォルトのメール別名の変更要求を送ることもできます。システムで NIS または NIS+ を使用する場合、メール転送の管理は、ユーザー自身ではなく、管理者が行うこともできます。「メール別名ファイルの管理 (作業マップ)」に、別名に関連する作業の一覧があります。「.forward ファイルの管理 (作業マップ)」に、.forward ファイルの管理に関連する作業の一覧があります。
メールシステムの計画を立てたら、サイトにシステムを設定し、「メールサービスの設定 (作業マップ)」で説明する機能を実行します。ほかの作業については、「メールサービス (作業マップ)」を参照してください。
図 13–1 に示すように、もっとも単純なメール構成は、1 台のメールホストに 2 台以上のワークステーションが接続されている場合です。メールは完全にローカルです。すべてのクライアントがローカルのディスクにメールを格納し、すべてのクライアントがメールサーバーとして機能します。メールアドレスは /etc/mail/aliases ファイルを使って構文解析されます。
この種類のメール構成を設定するには、次が必要です。
メールホストとして指定されたサーバー。NIS または NIS+ を実行している場合に、この指定を行うには、メールホスト上の /etc/hosts ファイルに mailhost. domain-name を追加します。DNS や LDAP など、別のネームサービスを実行している場合は、/etc/hosts ファイルに追加情報を入力します。「メールホストを設定する方法」を参照してください。
NIS や NIS+ 以外のネームサービスを使用している場合は、ローカルメールボックスのあるすべてのシステム上に、対応する /etc/mail/aliases ファイルが必要です。
各メールクライアントシステムの /var/mail に、メールボックスを格納できるだけの十分な領域。
メールサービスの設定の詳細については、「メールサービスを設定する」を参照してください。メールサービスの設定に関する特定の手順については、「メールサービスの設定 (作業マップ)」を参照してください。
小規模のネットワークにおけるもっとも一般的なメール構成を図 13–2 に示します。1 つのシステムが、メールサーバー、メールホスト、およびリモート接続を行うメールゲートウェイを兼ねています。メールは、メールゲートウェイ上の /etc/mail/aliases ファイルを使って配布されます。ネームサービスは必要ありません。
この構成では、メールクライアントがメールホスト上の /var/mail からメールファイルをマウントすると想定できます。この種類のメール構成を設定するには、次が必要です。
各メールクライアントシステム上に、デフォルトの /etc/mail/sendmail.cf ファイル。このファイルは編集不要です。
メールホストとして指定されたサーバー。NIS または NIS+ を実行している場合に、この指定を行うには、メールホスト上の /etc/hosts ファイルに mailhost. domain-name を追加します。DNS や LDAP など、別のネームサービスを実行している場合は、/etc/hosts ファイルに追加情報を入力します。「メールホストを設定する方法」を参照してください。
NIS や NIS+ 以外のネームサービスを使用している場合は、ローカルメールボックスのあるすべてのシステム上に、対応する /etc/mail/aliases ファイルが必要です。
メールサーバーの /var/mail に、クライアントのメールボックスを格納できるだけの十分な領域。
メールサービスの設定の詳細については、「メールサービスを設定する」を参照してください。メールサービスの設定に関する特定の手順については、「メールサービスの設定 (作業マップ)」を参照してください。
作業 |
説明 |
参照先 |
---|---|---|
メールサーバーを設定する |
サーバーがメールを経路指定できるようにする手順 | |
メールクライアントを設定する |
ユーザーがメールを受信できるようにする手順 | |
メールホストを設定する |
電子メールアドレスを解釈処理できるメールホストを確立する手順 | |
メールゲートウェイを設定する |
ドメイン外のネットワークとの通信を管理する手順 | |
sendmail で DNS を使用する |
DNS ホストルックアップ機能を有効にする手順 |
サイトが企業外の電子メールサービスに接続していないか、あるいは企業が 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 ファイルで確認します。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail を停止します。
# svcadm disable -t network/smtp:sendmail |
/var/mail ディレクトリをリモートアクセスに使用できるかどうかを確認します。
# share |
/var/mail ディレクトリが表示された場合は、手順 5 に進みます。
/var/mail ディレクトリが表示されない場合、あるいはリストが表示されない場合は、該当する手順に進みます。
(省略可能) リストが表示されない場合は、NFS サービスを起動します。
「ファイルシステム自動共有を設定する方法」の手順に従って、/var/mail ディレクトリを使用して NFS サービスを起動します。
(省略可能) /var/mail ディレクトリがリストに含まれていない場合は、/var/mail ディレクトリを /etc/dfs/dfstab に追加します。
/etc/dfs/dfstab ファイルに次のコマンド行を追加します。
share -F nfs -o rw /var/mail |
ファイルシステムをマウントできるようにします。
# shareall |
ネームサービスが起動されていることを確認します。
(省略可能) NIS を実行している場合は、次のコマンドを使用します。
# ypwhich |
詳細は、ypwhich(1) のマニュアルページを参照してください。
(省略可能) NIS+ を実行している場合は、次のコマンドを使用します。
# nisls |
詳細は、nisls(1) のマニュアルページを参照してください。
(省略可能) DNS を実行している場合は、次のコマンドを使用します。
# nslookup hostname |
ホスト名を指定します。
詳細は、nslookup(1M) のマニュアルページを参照してください。
(省略可能) LDAP を実行している場合は、次のコマンドを使用します。
# ldaplist |
詳細は、ldaplist(1) のマニュアルページを参照してください。
sendmail を再起動します。
# svcadm enable network/smtp:sendmail |
メールクライアントは、メールサーバー上にメールボックスを持っている、メールサービスのユーザーです。メールクライアントにはさらに、/etc/mail/aliases ファイルで、メールボックスの位置を示すメール別名が設定されています。
POP (Post Office Protocol) または IMAP (Internet Message Access Protocol) のようなサービスを使ってメールクライアントを設定することもできます。ただし、POP または IMAP の構成方法については、このマニュアルでは説明していません。
メールクライアントシステム上でスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail を停止します。
# svcadm disable -t network/smtp:sendmail |
メールクライアントのシステムで /var/mail マウントポイントがあることを確認します。
マウントポイントは、インストール過程で作成されています。ls を使用すると、ファイルシステムが存在するかどうかを確認できます。次の例はファイルシステムが作成されていない場合に受け取る応答を示しています。
# ls -l /var/mail /var/mail not found |
/var/mail ディレクトリにファイルが何もないことを確認します。
メールファイルがこのディレクトリにある場合は、それらのファイルを移動させ、サーバーから /var/mail ディレクトリがマウントされるときにその対象とならないようにします。
メールサーバーから /var/mail ディレクトリをマウントします。
メールディレクトリは自動的にマウントすることも、ブート時にマウントすることもできます。
(省略可能) /var/mail を自動的にマウントします。
次のようなエントリを /etc/auto_direct ファイルに追加します。
/var/mail -rw,hard,actimeo=0 server:/var/mail |
割り当てられているサーバー名を指定します。
(省略可能) ブート時に /var/mail をマウントします。
/etc/vfstab ファイルに次のエントリを追加します。このエントリにより、指定されたメールサーバー上の /var/mail ディレクトリがローカルの /var/mail ディレクトリをマウントできます。
server:/var/mail - /var/mail nfs - no rw,hard,actimeo=0 |
システムをリブートするたびに、クライアントのメールボックスが自動的にマウントされます。システムをリブートしない場合は、次のコマンドを入力すれば、クライアントのメールボックスをマウントできます。
# mountall |
メールボックスのロックとメールボックスへのアクセスが適切に動作するには、NFS サーバーからメールをマウントするときに actimeo=0 オプションを入れる必要があります。
/etc/hosts を更新します。
/etc/hosts ファイルを編集し、メールサーバーのエントリを追加します。ネームサービスを使用する場合、この手順は必要ありません。
# cat /etc/hosts # # Internet host table # .. IP-address mailhost mailhost mailhost.example.com |
割り当てられている IP アドレスを指定します。
割り当てられているドメインを指定します。
割り当てられているメールホストを指定します。
詳細は、hosts(4) のマニュアルページを参照してください。
別名ファイルの 1 つにクライアントのエントリを追加します。
メール別名ファイルの管理に関する作業マップについては、「メール別名ファイルの管理 (作業マップ)」を参照してください。mail.local プログラムは、メッセージがはじめて配信された時に /var/mail ディレクトリでメールボックスを自動的に作成します。メールクライアントの個々のメールボックスを作成する必要はありません。
sendmail を再起動します。
# svcadm enable network/smtp:sendmail |
メールホストは、電子メールアドレスを解決し、ドメイン内でメールを再度ルーティングします。メールホストに適しているのは、ネットワークにリモート接続を提供するシステム、または親ドメインにネットワークを接続するシステムです。次に、メールホストを設定する手順を示します。
メールホストシステム上でスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail を停止します。
# svcadm disable -t network/smtp:sendmail |
ホスト名の構成を確認します。
次のように check-hostname スクリプトを実行し、sendmail が、このサーバーの完全指定のホスト名を識別できるかどうかを確認します。
% /usr/sbin/check-hostname hostname phoenix OK: fully qualified as phoenix.example.com |
このスクリプトで完全指定ホスト名が識別できなかった場合は、完全指定ホスト名をホストの最初の別名として /etc/hosts 内に追加する必要があります。
/etc/hosts ファイルを更新します。
次から、適切な手順を選択します。
(省略可能) NIS または NIS+ を使用している場合は、新しいメールホストとなるシステムの /etc/hosts ファイルを編集します。
メールホストシステムの IP アドレスとシステム名のあとに mailhost と mailhost.domain を追加します。
IP-address mailhost mailhost mailhost.domain loghost |
割り当てられている IP アドレスを指定します。
メールホストシステムのシステム名を指定します。
拡張ドメイン名を指定します。
これで、このシステムはメールホストとして指定されます。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 |
(省略可能) NIS または NIS+ を使用しない場合は、ネットワーク内の各システムにある /etc/hosts ファイルを編集します。
次のようなエントリを作成します。
IP-address mailhost mailhost mailhost.domain loghost |
sendmail を再起動します。
# svcadm enable network/smtp:sendmail |
メール構成をテストします。
手順については、「メール構成をテストする方法」を参照してください。
メールホストの詳細は、「ハードウェアコンポーネント」の 第 14 章メールサービス (リファレンス)を参照してください。
メールゲートウェイは、ドメイン外のネットワークとの通信を管理します。送信側メールゲートウェイ上のメールプログラムは、受信側システムのメールプログラムと同じでなければなりません。
メールゲートウェイに適しているのは、Ethernet および電話回線に接続されているシステムです。インターネットへのルーターとして設定されているシステムも適しています。メールホストをメールゲートウェイとして設定するか、あるいは別のシステムをメールゲートウェイとして設定できます。複数のメールゲートウェイを自分のドメイン用として設定できます。UUCP (UNIX-to-UNIX Copy Program) 接続がある場合は、メールゲートウェイとして UUCP 接続を使ってシステムを構成します。
メールゲートウェイ上でスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail を停止します。
# svcadm disable -t network/smtp:sendmail |
ホスト名の構成を確認します。
次のように check-hostname スクリプトを実行し、sendmail が、このサーバーの完全指定のホスト名を識別できるかどうかを確認します。
# /usr/sbin/check-hostname hostname phoenix OK: fully qualified as phoenix.example.com |
このスクリプトで完全指定ホスト名が識別できなかった場合は、完全指定ホスト名をホストの最初の別名として /etc/hosts 内に追加する必要があります。この手順の詳細は、手順 4の「メールホストを設定する方法」 を参照してください。
ネームサービスが起動されていることを確認します。
(省略可能) NIS を実行している場合は、次のコマンドを使用します。
# ypwhich |
詳細は、ypwhich(1) のマニュアルページを参照してください。
(省略可能) NIS+ を実行している場合は、次のコマンドを使用します。
# nisls |
詳細は、nisls(1) のマニュアルページを参照してください。
(省略可能) DNS を実行している場合は、次のコマンドを使用します。
# nslookup hostname |
ホスト名を指定します。
詳細は、nslookup(1M) のマニュアルページを参照してください。
(省略可能) LDAP を実行している場合は、次のコマンドを使用します。
# ldaplist |
詳細は、ldaplist(1) のマニュアルページを参照してください。
sendmail を再起動します。
# svcadm enable network/smtp:sendmail |
メール構成をテストします。
手順については、「メール構成をテストする方法」を参照してください。
メールゲートウェイの詳細は、「ハードウェアコンポーネント」の 第 14 章メールサービス (リファレンス)を参照してください。
DNS ネームサービスは、個別の別名をサポートしません。このネームサービスは、MX (メール交換局) レコードおよび CNAME レコードを使用するホストまたはドメインの別名をサポートします。ホスト名とドメイン名は両方またはいずれか一方を DNS データベースで指定できます。sendmail と DNS の詳細は、「sendmail とネームサービスの相互作用」の 第 14 章メールサービス (リファレンス)、または『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
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 |
mailhost と mailhost.domain エントリを確認します。
nslookup を使用して、mailhost と mailhost. domain のエントリが DNS データベースに存在することを確認します。詳細は、nslookup(1M) のマニュアルページを参照してください。
作業 |
説明 |
参照先 |
---|---|---|
sendmail 構成ファイルの構築 |
sendmail.cf ファイルを変更する手順。例としてドメインマスカレードを有効にする方法を取り上げます。 | |
仮想ホストの設定 |
メールが複数のドメインに受け入れられるように sendmail を設定する手順。 | |
sendmail 構成ファイルの自動再構築の設定 |
アップグレード後に sendmail.cf および submit.mc 構成ファイルが自動的に再構築されるように sendmail サービスを変更する手順。 | |
sendmail のオープンモードでの実行 |
オープンモードが有効になるように sendmail サービスのプロパティーを変更する手順。 | |
Transport Layer Security (TLS) を使用する SMTP の設定 |
SMTP を有効にして TLS との接続をセキュリティー保護する手順。 | |
代替構成を使用したメール配信の管理 |
マスターデーモンが無効な場合に発生する可能性があるメール配信上の問題を防ぐための手順。 |
「新しい sendmail.cf ファイルを構築する方法」で、構成ファイルの構築方法について説明します。sendmail.cf ファイルの以前のバージョンも引き続き使用できますが、新しい形式を使用することをお薦めします。
/etc/mail/cf/README。構成手順の詳細な説明です。
http://www.sendmail.org。sendmail 構成に関するオンライン情報です。
「構成ファイルのバージョン」の 「sendmail 構成ファイル」 と 第 14 章メールサービス (リファレンス)。いくつかのガイダンスを示します。
次に、新しい構成ファイルを構築する手順を示します。
/usr/lib/mail/cf/main-v7sun.mc は、/etc/mail/cf/cf/sendmail.mc になりました。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail を停止します。
# svcadm disable -t network/smtp:sendmail |
変更しようとする構成ファイルのコピーを作成します。
# cd /etc/mail/cf/cf # cp sendmail.mc myhost.mc |
.mc ファイルの新しい名前を指定します。
必要に応じて、新しい構成ファイル (たとえば、myhost.mc) を編集します。
たとえば、ドメインマスカレードを有効にするには、次のコマンド行を追加します。
# cat myhost.mc .. MASQUERADE_AS(`host.domain') |
目的のホスト名とドメイン名を指定します。
この例では、MASQUERADE_AS は、送信されたメールに、$j ではなく host.domain から送信されたものとしてラベルを付けます。
m4 を使って構成ファイルを構築します。
# /usr/ccs/bin/make myhost.cf |
-C オプションを使用して、新しい構成ファイルをテストし、新しいファイルを指定します。
# /usr/lib/sendmail -C myhost.cf -v testaddr </dev/null |
このコマンドはメッセージを表示するとともに、メッセージを testaddr に送信します。システム上で sendmail サービスを再起動せずに、送信メールだけがテストできます。まだメールを処理していないシステムでは、「メール構成をテストする方法」で説明する完全なテスト手順を使用してください。
オリジナルのコピーを作成したあと、新しい構成ファイルをインストールします。
# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.save # cp myhost.cf /etc/mail/sendmail.cf |
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 |
.cf ファイルの名前を指定します。
「sendmail 構成を変更する」では、構築手順の一部として、これと同じ 3 つの手順を説明しています。
/etc/mail/sendmail.cf ファイルを生成したら、次の手順に進み、仮想ユーザーテーブルを作成できます。
sendmail.cf または submit.cf のコピーを独自に構築済みであれば、アップグレード時に構成ファイルが置き換えられることはありません。次の手順は、sendmail.cf ファイルが自動的に再構築されるように sendmail サービスのプロパティーを構成する方法を示します。submit.cf 構成ファイルを自動的に再構築する方法については、例 13–1 を参照してください。両方のファイルの構築が必要な場合には、これらの手順を組み合わることもできます。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
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 |
sendmail サービスの再表示と再起動を行います。
最初のコマンドは、変更を実行中のスナップショット内に転送します。2 番目のコマンドは、新しいオプションを使って sendmail サービスを再起動します。
# svcadm refresh svc:/network/smtp:sendmail # svcadm restart svc:/network/smtp:sendmail |
この手順では、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 |
Solaris 10 リリースでは、sendmail サービスがデフォルトでローカル専用モードで実行するように変更されました。ローカル専用モードとは、ローカルホストからのメールだけが受け入れられることを意味します。その他のシステムからのメッセージはすべて拒否されます。Solaris の以前のリリースは、すべてのリモートシステムからのメールを受け入れるように構成されていました。これはオープンモードとして知られています。オープンモードを使用するには、次の手順に従います。
ローカル専用モードでの sendmail の実行は、オープンモードでの実行よりもはるかに安全です。潜在的なセキュリティーの問題を確実に認識した上で、この手順を実行してください。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail プロパティーを設定します。
# svccfg -s sendmail svc:/network/smtp:sendmail> setprop config/local_only = false svc:/network/smtp:sendmail> quit |
sendmail サービスの再表示と再起動を行います。
# svcadm refresh svc:/network/smtp:sendmail # svcadm restart svc:/network/smtp:sendmail |
Solaris 10 1/06 以降のリリースでは、SMTP は sendmail の version 8.13 で Transport Layer Security (TLS) を使用できます。SMTP サーバーおよびクライアントに対するこのサービスは、インターネット上での機密性の高い認証された通信だけでなく、盗聴や攻撃からの保護も実現します。このサービスは、デフォルトでは有効になっていないことに注意してください。
次の手順では、サンプルデータを使用して、sendmail が TLS を使用できるようにする証明書を設定する方法を示します。詳細については、「sendmail の version 8.13 で TLS を使用して SMTP を実行するためのサポート」を参照してください。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail を停止します。
# svcadm disable -t network/smtp:sendmail |
sendmail が TLS を使用できるようにする証明書を設定します。
次の手順を行います。
# 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 . |
任意のテキストエディタを使用して openssl.cnf ファイルの dir の値を /etc/sfw/openssl から /etc/mail/certs/CA に変更します。
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 オプションを選択すると、新しい証明書要求が作成されます。
この req オプションを選択すると、自己署名付き証明書が作成されます。
この req オプションを選択すると、新しく作成された秘密鍵のファイル名として private/cakey.pem を割り当てることができます。
この req オプションを選択すると、出力ファイルとして cacert.pem を割り当てることができます。
この req オプションを選択すると、証明書を 365 日間証明することができます。デフォルト値は 30 です。
この 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 など)。
(省略可能) セキュリティー保護された新しい接続が必要である場合、新しい証明書を作成し、認証局を使用して新しい証明書に署名します。
新しい証明書を作成します。
# 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 内にあることに注意してください。
認証局を使用して新しい証明書に署名します。
# 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 には署名済みの証明書が含まれています。
証明書の情報を表示し、証明書をさまざまな形式に変換し、証明書要求に署名します。
さまざまな形式の証明書要求の署名と、CRL (Certificate Revocation List) の生成に使用されます。
.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 を実行するための構成ファイルのオプション」を参照してください。
/etc/mail ディレクトリで sendmail.cf ファイルを再構築し、インストールします。
手順の詳細は、「sendmail 構成を変更する」を参照してください。
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 |
セキュリティーを高めるには、MYkey.pem に関して、グループなどに対して読み取り権を許可しないでください。
# chmod go-r MYkey.pem |
シンボリックリンクを使用して、confCACERT_PATH に割り当てられているディレクトリで CA 証明書をインストールします。
# C=CAcert.pem # ln -s $C `openssl x509 -noout -hash < $C`.0 |
そのほかのホストとのメールのセキュリティーを保護するには、ホストの証明書をインストールします。
sendmail を再起動します。
# svcadm enable network/smtp:sendmail |
次に、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 のマニュアルページも参照してください。
送受信されるメールの転送を容易にするため、sendmail の新しいデフォルトの構成は、デーモンとクライアントキューランナーを使用します。クライアントキューランナーは、ローカルの SMTP ポートのデーモンにメールを送信できなければなりません。デーモンが SMTP ポート上で待機していない場合、メールはキューに留まります。この問題を避けるには、次の作業を行います。デーモンとクライアントキューランナーについての詳細、およびこの代替構成を使用する必要性を理解するには、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。
この手順を実行すると、デーモンは、ローカルホストからの接続を受け付けるためだけに動作するようになります。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail クライアントサービスを停止します。
# svcadm disable -t sendmail-client |
変更しようとする構成ファイルのコピーを作成します。
# cd /etc/mail/cf/cf # cp submit.mc submit-myhost.mc |
.mc ファイルの新しい名前を指定します。
新しい構成ファイル (たとえば、submit- myhost.mc) を編集します。
待機中のホスト IP アドレスを msp 定義に変更します。
# grep msp submit-myhost.mc FEATURE(`msp', `[#.#.#.#]')dnl |
m4 を使って構成ファイルを構築します。
# /usr/ccs/bin/make submit-myhost.cf |
オリジナルのコピーを作成したあと、新しい構成ファイルをインストールします。
# cp /etc/mail/submit.cf /etc/mail/submit.cf.save # cp submit-myhost.cf /etc/mail/submit.cf |
sendmail クライアントサービスを再起動します。
# svcadm enable sendmail-client |
次の表では、メール別名ファイルの管理の手順を説明します。このトピックの詳細は、「メール別名ファイル」の 第 14 章メールサービス (リファレンス)を参照してください。
作業 |
説明 |
参照先 |
---|---|---|
NIS+ mail_aliases テーブルでの別名のエントリの管理 |
ネームサービスが NIS+ である場合に、mail_aliases テーブルの内容を管理する手順。 NIS+ mail_aliases テーブルを作成します。 | |
NIS+ mail_aliases テーブルの内容を表示します。 この手順には、個々のエントリを表示する方法と部分一致エントリを表示する方法の例が含まれています。 | ||
コマンド行から NIS+ mail_aliases テーブルへ別名を追加します。 | ||
NIS+ mail_aliases テーブルを編集してエントリを追加します。 | ||
NIS+ mail_aliases テーブルでエントリを編集します。 この手順には、エントリを削除する方法の例が含まれています。 | ||
NIS mail.aliases マップの設定 |
ネームサービスが NIS の場合に、mail.aliases マップを使って別名を設定する手順。 | |
ローカルのメール別名ファイルの設定 |
NIS や NIS+ などのネームサービスを使用していない場合に、/etc/mail/aliases ファイルを使って別名を設定する手順。 | |
キー付きマップファイルの作成 |
キー付きマップファイルを使って別名を設定する手順。 | |
postmaster 別名の設定 |
postmaster 別名を管理する手順。この別名は必須です。 |
メール別名はドメイン独自にする必要があります。この節では、メール別名ファイルを管理する手順を説明します。また、Solaris 管理コンソールの「メーリングリスト」機能を使って別名データベース上でこれらの作業を実行することもできます。
その他に、makemap を使ってローカルメールホストにデータベースファイルを作成することもできます。makemap(1M) のマニュアルページを参照してください。ローカルのデータベースファイルを使用しても、NIS や NIS+ のようなネームサービスを使用するほどの利点は得られません。しかし、ネットワークのルックアップは必要ないため、ローカルのデータベースファイルからの方がより早くデータを取り出すことができます。詳細は、「sendmail とネームサービスの相互作用」の 「メール別名ファイル」および 第 14 章メールサービス (リファレンス)を参照してください。
次の操作を行うことができます。
aliasadm コマンドを使用して、NIS+ テーブルのエントリを管理することができます。テーブルを作成するには、次の手順に従います。詳細は、aliasadm(1M) のマニュアルページを参照してください。
テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
NIS+ テーブルを作成します。
# aliasadm -I |
テーブルにエントリを追加します。
2 つまたは 3 つの別名を追加する方法については、「コマンド行から NIS+ mail_aliases テーブルへ別名を追加する方法」を参照してください。
多数の別名を追加する方法については、「NIS+ mail_aliases テーブルを編集してエントリを追加する方法」を参照してください。
テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
別名のアルファベット順に全エントリを表示します。
# aliasadm -1 |
詳細は、aliasadm(1M) のマニュアルページを参照してください。
また、aliasadm コマンドを使用して、個々のエントリを表示することもできます。この手順の最初の手順が完了したら、次のように入力します。
# aliasadm -m ignatz ignatz: ignatz@saturn # Alias for Iggy Ignatz |
このコマンドは、完全に一致する別名のみ表示し、部分的に一致するエントリは表示しません。aliasadm -m オプションでは、メタキャラクタ (*、? など) は使用できません。
また、aliasadm コマンドを使用して、部分一致エントリを表示することもできます。この手順の最初の手順が完了したら、次のように入力します。
# aliasadm -l | grep partial-string |
partial-string は、検索に使用する文字列で置き換えます。
2 つまたは 3 つの別名をテーブルに追加するには、次の手順に従います。多数の別名を追加する場合は、「NIS+ mail_aliases テーブルを編集してエントリを追加する方法」を参照してください。
メールクライアント、メールボックスの場所、およびメールサーバーシステムの名前の各リストをコンパイルします。
テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
(省略可能) 必要な場合は、NIS+ テーブルを作成します。
まったく新しい NIS+ mail_aliases テーブルを作成する場合は、最初に NIS+ テーブルを初期設定しなければなりません。テーブルの作成方法については、「NIS+ mail_aliases テーブルを作成する方法」を参照してください。
テーブルに別名を追加します。
次に、一般的なエントリの例を示します。
# aliasadm -a iggy iggy.ignatz@saturn "Iggy Ignatz" |
上記の例の入力内容を次に説明します。
別名を追加するためのオプション
簡略別名
拡張別名
引用符で囲んだ別名
作成したエントリを表示し、エントリに間違いがないことを確認します。
# aliasadm -m alias |
作成したエントリ
詳細は、aliasadm(1M) のマニュアルページを参照してください。
aliasadm コマンドを使用して、NIS+ テーブルのエントリを管理することができます。多数の別名をテーブルに追加するには、次の手順に従います。
メールクライアント、メールボックスの場所、およびメールサーバーシステムの名前の各リストをコンパイルします。
テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
別名テーブルを表示して編集します。
# aliasadm -e |
このコマンドは、テーブルを表示し、テーブルの編集を可能にします。使用するエディタは、$EDITOR 環境変数で設定されています。この変数が設定されていない場合、vi がデフォルトのエディタになります。
次の形式で、1 行に 1 別名ずつ入力します。
alias: expanded-alias # ["option" # "comments"] |
この列には、簡略別名を入力します。
この列には、拡張別名を入力します。
この列は、将来の拡張のために予約されています。
この列は、別名など、個々の別名に関するコメントに使用します。
オプション列をブランクにする場合は、空の引用符 2 つ ("") を入力し、そのあとにコメントを追加します。
NIS+ mail_aliases テーブルでは、エントリの順序は重要ではありません。aliasadm -l コマンドがリストをソートし、エントリをアルファベット順に表示します。
詳細は、「メール別名ファイル」および aliasadm(1M) のマニュアルページを参照してください。
テーブルを所有する NIS+ グループのメンバーになるか、メールサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
別名エントリを表示します。
# aliasadm -m alias |
alias は、割り当てられている別名で置き換えます。
必要に応じて別名エントリを編集します。
# aliasadm -c alias expanded-alias [options comments] |
必要な場合は、別名を編集します。
必要な場合は、拡張別名を編集します。
必要な場合は、オプションを編集します。
必要な場合は、このエントリのコメントを編集します。
詳細は、aliasadm(1M) のマニュアルページおよび 「メール別名ファイル」を参照してください。
編集したエントリを表示し、エントリに間違いがないことを確認します。
# aliasadm -m alias |
詳細は、aliasadm(1M) のマニュアルページを参照してください。
テーブルからエントリを削除するには、この手順の最初の手順の完了後、次の構文を入力します。
# aliasadm -d alias |
alias は、削除するエントリの別名で置き換えます。
次の手順によって、NIS の mail.aliases マップを使って別名の設定を容易に行うことができます。
メールクライアント、メールボックスの場所、およびメールサーバーシステムの名前の各リストをコンパイルします。
NIS マスターサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
/etc/mail/aliases ファイルを編集し、次のようなエントリを作成します。
メールクライアントごとにエントリを追加します。
# cat /etc/mail/aliases .. alias:expanded-alias |
簡略別名を指定します。
拡張別名 (user@host.domain.com) を指定します。
Postmaster: root エントリがあることを確認します。
# cat /etc/mail/aliases .. Postmaster: root |
root の別名を追加します。ポストマスターとして指定された個人のメールアドレスを使用します。
# cat /etc/mail/aliases .. root: user@host.domain.com |
指定されたポストマスターに割り当てられているアドレスを指定します。
NIS マスターサーバーがネームサービスを実行中で、各メールサーバーのホスト名を解釈処理できることを確認します。
/var/yp ディレクトリに移動します。
# cd /var/yp |
make コマンドを適用します。
# make |
/etc/hosts および /etc/mail/aliases ファイルの変更は、NIS スレーブシステムに伝達されます。変更は、遅くとも数分後には有効になります。
ローカルメール別名ファイルで別名を解釈処理するには、次の手順に従います。
ユーザーとメールボックスの場所の各リストをコンパイルします。
メールサーバーのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
/etc/mail/aliases ファイルを編集し、次のようなエントリを作成します。
ユーザーごとにエントリを追加します。
user1: user2@host.domain |
新しい別名を指定します。
新しい別名の実際のアドレスを指定します。
Postmaster: root エントリがあることを確認します。
# cat /etc/mail/aliases .. Postmaster: root |
root の別名を追加します。ポストマスターとして指定された個人のメールアドレスを使用します。
# cat /etc/mail/aliases .. root: user@host.domain.com |
指定されたポストマスターに割り当てられているアドレスを指定します。
別名データベースを再構築します。
# newaliases |
/etc/mail/sendmail.cf の AliasFile オプションの構成によって、このコマンドがバイナリ形式で、/etc/mail/aliases.db ファイルを 1 つ生成するか、または /etc/mail/aliases.dir と /etc/mail/aliases.pag の 1 組のファイルを生成するかが決まります。
次の手順のどちらかを実行して、生成されたファイルをコピーします。
(省略可能) /etc/mail/aliases、/etc/mail/aliases.dir、および /etc/mail/aliases.pag ファイルをほかの各システムにコピーします。
rcp または rdist コマンドを使用して 3 つのファイルをコピーできます。詳細は、rcp(1) のマニュアルページまたは rdist(1) のマニュアルページを参照してください。また、この目的のためのスクリプトを作成することもできます。
これらのファイルをコピーしたら、newaliases コマンドをほかの各システムで実行する必要はありません。ただし、メールクライアントを追加または削除するたびにすべての /etc/mail/aliases ファイルを更新する必要があるので注意してください。
(省略可能) /etc/mail/aliases および /etc/mail/aliases.db ファイルをほかの各システムにコピーします。
rcp または rdist コマンドを使用してこれらのファイルをコピーできます。詳細は、rcp(1) のマニュアルページまたは rdist(1) のマニュアルページを参照してください。また、この目的のためのスクリプトを作成することもできます。
これらのファイルをコピーしたら、newaliases コマンドをほかの各システムで実行する必要はありません。ただし、メールクライアントを追加または削除するたびにすべての /etc/mail/aliases ファイルを更新する必要があるので注意してください。
キー付きマップファイルを作成するには、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
エントリには、次の構文を使用できます。
old-name@newdomain.com new-name@newdomain.com old-name@olddomain.com error:nouser No such user here @olddomain.com %1@newdomain.com |
新たに割り当てたドメインでこれまで割り当てられていたユーザー名を指定します。
新たに割り当てるアドレスを指定します。
これまで割り当てられていたドメインでこれまで割り当てられていたユーザー名を指定します。
これまで割り当てられていたドメインを指定します。
新たに割り当てるドメインを指定します。
1 番目のエントリにより、メールは新しい別名に転送されます。2 番目のエントリにより、不適切な別名が使用された時にメッセージが作成されます。最後のエントリにより、すべての着信メールは olddomain から newdomain へ転送されます。
データベースファイルを作成します。
# /usr/sbin/makemap maptype newmap < newmap |
dbm、btree、hash などのデータベースタイプを選択します。
入力ファイル名とデータベースファイル名の最初の部分を指定します。dbm データベースタイプを選択すると、データベースファイルは接尾辞に .pag または .dir を使って作成されます。ほかの 2 つのデータベースタイプの場合、ファイル名には .db が付きます。
各システムは postmaster メールボックスにメールを送信できなければなりません。 postmaster の NIS または NIS+ 別名を作成できます。あるいは、ローカルの /etc/mail/aliases ファイルそれぞれに別名を作成することもできます。次の手順を参照してください。
postmaster 別名をローカルの各 /etc/mail/aliases ファイルに作成する場合は、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
/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 |
各システムの /etc/mail/aliases ファイルを編集します。
root をポストマスターに指定する個人のメールアドレスに変更します。
Postmaster: mail-address |
ポストマスターとして指定された個人に割り当てられたアドレスを使用します。
(省略可能) ポストマスター用に別のメールボックスを作成します。
ポストマスターがポストマスターメールと個人メールとを区別するために、別のメールボックスを作成できます。別のメールボックスを作成する場合は、/etc/mail/aliases ファイルを編集するときに、ポストマスターの個人メールアドレスではなくメールボックスアドレスを使用してください。詳細は、「postmaster 用に別のメールボックスを作成する方法」を参照してください。
postmaster 用に別のメールボックスを作成する場合は、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
postmaster として指定された個人のアカウントを作成します。パスワードフィールドにアスタリスク (*) を入力します。
ユーザーアカウントの追加の詳細については、『Solaris のシステム管理 (基本編)』の第 5 章「ユーザーアカウントとグループの管理 (手順)」を参照してください。
メールが配信されたら、mail プログラムがメールボックス名に読み書きできるようにします。
# mail -f postmaster |
割り当てられているアドレスを指定します。
postmaster メールボックスを /etc/mail/aliases ファイル内の別名に追加する場合は、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
root の別名を追加します。ポストマスターとして指定された個人のメールアドレスを使用します。
# cat /etc/mail/aliases .. root: user@host.domain.com |
ポストマスターとして指定された個人に割り当てられたアドレスを使用します。
ポストマスターのローカルシステムで、/etc/mail/aliases ファイルに別名の名前を定義するエントリを作成します。sysadmin が 1 例です。ローカルメールボックスへのパスも指定します。
# cat /etc/mail/aliases .. sysadmin: /usr/somewhere/somefile |
新しい別名の名前を作成します。
ローカルメールボックスのパスを指定します。
別名データベースを再構築します。
# newaliases |
作業 |
説明 |
参照先 |
---|---|---|
メールキュー /var/spool/mqueue の内容の表示 |
キューにあるメッセージの数とそれらのメッセージがキューから消去されるのにかかる時間を表示する手順。 | |
メールキュー /var/spool/mqueue の強制処理 |
以前にメッセージを受信できなかったシステムへのメッセージを処理する手順。 | |
メールキュー /var/spool/mqueue のサブセットの実行 |
ホスト名など、アドレスの部分文字列を強制的に処理する手順。さらに、特定のメッセージをキューから強制的に処理する手順。 | |
メールキュー /var/spool/mqueue の移動 |
メールキューを移動する手順。 | |
古いメールキュー /var/spool/omqueue の実行 |
古いメールキューを実行する手順。 |
この節では、キューの管理に役立つ作業について説明します。クライアント専用のキューの詳細については、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。ほかの関連情報については、「sendmail の version 8.12 から追加されたキューの機能」を参照してください。
次を参照してください。
キューにあるメッセージの数とそれらのメッセージがキューから消去されるのにかかる時間を表示します。
次の行を入力します。
# /usr/bin/mailq | more |
このコマンドは、次の情報を表示します。
キュー ID
メッセージのサイズ
メッセージがキューに入った日付
メッセージの状態
送信者と受信者
さらに、このコマンドは、承認属性 solaris.admin.mail.mailq を確認します。確認が取れると、sendmail で -bp フラグを指定するのと同じ処理が実行されます。確認ができない場合は、エラーメッセージが表示されます。デフォルトでは、この承認属性はすべてのユーザーで使用できるようになっています。承認属性は、prof_attr 内のユーザーエントリを変更することにより無効にできます。詳細は、prof_attr(4) および mailq(1) のマニュアルページを参照してください。
たとえば、以前にメッセージを受信できなかったシステムへのメッセージを処理するには、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
キューを強制処理し、キューが消去されるとジョブの進捗状況を表示します。
# /usr/lib/sendmail -q -v |
たとえば、ホスト名など、アドレスの部分文字列を強制的に処理するには、次の手順に従います。また、特定のメッセージをキューから強制的に処理するにも、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
-qRstring を使用して、いつでもメールキューのサブセットを実行できます。
# /usr/lib/sendmail -qRstring |
受信者の別名または user@host.domain の部分文字列 (ホスト名など) を指定
代わりに、-qInnnnn を使ってメールキューのサブセットを実行することもできます。
# /usr/lib/sendmail -qInnnnn |
キュー ID を指定します。
メールホストのスーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
sendmail デーモンを終了します。
# svcadm disable network/smtp:sendmail |
これで、sendmail はキューディレクトリを処理しなくなります。
/var/spool ディレクトリに移動します。
# cd /var/spool |
mqueue ディレクトリとディレクトリ内のすべての内容を omqueue ディレクトリに移動します。次に、mqueue という名前の新しい空のディレクトリを作成します。
# mv mqueue omqueue; mkdir mqueue |
ディレクトリのアクセス権を所有者は読み取り/書き込み/実行に、またグループは読み取り/実行に設定します。また、所有者とグループを daemon に設定します。
# chmod 750 mqueue; chown root:bin mqueue |
sendmail を起動します。
# svcadm enable network/smtp:sendmail |
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
古いメールキューを実行します。
# /usr/lib/sendmail -oQ/var/spool/omqueue -q |
-oQ フラグで、代替キューディレクトリを指定します。-q フラグで、キューのすべてのジョブを実行するように指示します。画面に冗長出力を表示する場合は、-v フラグを使用します。
空のディレクトリを削除します。
# rmdir /var/spool/omqueue |
次の表では、.forward ファイルを管理するための手順を説明します。詳細は、「.forward ファイル」の 第 14 章メールサービス (リファレンス)を参照してください。
作業 |
説明 |
参照先 |
---|---|---|
.forward ファイルを無効にする |
たとえば、自動転送を禁止する場合に実行する手順。 | |
.forward ファイルの検索パスを変更する |
たとえば、すべての .forward ファイルを共通ディレクトリに移動させる場合に実行する手順。 | |
/etc/shells を作成し生成する |
メールをプログラムまたはファイルに転送するために、ユーザーが .forward ファイルを使用できるようにする手順。 |
この節では、.forward ファイルの管理に関する複数の手順を説明します。これらのファイルはユーザーが編集できるので、ファイルが問題の原因になる場合があります。詳細は、「.forward ファイル」の 第 14 章メールサービス (リファレンス)を参照してください。
次を参照してください。
自動転送を禁止し、特定のホストの .forward ファイルを無効にするには、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
/etc/mail/cf/domain/solaris-generic.m4 またはサイト固有のドメイン m4 ファイルのコピーを作成します。
# cd /etc/mail/cf/domain # cp solaris-generic.m4 mydomain.m4 |
define(`confFORWARD_PATH',`')dnl |
m4 ファイルに confFORWARD_PATH の値がすでに存在する場合は、NULL 値に置き換えます。
新しい構成ファイルを構築してインストールします。
この手順の詳細については、「新しい sendmail.cf ファイルを構築する方法」を参照してください。
.mc ファイルを編集する場合は、忘れずに、DOMAIN(`solaris-generic') を DOMAIN(`mydomain ') に変更してください。
たとえば、すべての .forward ファイルを共通ディレクトリに入れる場合は、次の手順に従います。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
/etc/mail/cf/domain/solaris-generic.m4 またはサイト固有のドメイン m4 ファイルのコピーを作成します。
# cd /etc/mail/cf/domain # cp solaris-generic.m4 mydomain.m4 |
次の行を作成したファイルに追加します。
define(`confFORWARD_PATH',`$z/.forward:/var/forward/$u')dnl |
新しい構成ファイルを構築してインストールします。
この手順の詳細については、「新しい sendmail.cf ファイルを構築する方法」を参照してください。
.mc ファイルを編集する場合は、忘れずに、DOMAIN(`solaris-generic') を DOMAIN(`mydomain ') に変更してください。
このファイルは標準リリースには含まれていません。.forward ファイルを使用してプログラムまたはファイルにメールを転送することをユーザーに許可する場合は、このファイルを追加する必要があります。grep を使用して、パスワードファイルに一覧表示されたすべてのシェルを特定し、ファイルを手動で作成することができます。これにより、シェルをファイルに入力できます。しかし、次に示す、ダウンロード可能なスクリプトを使用する手順の方が簡単です。
スクリプトをダウンロードします。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
シェルのリストを作成するために、gen-etc-shells を実行します。
# ./gen-etc-shells.sh > /tmp/shells |
このスクリプトでは、getent コマンドを使用して、/etc/nsswitch.conf 内に一覧表示されたパスワードファイルソースに組み込まれたシェルの名前を収集します。
/tmp/shells 内のシェルのリストを調べて編集します。
選択したエディタを使用し、組み込まないシェルを削除します。
ファイルを /etc/shells に移動します。
# mv /tmp/shells /etc/shells |
次の表では、メールサービスのトラブルシューティング手順とヒントを説明します。
作業 |
説明 |
参照先 |
---|---|---|
メール構成のテスト |
sendmail 構成ファイルの変更をテストする手順 | |
メール別名の確認 |
指定された受信者にメールを配信できるかどうかを確認する手順 | |
ルールセットのテスト |
sendmail ルールセットの入力と戻りを確認する手順 | |
ほかのシステムへの接続の確認 |
ほかのシステムへの接続を確認するためのヒント | |
syslogd プログラムを使用したメッセージの記録 |
エラーメッセージ情報を収集するためのヒント | |
診断情報のその他の情報源の確認 |
ほかの情報源から診断情報を取得するためのヒント |
この節では、メールサービスの問題解決に使用できる手順とヒントをいくつか示します。
構成ファイルに対して行なった変更をテストするには、次の手順に従います。
変更した構成ファイルがあるシステムで sendmail を再起動します。
# svcadm refresh network/smtp:sendmail |
各システムからテストメッセージを送信します。
# /usr/lib/sendmail -v names </dev/null |
受信者の電子メールアドレスを指定します。
このコマンドは、指定された受信者に NULL メッセージを送信し、画面にメッセージの動作を表示します。
メッセージを通常のユーザー名に送ることによって、メールを自分自身またはローカルシステム上のほかの人に送信します。
(省略可能) ネットワークに接続している場合は、別のシステムの個人宛に次の 3 方向でメールを送信します。
メインシステムからクライアントシステムへ
クライアントシステムからメインシステムへ
クライアントシステムから別のクライアントシステムへ
(省略可能) メールゲートウェイがある場合、メールホストから別のドメインにメールを送信して、中継メールプログラムおよびホストが適切に設定されていることを確認します。
(省略可能) 電話回線上で別のホストへの UUCP 接続を設定している場合は、そのホストのだれかにメールを送信します。メッセージを受信した時点で、メールを返信してもらうか、電話してもらいます。
UUCP 接続を介してメールを送信するようにほかの人に頼みます。
sendmail プログラムは、メッセージが配信されたかどうかは検出しません。これは、配信のためにプログラムがメッセージを UUCP に渡すためです。
異なるシステムからメッセージを 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 ルールセットの入力と戻りを確認するには、次の手順に従います。
アドレステストモードに変更します。
# /usr/lib/sendmail -bt |
メールアドレスをテストします。
最後のプロンプト (>) で次の数値とアドレスを入力します。
> 3,0 mail-sraddress |
テストするメールアドレスを指定します。
セッションを終了します。
Control-D キーを押します。
次にアドレステストモードの出力例を示します。
% /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 行を調べます。これらの行は、メッセージが中継されるときにとった経路を追跡できます。時間帯の違いを考慮するのを忘れないでください。
ワークステーショングループの配信上の問題を記録するシステムログを確認します。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 を参照してください。
sendmail プログラムは、メール転送エージェントです。前の章で説明したように、このプログラムは、構成ファイルを使用して、別名処理、転送、ネットワークゲートウェイへの自動ルーティング、柔軟な構成を提供します。Solaris OS では、ほとんどのサイトで使用できる標準構成ファイルが付属しています。第 12 章メールサービス (概要)では、メールサービスのコンポーネントと典型的なメールサービスの構成を紹介しています。第 13 章メールサービス (手順) では、電子メールシステムをセットアップして管理する方法について説明しています。この章では、次のトピックについて説明します。
上記の章で説明されていない内容については、次のマニュアルページを参照してください。
ここでは、次の項目について sendmail の Solaris 版と一般的な Berkeley バージョンを比較します。
Solaris 10 以降のリリースで sendmail のコンパイルに使用されるフラグは、次のとおりです。構成にほかのフラグが必要な場合は、そのソースをダウンロードし、バイナリにコンパイルし直してください。このプロセスについては、http://www.sendmail.org を参照してください。
表 14–1 一般的な sendmail フラグ
フラグ |
説明 |
---|---|
SOLARIS=21000 |
Solaris 10 のサポート。 |
MILTER |
メールフィルタ API のサポート。sendmail の version 8.13 では、このフラグはデフォルトで有効になっています。「MILTER (sendmail のメールフィルタ API)」を参照してください。 |
NETINET6 |
IPv6 のサポート。このフラグは、conf.h から Makefile に移動されました。 |
表 14–2 マップとデータベースの種類
フラグ |
説明 |
---|---|
NDBM |
ndbm データベースのサポート |
NEWDB |
Berkeley DB データベースのサポート |
USERDB |
ユーザーデータベースのサポート |
NIS |
nis データベースのサポート |
NISPLUS |
nisplus データベースのサポート |
LDAPMAP |
LDAP のマップのサポート |
MAP_REGEX |
正規表現のマップのサポート |
表 14–3 Solaris のフラグ
フラグ |
説明 |
---|---|
SUN_EXTENSIONS |
sun_compat.o に含まれる Sun の拡張をサポートします。 |
SUN_INIT_DOMAIN |
下位互換性を確保するために、NIS ドメイン名をサポートしてローカルホスト名を完全指定します。詳細は、http://www.sendmail.org のベンダー固有の情報を参照してください。 |
SUN_SIMPLIFIED_LDAP |
Sun 固有の簡略化された LDAP API をサポートします。詳細は、http://www.sendmail.org のベンダー固有の情報を参照してください。 |
VENDOR_DEFAULT=VENDOR_SUN |
Sun をデフォルトのベンダーに選択します。 |
次の表に、Solaris 10 に添付されるバージョンの sendmail のコンパイルに使用されない一般的なフラグを示します。
表 14–4 sendmail の Solaris 版に使用されない一般的なフラグ
フラグ |
説明 |
---|---|
SASL |
Simple Authentication and Security Layer (RFC 2554) |
STARTTLS |
Transaction Level Security (RFC 2487) |
sendmail のコンパイルに使用するフラグのリストを参照するには、次のコマンドを使用します。
% /usr/lib/sendmail -bt -d0.10 < /dev/null |
上記のコマンドでは、Sun 固有のフラグは表示されません。
MILTER (sendmail のメールフィルタ API ) によって、サードパーティー製のプログラムが、メタ情報と本文にフィルタをかけるために処理されるときに、メールメッセージにアクセスできるようになります。フィルタを作成する必要や、作成したフィルタを使用するように sendmailを構成する必要はありません。この API は、sendmail の version 8.13 ではデフォルトで有効になっています。
詳細は、次を参照してください。
Solaris リリースには、sendmail.org による汎用リリースで提供されているコマンドの同義語がすべて組み込まれているわけではありません。次の表は、すべてのコマンドの別名を示したリストです。この表には、コマンドが Solaris リリースに組み込まれているかどうか、および sendmail を使って同じ動作を生成する方法も示しています。
表 14–5 代替 sendmail コマンド
代替名 |
Solaris への組み込み |
sendmail を使用したオプション |
---|---|---|
hoststat |
いいえ |
sendmail -bh |
mailq |
はい |
sendmail -bp |
newaliases |
はい |
sendmail -bi |
purgestat |
いいえ |
sendmail -bH |
smtpd |
いいえ |
sendmail -bd |
Solaris 10 以降のリリースに含まれている sendmail のバージョンには、sendmail.cf ファイルのバージョンを定義するための構成オプションが含まれます。現在のバージョンの sendmail でも以前のバージョンの構成ファイルを使用できます。バージョンレベルには 0 から 10 の値を設定できます。また、ベンダーの定義もできます。Berkeley または Sun をベンダーとして選択できます。ベンダーを定義しないでバージョンレベルだけを設定した場合は、Sun がデフォルトとして使用されます。次の表に有効なオプションを示します。
表 14–6 構成ファイルのバージョン値
フィールド |
説明 |
---|---|
V7/Sun |
sendmail の version 8.8 で使用された設定。 |
V8/Sun |
sendmail の version 8.9 で使用された設定。この設定は、Solaris 8 に含まれていました。 |
V9/Sun |
sendmail の version 8.10 と 8.11 で使用された設定。 |
V10/Sun |
sendmail の version 8.12 と 8.13 で使用される設定。version 8.12 は、Solaris 9 のデフォルトです。Solaris 10 以降のリリースでは、version 8.13 がデフォルトです。 |
V1/Sun は使用しないでください。詳細は、http://www.sendmail.org/vendor/sun/differences.html#4 を参照してください。
作業手順については、第 13 章メールサービス (手順)の 「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 固有の用語です。「メールプログラム」は sendmail によって使用され、カスタマイズされたローカル配信エージェントまたはカスタマイズされたメール転送エージェントの特定のインスタンスを特定します。sendmail.cf ファイルに少なくとも 1 つのメールプログラムを指定する必要があります。作業手順については、第 13 章メールサービス (手順)の 「sendmail 構成を変更する」を参照してください。ここでは、2 種類のメールプログラムについて説明します。
メールプログラムの詳細は、http://www.sendmail.org/m4/readme.html または /etc/mail/cf/README を参照してください。
SMTP はインターネットで使用される標準のメールプロトコルです。このプロトコルが、メールプログラムを定義します。
smtp は、ほかのサーバーへの標準 SMTP 転送機能を提供します。
esmtp は、ほかのサーバーへの拡張 SMTP 転送機能を提供します。
smtp8 は、8 ビットデータを MIME に変更することなく、ほかのサーバーに SMTP 転送機能を提供します。
dsmtp は、F=% メールプログラムフラグを使ってオンデマンド配信機能を提供します。「sendmail の version 8.12 からの MAILER() の宣言についての変更点」と 「sendmail の version 8.12 から追加された配信エージェントのフラグ」を参照してください。
UUCP の使用は、できるだけ避けてください。説明については、http://www.sendmail.org/m4/uucp_mailers.html を参照するか、/etc/mail/cf/README で USING UUCP MAILERS という文字列を検索してください。
UUCP が、メールプログラムを定義します。
$=U クラスの名前が uucp-old に送られます。suucp は、このメールプログラムの以前の名前です。uucp-old メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。
$=Y クラスの名前が uucp-new に送られます。受信側の UUCP メールプログラムが単一の転送で複数の受信者を管理できる場合は、このメールプログラムを使用します。suucp は、このメールプログラムの以前の名前です。uucp-new メールプログラムはヘッダーで感嘆符を用いるアドレスも使用します。
構成に MAILER(smtp) も指定されている場合は、さらに次の 2 つのメールプログラムが定義されます。
このメールプログラムは、ドメインスタイルアドレスを使用し、基本的に SMTP のリライトルールを適用します。
$=Z クラスの名前が uucp-uudom に送られます。uucp-uudom と uucp-dom は、ドメインスタイルアドレスという同じヘッダーアドレス書式を使用します。
smtp メールプログラムは UUCP メールプログラムを変更するので、.mc ファイルの MAILER(uucp) の前に必ず MAILER(smtp) を記述します。
「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。メールボックスを含む複数のシステムで構成されるメールシステム、または 1 つ以上のドメインで構成されるメールシステムを管理する場合は複雑になります。UUCP またはその他のメールシステムによってネットワーク外部のサーバーに接続する場合は、さらに複雑になります。次の節で、メールアドレスの各部とその複雑さを説明しています。
電子メールのアドレス指定には、ドメインが使用されます。「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。ドメインは 1 つ以上の「サブドメイン」を持つことができます。アドレスのドメインとサブドメインは、ファイルシステムの階層と比較できます。サブディレクトリが上位のディレクトリに含まれるように、メールアドレスの各サブドメインもその右のドメインに含まれると考えられます。
表 14–7 最上位のドメイン
ドメイン |
説明 |
---|---|
com |
企業 |
edu |
教育機関用 |
gov |
米国の政府機関 |
mil |
米国の軍事機関 |
net |
ネットワーク組織 |
org |
その他の非営利組織 |
ドメインには大文字と小文字の区別がありません。アドレスのドメイン部分には、大文字、小文字、またはその両方を混合したものを、問題なく使用できます。
ネームサービスドメイン名とメールドメイン名を操作するときは、次のことに注意します。
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+ といったネームサービスを利用すると、電子メールアドレスの別名を作成できます。したがって、ユーザーは、個々のユーザーのメールボックスの正確なローカル名を知る必要はありません。
次の表に、特殊な目的のメールボックスに対する共通の命名規則をいくつか示します。
表 14–8 メールボックス名の書式についての規則
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 ファイルをカスタマイズする必要がありますが、これは困難で時間のかかる作業になる場合もあります。
インターネットに接続できるマシンがある場合は、そのマシンをメールゲートウェイとして構成できます。メールゲートウェイを構成するときは、まずサイトのセキュリティー要件を慎重に考慮する必要があります。社内ネットワークをほかのネットワークと接続するには、ファイアウォールゲートウェイを構築し、それをメールゲートウェイとして設定しなければならない場合があります。作業手順については、「メールゲートウェイを設定する方法」の 第 13 章メールサービス (手順)を参照してください。
メールサービスには、相互に対応する数多くのプログラムやデーモンが含まれています。ここでは、電子メールの管理に関連するファイル、プログラム、用語、および概念について説明します。
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 ディレクトリの内容を示します。
名前 |
種類 |
説明 |
---|---|---|
ファイル |
NIS+ 別名マップを処理するプログラム。 |
|
ファイル |
ユーザーエージェント。 |
|
ファイル |
メールを SunOS 4.1 メールボックスフォーマットに格納するフィルタ。 |
|
ファイル |
メールキューの内容を一覧表示するプログラム。 |
|
ファイル |
/etc/mail/statistics ファイルに格納されたメール統計情報の読み込みに使用するプログラム (存在する場合のみ)。 |
|
ファイル |
ユーザーエージェント。 |
|
ファイル |
アドレスの検証とデバッグのためメールプログラムに接続するプログラム。 |
|
ファイル |
別名データベースを「ソースに展開」するコマンド。praliases(1) のマニュアルページにあるソース展開の情報を参照してください。 |
|
シンボリックリンク |
/usr/bin/mail へのシンボリックリンク。メール送信だけに使用されるコマンド。 |
|
ファイル |
メールへの自動応答を設定するコマンド。 |
次の表に、/etc/mail ディレクトリの内容を示します。
名前 |
種類 |
説明 |
---|---|---|
ファイル |
mailx ユーザーエージェントのデフォルトの設定値。 |
|
ファイル |
メール転送情報。 |
|
ファイル |
newaliases の実行によって作成されるデフォルトのバイナリ形式のメール転送情報。 |
|
ファイル |
newaliases の実行によって作成されるバイナリ形式のメール転送情報。まだ使用できますが、Solaris 9 よりデフォルトでは使用できません。 |
|
ファイル |
newaliases の実行によって作成されるバイナリ形式のメール転送情報。まだ使用できますが、Solaris 9 よりデフォルトでは使用できません。 |
|
ファイル |
mailx ユーザーエージェントのデフォルトの設定値。 |
|
シンボリックリンク |
メインシステム用の構成ファイルのこの例から sendmail.cf へのシンボリックリンクが、下位互換性を確保するために提供されます。このファイルは、sendmail の version 8.13 では必要ありません。 |
|
ファイル |
リレーを許容するすべてのドメインのリスト。デフォルトでは、ローカルドメインだけが使用できます。 |
|
ファイル |
メールルーティング用の構成ファイル。 |
|
ファイル |
メール配信プログラム (MSP) のための新しい構成ファイル。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。 |
|
ファイル |
メールホスト用の別名の数が多すぎるときに作成可能なオプションファイル。 |
|
ファイル |
SMTP HELP コマンドで使用するヘルプファイル。 |
|
ファイル |
リスニングデーモンの PID を一覧表示し、現在は /var/run にあるファイル。 |
|
ファイル |
sendmail 統計ファイル。このファイルが存在すると、sendmail は各メールプログラムのトラフィック量をログに記録します。このファイルは以前 sendmail.st と呼ばれていました。 |
|
シンボリックリンク |
サブシステム用の構成ファイルのこの例から sendmail.cf へのシンボリックリンクが、下位互換性を確保するために提供されます。このファイルは、sendmail の version 8.13 では必要ありません。 |
|
ファイル |
特定のメール操作を実行するための信頼を与えられたユーザーを一覧表示するファイル (各行 1 ユーザー)。デフォルトでは、root だけがこのファイルに入っています。信頼されていないユーザーが特定のメール操作を実行すると、X-Authentication-Warning: header being added to a message という警告が生成されます。 |
/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 ディレクトリに置かれるようになりました。「メールサービスに使用するその他のファイル」を参照してください。下位互換性を確保するために、シンボリックリンクが各ファイルの新しい位置を示します。
表 14–9 メールサービスに利用する /etc/mail/cf ディレクトリの内容
名前 |
種類 |
説明 |
---|---|---|
ファイル |
構成ファイルを説明します。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.cf にリンクされます。このファイルはメインの構成ファイルとして使用されます。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.mc にリンクされます。このファイルは、メインの構成ファイルを作成するためのファイルでした。 |
|
ファイル |
新しい構成ファイルを作成する場合の規則を提供します。 |
|
ファイル |
メッセージを送信するためのメール配信プログラム (MSP) のための構成ファイルです。 |
|
ファイル |
submit.cf ファイルの構築に使用されるファイルです。このファイルは、メール配信プログラム (MSP) のための m4 マクロを定義します。 |
|
ファイル |
sendmail のためのメインの構成ファイルです。 |
|
ファイル |
sendmail.cf ファイルの生成に使用される m4 マクロが含まれています。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.cf にリンクされます。別のホストから /var/mail を NFS マウントするホストのための構成ファイルとして使用されます。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.mc にリンクされます。このファイルには、subsidiary.cf ファイルの生成に使用された m4 マクロが含まれています。 |
|
ディレクトリ |
サイトに依存するサブドメインの説明を提供します。 |
|
ファイル |
Berkeley Software Distribution からの汎用ドメインファイルです。 |
|
ファイル |
sendmail 関数を以前の Solaris 版の sendmail のようにする変更を伴うドメインファイルです。ただし、リレーは完全に無効に設定されるので、ホスト名のない送信者アドレスは拒否され、解決されないドメインは拒否されます。 |
|
ファイル |
sendmail 関数を以前の Solaris 版の sendmail のようにする変更を伴うデフォルトのドメインファイルです。 |
|
ディレクトリ |
特定のホスト用の特別な機能の定義を含みます。機能の詳細な説明は README を参照してください。 |
|
ディレクトリ |
サイトに依存しないインクルードファイルを含みます。 |
|
ディレクトリ |
local、smtp、uucp などのメールプログラムの定義を含みます。 |
|
ファイル |
廃止: Solaris 10 リリース以降、このファイル名は cf/sendmail.mc に変更されました。 |
|
ディレクトリ |
各種のオペレーティングシステム環境を説明します。 |
|
ファイル |
デフォルトのローカルメールプログラムを mail.local に定義します。 |
|
ファイル |
デフォルトのローカルメールプログラムを mail.local に定義します。 |
|
ファイル |
ローカルメールプログラムを mail に定義します。 |
|
ファイル |
ローカルメールプログラムを LMTP モードで mail.local に定義し、IPv6 を有効にし、sendmail.pid ファイルのディレクトリとして /var/run を指定します。 |
|
ファイル |
廃止: Solaris 10 リリース以降、このファイル名は cf/sendmail.mc に変更されました。 |
次の表にメールサービスに使用する /usr/lib ディレクトリの内容を示します。
表 14–10 /usr/lib ディレクトリの内容
名前 |
種類 |
説明 |
---|---|---|
mail.local |
ファイル |
メールボックスにメールを配信するメールプログラム。 |
sendmail |
ファイル |
メール転送エージェントとしても知られるルーティングプログラム。 |
smrsh |
ファイル |
sendmail の |program 構文を使用して /var/adm/sm.bin ディレクトリにあるプログラムに対して sendmail を実行できるプログラムを制限するシェルプログラム (sendmail に限定されたシェル)。/var/adm/sm.bin に含める内容については、smrsh(1M) のマニュアルページを参照してください。有効にするには、この m4 コマンドと FEATURE(`smrsh') を mc ファイルに含めます。 |
|
シンボリックリンク |
シンボリックリンクは /etc/mail/cf ディレクトリを示します。詳細は、「/etc/mail/cf ディレクトリの内容」を参照してください。 |
メールサービスは、その他のいくつかのファイルおよびディレクトリを使用します。これらを表 14–11 に示します。
表 14–11 メールサービスに使用するその他のファイル
名前 |
種類 |
説明 |
---|---|---|
/etc/default/sendmail |
ファイル |
sendmail の起動スクリプトの環境変数を一覧表示します。 |
/etc/shells |
ファイル |
有効なログインシェルを一覧表示します。 |
/etc/mail/cf/sh |
ディレクトリ |
m4 構築プロセスと移行補助に使用するシェルスクリプトを含みます。 |
ファイル |
:include: 別名と .forward ファイルのアクセス権、および正確なアクセス権に必要なこれらの親ディレクトリのパスを確認します。 |
|
ファイル |
sendmail が完全指定のホスト名を判別できることを確認します。 |
|
ファイル |
sendmail のデータベースマップの単一のレコードに対してクエリーを実行して編集します。 |
|
ファイル |
メール通知デーモン。 |
|
ファイル |
入力されたマップのバイナリ形式を構築します。 |
|
シンボリックリンク |
/usr/lib/sendmail へのシンボリックリンク。別名データベースのバイナリ形式を作成するために使用します。以前は /usr/bin にありました。 |
|
ファイル |
sendmail が使用するエラーメッセージログをとるデーモン。 |
|
ファイル |
クライアント側リモートメールキューを起動するための Perl スクリプト。 |
|
ファイル |
CDE メールユーザーエージェント。 |
|
ファイル |
配信されたメールのメールボックス。 |
|
ディレクトリ |
クライアントデーモンによって配信されるメールの記憶領域。 |
|
ディレクトリ |
マスターデーモンによって配信されるメールの記憶領域。 |
|
ファイル |
リスニングデーモンの PID を表示するファイル。 |
メールサービスは次のプログラムで構成され、図 14–2 のように作用します。
次に、メールプログラムの相互作用について説明します。
ユーザーは、mailx などのプログラムを使ってメッセージを送信します。詳細は、mailx(1) のマニュアルページを参照してください。
メッセージは、そのメッセージを生成したプログラムによって収集され、sendmail デーモンに渡されます。
sendmail デーモンがメッセージのアドレスを識別可能な各部に分割して解析します。sendmail デーモンは、/etc/mail/sendmail.cf という構成ファイルの情報を使ってネットワーク名の構文、別名、転送情報、およびネットワークトポロジを決定します。sendmail はこの情報を使用して、メッセージが受信者に到達する経路を決定します。
sendmail デーモンはメッセージを適切なシステムに渡します。
ローカルシステムの /usr/lib/mail.local プログラムは、メッセージの受信者の /var/mail/username ディレクトリのメールボックスにメールを配信します。
受信者は、メールが届いたことが通知されるので、mail、mailx などのプログラムを使用してメールを受け取ります。
sendmail は、TCP/IP や UUCP などの異なる通信プロトコルを使用できます。
sendmail は、SMTP サーバー、メッセージキュー、メーリングリストを実装します。
sendmail は、次の命名規則に準拠したパターンマッチングシステムを使って名前の解釈を制御します。
ドメインベースの命名規則。ドメインの手法は、物理的なネーミングと論理的なネーミングの問題を分離します。詳細は、「メールアドレス」を参照してください。
ほかのネットワークのホストからローカルに見えるネットワーク名を提供するなどの即席のテクニック。
任意 (以前) の命名構文。
異種の命名スキーム。
Solaris オペレーティングシステムでは、sendmail プログラムをメールルーターとして使用します。次に、機能の一部を示します。
sendmail は、mail.local や procmail などのローカル配信エージェントとの間で、電子メールメッセージの受信や配信を行う役割を果たします。
sendmail はメール転送エージェントであり、mailx や Mozilla Mail などのユーザーエージェントからメッセージを受け取り、そのメッセージをインターネット経由でその宛先までルーティングします。
sendmail は、次の要領でユーザーが送信する電子メールメッセージを制御します。
受信者のアドレスを確認します。
適切な配信プログラムを選択します。
アドレスを配信エージェントが処理できるフォーマットに書き換えます。
必要に応じて、メールヘッダーをフォーマットし直します。
最後に転送されたメッセージをメール配信プログラムに渡します。
sendmail の詳細は、次のトピックを参照してください。
sendmail プログラムでは、メールルーティングに必要な 3 つのメカニズムをサポートしています。適切なメカニズムは、変更の種類によって決まります。
サーバーの変更
ドメイン全体の変更
単独のユーザーの変更
さらに、選択する再ルーティングメカニズムによって必要な管理レベルが異なります。次のオプションを考慮してください。
再ルーティングメカニズムの 1 つは「別名」です。
別名を使用すれば、使用するファイルの種類に基づいて、サーバー全体またはネームサービス全体をベースにしてアドレス名をマップできます。
次に、ネームサービスの別名の長所と短所を示します。
ネームサービス別名ファイルを使用すれば、メール再ルーティングの変更を単一のソースで管理できます。ただし、ネームサービスの別名指定では、再ルーティングの変更を伝達する際に遅延が起こります。
通常、ネームサービスの管理は、特定のシステム管理者グループに制限されます。一般ユーザーは、このファイルを管理しません。
次に、サーバー別名ファイルを使用する際の長所と短所を示します。
サーバー別名ファイルを使用すれば、指定されたサーバーの root になることができる任意のユーザーが再ルーティングを管理できます。
サーバー別名指定は、再ルーティングの変更を伝達する際の遅延はほとんどありません。
変更はローカルサーバーだけに影響します。ほとんどのメールが単一のサーバーに送信される場合は、影響が少なくなります。ただし、この変更を多くのメールサーバーに伝達する必要がある場合は、ネームサービスの別名指定を使用します。
一般ユーザーは、この変更を管理しません。
詳細は、この章の 「メール別名ファイル」を参照してください。作業マップについては、第 13 章メールサービス (手順)の 「メール別名ファイルの管理 (作業マップ)」を参照してください。
次のメカニズムは、「転送」です。
このメカニズムでは、ユーザーがメールの再ルーティングを管理できます。ローカルユーザーは、受信メールを次の対象に再ルーティングできます。
別のメールボックス
別のメールプログラム
別のメールホスト
このメカニズムは、.forward ファイルによってサポートされます。.forward ファイルの詳細は、この章の 「.forward ファイル」を参照してください。作業マップについては、「.forward ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
最後のメカニズムは、「取り込み」です。
このメカニズムでは、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 は、構成情報をコードにコンパイルする代わりに、構成ファイルを使ってメール構成を制御します。
ユーザーは独自のメーリングリストを管理できます。さらに各ユーザーは、ドメイン全体で有効な別名ファイル (通常、NIS または NIS+ によって管理されるドメイン全体の別名の中にある) を修正することなく自分自身の転送メカニズムを指定できます。
各ユーザーは、受信メールを処理するカスタムメールプログラムを指定できます。カスタムメールプログラムは、次のようなメッセージを返すこともできます。 「私は休暇中です」。詳細は、vacation(1) のマニュアルページを参照してください。
sendmail は、1 つのホストでアドレスを処理し、ネットワークトラフィックを削減します。
「構成ファイル」は、sendmail がその機能を実行する方法を制御します。構成ファイルにより、配信エージェント、アドレスの変換の規則、およびメールヘッダーのフォーマットが選択されます。sendmail プログラムは、/etc/mail/sendmail.cf ファイルの情報を使用して、その機能を実行します。
Solaris オペレーティングシステムには、/etc/mail ディレクトリに次の 2 つのデフォルト構成ファイルがあります。
デーモンモードの代わりにメール配信プログラムモードで sendmailを実行するために使用する submit.cf 構成ファイル。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。
メールクライアント、メールサーバー、メールホスト、メールゲートウェイを設定するときは、次を考慮してください。
メールホストやメールゲートウェイを設定するには、メール設定に必要な中継メールプログラムおよび中継ホストのパラメータを設定します。作業手順については、「メールサービスの設定 (作業マップ)」の 「sendmail 構成を変更する」または 第 13 章メールサービス (手順)を参照してください。sendmail version 8.13 では、main.cf ファイルは必要ありません。
次に、サイトの要求に応じて変更が可能な構成パラメータをいくつか説明します。
次の情報を指定する時間値。
読み取りのタイムアウト。
メッセージが送信者に返送されるまで、配信されずにキューに置かれる時間。「sendmail の version 8.12 から追加されたキューの機能」を参照してください。作業マップについては、「キューディレクトリの管理 (作業マップ)」を参照してください。
メール配信の速度を指定する配信 (delivery) モード。
ビジー期間中の効率を高めるためのロード制限。これらのパラメータは、sendmail が、長いメッセージ、多くの受信者へのメッセージ、および長時間ダウンしているサイトへのメッセージを配信しないようにします。
別名を保守するには、次のファイル、マップ、またはテーブルを使用します。
別名を保守する方法は、だれが使用し、だれが変更するかによって決まります。別名のタイプにはそれぞれ固有の形式要件があります。
関連する作業については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
.mailrc ファイルのリストに入っている別名には、ファイルを所有するユーザーしかアクセスできません。この制限により、ユーザーは自分で制御し、所有者だけが使用できる別名を作成できます。.mailrc ファイルの別名の形式は、次のとおりです。
alias aliasname value value value ... |
aliasname は、ユーザーがメールの送信時に使用する名前であり、value は有効な電子メールアドレスです。
ユーザーが scott に個人的な別名を作成し、それがネームサービスの scott の電子メールアドレスと一致しない場合、エラーが発生します。そのユーザーが作成したメールにユーザーが返信しようとするときに、メールが間違ったユーザーに転送されることになります。これを回避するには、別の別名命名方式を使用する以外にありません。
/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 マップのエントリを使用できます。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 テーブルには、名前が含まれており、それによってローカルドメインにおけるシステムや個人が登録されています。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 つの列を示します。
表 14–12 NIS+ mail_aliases テーブルの列
列 |
説明 |
---|---|
別名 |
別名の名前 |
expansion |
sendmail /etc/mail/aliases ファイルに表示される別名の値または別名のリスト |
options |
今後の使用のために予約された列 |
comments |
個々の別名のコメントのための列 |
NIS+ mail_aliases テーブルには、すべてのメールクライアントのエントリを含めてください。NIS+ aliases テーブルでは、aliasadm コマンドで、エントリの表示、作成、変更、および削除ができます。aliasadm コマンドを使用するには、aliases テーブルを所有する NIS+ グループのメンバーでなければなりません。作業手順については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。Solaris 管理コンソールを使用して NIS+ メール別名を管理することもできます。
新規の NIS+ aliases テーブルを作成する場合は、エントリを作成する前にテーブルを初期設定する必要があります。テーブルが存在するときは、初期設定は不要です。
ホームディレクトリに .forward ファイルを作成すると、sendmail およびその他のプログラムは、メールのリダイレクトや送信にこのファイルを使用できます。次の節を参照してください。
作業マップについては、「.forward ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
次に、容易に回避または修復できる状況を示します。
メールが宛先のアドレスに配信されない場合は、ユーザーの .forward ファイルをチェックしてください。ユーザーは、ホームディレクトリ host1 に .forward ファイルを配置して、user@host2 にメールを転送するようにしたのかもしれません。host2 にメールが着信すると、sendmail は NIS または NIS+ 別名に user があるかどうかを確認し、メッセージを user@host1 に返送します。このルーティングによってループが発生し、バウンスメールの増加を引き起こしています。
セキュリティーの問題を予防するために、root または bin アカウントに .forward ファイルを決して置かないでください。必要な場合は、代わりに aliases ファイルを使ってメールを転送してください。
メール配信で .forward ファイルを有効に使用するために、アクセス権などの次の設定が正しく適用されていることを確認してください。
.forward ファイルへの書き込みは、ファイルの所有者に制限されます。この制限によって、ほかのユーザーがセキュリティーに反することを防止します。
ホームディレクトリの親パスは root だけが所有し、root だけが書き込めるようにする必要があります。たとえば、.forward ファイルが /export/home/terry にある場合、/export および /export/home は root が所有し、root だけが書き込めるようにします。
また実際のホームディレクトリに書き込めるのは、そのユーザーだけであるべきです。
.forward ファイルをシンボリックリンクにすることはできません。また、複数のハードリンクを持つこともできません。
.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 ファイルがあります。detail 文字列には、演算子文字を除く任意の文字を使用できます。演算子文字は、.:%&!^[]+ です。この種のファイルを使用すれば、ほかのユーザーが電子メールアドレスを無断で使用しているかどうかを確認できます。たとえば、あるユーザーが、だれかに電子メールアドレス sandy+test1@example.com を使用するように指示した場合、ユーザーは、この別名に配信されるメールを、アドレスに送信されるメールの中から識別できます。デフォルトにより、sandy+test1@example.com の別名に送信されたメールはすべて、この別名と .forward+detail ファイルと突き合わせて検査されます。ここで一致しない場合は、そのメールは最終的に sandy@example.com に配信されますが、ユーザーは、これらのメールの To: メールヘッダー内の変更箇所を調べることができます。
このファイルは、sendmail のための初期設定用オプションを保存し、ホストをアップグレードしたときにオプションが除去されないようにするために使用します。次の変数を使用することができます。
クライアントデーモンで使用する追加オプションを選択します。クライアントデーモンは、クライアントだけのキュー (/var/spool/clientmqueue) の内容を確認し、クライアントキューランナーとして動作します。構文の検査は行われないため、この変数を変更するときは間違えないように注意してください。
CLIENTQUEUEINTERVAL には、QUEUEINTERVAL オプションと同様に、メールキューの実行間隔を設定します。ただし、CLIENTQUEUEINTERVAL オプションは、マスターデーモンではなくクライアントデーモンの機能を制御します。一般に、マスターデーモンはすべてのメッセージを SMTP ポートに配信できます。ただし、メッセージ負荷が高すぎる場合、またはマスターデーモンが実行されていない場合、メッセージはクライアントだけのキューである /var/spool/clientmqueue に入ります。次に、クライアントだけのキューをチェックするクライアントデーモンがクライアントキューを処理します。
SMTP クライアントとサーバーが、定期的なキューの実行を待たずに即座に対話を実行できるようにします。サーバーは、指定されたホストに送信されるキューを即座に配信できます。詳細は、etrn(1M) のマニュアルページを参照してください。
sendmail を起動するためのモードを選択します。-bd オプションを使用するか、未定義のままにしておきます。
マスターデーモンで使用される追加オプションを選択します。構文の検査は行われないため、この変数を変更するときは間違えないように注意してください。
マスターデーモンのメールキューの実行間隔を設定します。# は正の整数とし、そのあとに秒の場合は s、分の場合は m、時の場合は h、日の場合は d、週の場合は w を付けます。この構文は sendmail の起動前に確認されます。この間隔が負の場合、またはエントリの最後の文字が不適当な場合、この間隔は無視され、sendmail は 15 分のキュー間隔で起動します。
キューを実行するたびに新しいキューランナーを作成する代わりに、各実行の間に休止する単一の永続的なキューランナーを使用できるようにします。このオプションに設定可能な値は p だけです。p 以外に設定すると、このオプションは無効になります。
配信時にメールメッセージがたどる経路は、クライアントシステムの設定とメールドメインのトポロジによって異なります。メールホストやメールドメインの各追加レベルでは、別名のもう 1 つの解釈を追加できますが、ルーティングプロセスは基本的にほとんどのホストで同じになります。
クライアントシステムは、メールをローカルに受信できるようにセットアップできます。メールをローカルで受信することは、ローカルモードでの sendmail の実行として知られています。すべてのメールサーバーと一部のクライアントでは、ローカルモードがデフォルトです。ローカルモードのメールサーバーまたはクライアントでは、メッセージは次の要領でルーティングされます。
次の例では、sendmail.cf ファイルに設定されたデフォルトの規則を使用することを前提にしています。
可能な場合はメール別名を展開し、ローカルのルーティングプロセスを再起動します。
ネームサービスでメール別名を確認し、見つかった場合に新しい値と置換することで、メールアドレスが展開されます。次にこの新しい別名が再度確認されます。
メールがローカルの場合、/usr/lib/mail.local に配信されます。
メールはローカルのメールボックスに配信されます。
メールアドレスがこのメールドメインにホストを含んでいると、そのホストにメールを配信します。
アドレスがこのドメインにホストを含んでいない場合、メールホストにメールを転送します。
メールホストはメールサーバーと同じルーティングプロセスを使用します。ただし、メールホストはホスト名に加えて、ドメイン名が宛先になっているメールも受信できます。
ここでは、 sendmail とネームサービスに適用されるドメイン名について説明します。さらに、ネームサービスを有効に利用するための規則、および sendmail とネームサービスの相互作用について説明します。詳細は、次のトピックを参照してください。
関連する作業については、「sendmail で DNS を使用する方法」の 「メール別名ファイルの管理 (作業マップ)」または 第 13 章メールサービス (手順)を参照してください。
標準の sendmail.cf ファイルは、メールドメインを使ってメールを直接配信するか、あるいはメールホストを経由して配信するかを決定します。ドメイン内メールは直接 SMTP 接続経由で配信され、ドメイン間メールはメールホストに送られます。
セキュリティーの高いネットワークでは、ほんの少数の選ばれたホストだけが、外部宛てのパケットを生成する権限を与えられています。ホストがメールドメインの外部のリモートホストの IP アドレスを持っている場合も、SMTP 接続の確立は保証されません。標準の sendmail.cf では次のことを仮定しています。
現在のホストは、パケットを直接メールドメイン外のホストに送信する権限がない。
メールホストは、パケットを外部ホストに直接送信できる認可されたホストにメールを転送できる。実際には、メールホストが認可されたホストになることがある。
このように仮定すると、ドメイン間メールの配信または転送はメールホスト側の責任です。
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) のマニュアルページを参照してください。
次に、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 章メールサービス (手順)を参照してください。
次に、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 との相互作用について説明し、ガイドラインを示します。
メールドメイン名 – プライマリネームサービスとして 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 のこの新しいバージョンには多くの新機能が用意されていますが、FallBackSmartHost オプションがもっとも重要な追加機能です。このオプションにより、main.cf ファイルおよび subsidiary.cf ファイルを使用する必要がなくなります。main.cf ファイルは、MX レコードをサポートする環境で使用されていました。subsidiary.cf ファイルは、完全に動作する DNS がない環境で使用されていました。そのような環境では、スマートホストが MX レコードの代わりに使用されていました。FallBackSmartHost オプションは、統一された構成を提供します。このオプションは、すべての環境でもっとも優先順位の低い MX レコードのように動作します。このオプションは、有効である場合、メールが確実にクライアントに配信されるように、失敗した MX レコードのバックアップ (フェイルオーバー) として担う接続が保たれた (スマート) ホストを提供します。
version 8.13 の詳細については、次の各節を参照してください。
さらに、Solaris 10 1/06 以降のリリースでは、TLS (Transport Layer Security) を使用して 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 を実行するために使用される構成ファイルのオプションを説明します。これらのオプションを宣言する場合は、次の構文のどれかを使用します。
O OptionName=argument # 構成ファイル用
-O OptionName=argument # コマンド行用
define(`m4Name',argument) # m4 構成用
オプション |
説明 |
---|---|
CACertFile |
m4 名 : confCACERT 引数 : filename デフォルト値 : 未定義 1 つの CA 証明書を含むファイルを指定します。 |
CACertPath |
m4 名 : confCACERT_PATH 引数 : path デフォルト値 : 未定義 複数の CA の証明書が含まれるディレクトリへのパスを指定します。 |
ClientCertFile |
m4 名 : confCLIENT_CERT 引数 : filename デフォルト値 : 未定義 クライアントの証明書が含まれるファイルを指定します。sendmail がクライアントとして動作する場合にこの証明書が使用されることに注意してください。 |
ClientKeyFile |
m4 名 : confCLIENT_KEY 引数 : filename デフォルト値 : 未定義 クライアントの証明書に属する秘密鍵が含まれるファイルを指定します。 |
CRLFile |
m4 名 : confCRL 引数 : filename デフォルト値 : 未定義 X.509v3 認証に使用される、証明書の失効ステータスが含まれるファイルを指定します。 |
DHParameters |
m4 名 : confDH_PARAMETERS 引数 : filename デフォルト値 : 未定義 Diffie-Hellman (DH) パラメータが含まれるファイルを指定します。 |
RandFile |
m4 名 : confRAND_FILE 引数 : file:filename または egd:UNIX socket デフォルト値 : 未定義 file: 接頭辞を使用してランダムデータが含まれるファイルを指定するか、egd: 接頭辞を使用して UNIX ソケットを指定します。Solaris OS は乱数生成デバイスをサポートしているため、このオプションを指定する必要はありません。random(7D) のマニュアルページを参照してください。 |
ServerCertFile |
m4 名 : confSERVER_CERT 引数 : filename デフォルト値 : 未定義 サーバーの証明書が含まれるファイルを指定します。sendmail がサーバーとして動作する場合にこの証明書が使用されます。 |
Timeout.starttls |
m4 名 : confTO_STARTTLS 引数 : amount of time デフォルト値 : 1h STARTTLS コマンドに対する応答を SMTP クライアントが待機する時間を設定します。 |
TLSSrvOptions |
m4 名 : confTLS_SRV_OPTIONS 引数 : V デフォルト値 : 未定義 サーバーがクライアントから証明書を要求するかどうかを決定します。このオプションが V に設定されている場合、クライアント検証は行われません。 |
sendmail で SMTP による TLS の使用をサポートできるようにするには、次のオプションを定義してください。
CACertPath
CACertFile
ServerCertFile
ClientKeyFile
そのほかのオプションは必須ではありません。
次の表で、STARTTLS コマンドにより使用されるマクロを説明します。
表 14–14 TLS を使用して SMTP を実行するためのマクロ
次の表で、TLS を使用する SMTP 接続を、受け入れるか、継続するか、拒否するかを決定するルールセットを説明します。
表 14–15 TLS を使用して SMTP を実行するためのルールセット
ルールセット |
説明 |
---|---|
tls_server |
クライアントとして動作する場合、sendmail はこのルールセットを使用して、サーバーが現在 TLS によってサポートされているかどうかを判別します。 |
tls_client |
サーバーとして動作する場合、sendmail はこのルールセットを使用して、クライアントが現在 TLS によってサポートされているかどうかを判別します。 |
tls_rcpt |
このルールセットは、受取人の MTA の検証を必要とします。この受取人の制限により、DNS スプーフィングなどの攻撃が不可能になります。 |
TLS_connection |
このルールセットは、アクセスマップの RHS により指定された要件を、現在の TLS 接続の実際のパラメータに照合して確認します。 |
try_tls |
sendmail はこのルールセットを使用して、別の MTA への接続時に STARTTLS を使用できるかを判別します。MTA が適切に STARTTLS を実装できない場合、STARTTLS は使用されません。 |
詳細は、http://www.sendmail.org/m4/starttls.html を参照してください。
インターネットで動作するメールプログラムを定義する標準メールプロトコルとしては、SMTP はエンドツーエンドのメカニズムではありません。このプロトコルの制限により、SMTP を介した TLS のセキュリティーにはメールユーザーエージェントは含まれていません。メールユーザーエージェントは、ユーザーと (sendmail などの) メール転送エージェントの間のインタフェースとして動作します。
また、メールは複数のサーバーを経由してルーティングされる場合があります。SMTP のセキュリティーを完全にするには、SMTP 接続のチェーン全体に TLS のサポートが必要です。
最終的には、サーバーの各ペア、またはクライアントとサーバーのペアの間でネゴシエーションされる認証と機密性のレベルを考慮すべきです。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「認証サービス」を参照してください。
次の表に、sendmail の version 8.13 で追加されたコマンド行オプションを示します。コマンド行のほかのオプションについては、sendmail(1M) のマニュアルページを参照してください。
表 14–16 sendmail の version 8.13 で使用可能になったコマンド行オプション
オプション |
説明 |
---|---|
-D logfile |
この情報を標準出力に含めるのではなく、指定された logfile にデバッグ出力を送信します。 |
-q[!]Qsubstr |
隔離 reason の部分文字列である substr を持つ隔離されたジョブの処理を指定します。-Q reason オプションの説明を参照。!が追加された場合、このオプションは、この substr を持たない隔離されたジョブを処理します。 |
-Qreason |
この reason を持つ通常のキュー項目を隔離します。reason が指定されていない場合、隔離されるキュー項目が隔離されません。このオプションは、-q[!]Qsubstr オプションと連動します。substr は、reason の一部 (部分文字列) です。 |
次の表に、追加または改訂された構成ファイルオプションを示します。これらのオプションを宣言する場合は、次の構文のどれかを使用します。
O OptionName=argument # for the configuration file -O OptionName=argument # for the command line define(`m4Name',argument) # for m4 configuration |
オプション |
説明 |
---|---|
ConnectionRateWindowSize |
m4 名 : confCONNECTION_RATE_WINDOW_SIZE 引数 : number デフォルト値 : 60 受信接続を維持する秒数を設定します。 |
FallBackSmartHost |
m4 名 : confFALLBACK_SMARTHOST 引数 : hostname このオプションは、メールが確実にクライアントに配信されるように、失敗した MX レコードのバックアップ (フェイルオーバー) として担う接続が保たれたホストを提供します。 |
InputMailFilters |
m4 名 : confINPUT_MAIL_FILTERS 引数 : filename sendmail デーモンの入力メールフィルタを示します。 |
PidFile |
m4 名 : confPID_FILE 引数 : filename デフォルト値 : /var/run/sendmail.pid 今までのリリースのように、ファイルを開く前に、そのファイル名がマクロで展開されます。さらに、version 8.13 では、sendmail の終了時にファイルへのリンクが削除されます (unlinked)。 |
QueueSortOrder |
m4 名 : confQUEUE_SORT_ORDER 追加された引数 : none version 8.13 では、ソート順序を指定しない場合に none を使用します。 |
RejectLogInterval |
m4 名 : confREJECT_LOG_INTERVAL 引数 : period-of-time デフォルト値 : 3h (3 時間) 指定した period-of-time に対してデーモン接続が拒否された場合、その情報が記録されます。 |
SuperSafe |
m4 名 : confSAFE_QUEUE 短縮名 : s 追加された引数 : postmilter デフォルト値 : true postmilter が設定されている場合、sendmail は、すべての milters がメッセージの受付の信号を送るまで、キューファイルとの同期を延期します。この引数を有効にするには、sendmail が SMTP サーバーとして実行される必要があります。それ以外の場合、postmilter は true 引数を使用しているように動作します。 |
次の表に、追加または改訂された FEATURE() の宣言を示します。この m4 マクロは次の構文を使用します。
FEATURE(`name', `argument') |
FEATURE() の名前 |
説明 |
|
---|---|---|
conncontrol |
access_db ルールセットと連動して、受信 SMTP 接続の数を確認します。詳細は、/etc/mail/cf/README を参照してください。 |
|
greet_pause |
オープンプロキシと SMTP のスラミング保護を可能にする、greet_pause ルールセットを追加します。詳細は、/etc/mail/cf/README を参照してください。 |
|
local_lmtp |
デフォルトの引数は引き続き mail.local であり、今回の Solaris のリリースでの LMTP を使用できるメールプログラムです。ただし、version 8.13 で、LMTP を使用できる別のメールプログラムを使用する場合は、パス名を 2 番目のパラメータとして指定し、2 番目のパラメータに渡される引数を 3 番目のパラメータとして指定します。次に例を示します。
|
|
mtamark |
“TXT RRs による逆引き DNS でのメール転送エージェントのマーキング” (MTAMark) を試験的にサポートします。詳細は、/etc/mail/cf/README を参照してください。 |
|
ratecontrol |
access_db ルールセットと連動して、ホストに対する接続速度を制御します。詳細は、/etc/mail/cf/README を参照してください。 |
|
use_client_ptr |
この FEATURE() が有効になっている場合、ルールセット check_relay は $&{client_ptr} というこの引数で最初の引数を上書きします。 |
TCP ラッパーは、特定のネットワークサービスを要求するホストのアドレスをアクセス制御リスト (ACL) と突き合わせて検査することによるアクセス制御の実装方法を提供します。要求は、状況に応じて、許可されたり拒否されたりします。このアクセス制御メカニズムを提供する以外に、TCP ラッパーは、ネットワークサービスに対するホストの要求を記録します。これは、有用な監視機能です。アクセス制御のもとに置かれるネットワークサービスの例として、rlogind、telnetd、ftpd などがあります。
version 8.12 より、sendmail で TCP ラッパーが使用できるようになりました。この検査によってほかのセキュリティー対策が省略されることはありません。sendmail で TCP ラッパーを有効にすることにより、検査が追加され、ネットワーク要求元の妥当性が検証されてから要求が許可されます。hosts_access(4) のマニュアルページを参照してください。
inetd(1M) および sshd(1M) での TCP ラッパーは、Solaris 9 リリースからサポートされています。
ACL については、『Solaris のシステム管理 (セキュリティサービス)』の「アクセス制御リストによる UFS ファイルの保護」を参照してください。
version 8.12 より、sendmail に新しい構成ファイル /etc/mail/submit.cf が含まれるようになりました。この submit.cf ファイルを使用して、sendmail をデーモンモードではなく、メール配信プログラムモードで実行できます。デーモンモードとは異なり、メール配信プログラムモードでは root 権限は必要ありません。そのため、この新しいパラダイムを使用すると、セキュリティーが向上します。
submit.cf の機能については、次を参照してください。
sendmail は、MSP (メール配信プログラム) モードでは submit.cf を使って実行します。submit.cf は、電子メールを送信したり、ユーザー以外の mailx のようなプログラムによって呼び出したりすることができます。-Ac オプションおよび -Am オプションについては、sendmail(1M) のマニュアルページを参照してください。
submit.cf は、次の操作モードで使用します。
-bm デフォルトの操作モード
-bs 標準入力を使用して SMTP を実行する
-bt アドレスの解決に使用されるテストモード
submit.cf を使用している場合には、sendmail は SMTP デーモンとして動作しません。
submit.cf を使用している場合には、sendmail はクライアント専用のメールキューである /var/spool/clientmqueue を使用します。このキューにより、sendmail デーモンに配信されなかったメッセージが保持されます。クライアント専用キューにあるメッセージは、クライアントの「デーモン」によって配信されます。実際には、このデーモンが、クライアントキューを実行します。
デフォルトでは、sendmail は submit.cf を使用して、定期的に MSP キュー (クライアント専用キュー) である /var/spool/clientmqueue を実行します。
/usr/lib/sendmail -Ac -q15m |
次の事項に注意してください。
Solaris 9 より、submit.cf は自動的にインストールされます。
Solaris 9 以降をインストールする前に、submit.cf について計画および準備をする必要はありません。
構成ファイルを指定しないかぎり、sendmail は、必要に応じて、submit.cf を自動的に使用します。基本的に、sendmail は各タスクについて、submit.cf と sendmail.cf のどちらを使用するのが適切かを判断します。
submit.cf を変更することはできません。
構成ファイル sendmail.cf は、デーモンモードで使用します。このファイルを使用すると、sendmail は、メール転送エージェント (MTA) として動作します。sendmail は、root によって起動されます。
/usr/lib/sendmail -L sm-mta -bd -q1h |
sendmail.cf 特有のほかの機能については、次を参照してください。
デフォルトでは、sendmail.cf がメールキュー /var/spool/mqueue を実行します。
submit.cf が追加されたため、次の機能が変更されました。
sendmail の version 8.12 より、root だけがメールキューを実行できます。この変更の詳細は、mailq(1) のマニュアルページを参照してください。新しい作業手順については、「キューディレクトリの管理 (作業マップ)」を参照してください。
メール配信プログラムモードは、root 権限がなくても実行されるので、sendmail が特定のファイル (.forward ファイルなど) にアクセスできないことがあります。したがって、sendmail に -bv オプションを追加すると、ユーザーが誤解するような出力を発生させる可能性があります。回避策はありません。
8.12 より前のバージョンの sendmail では、sendmail をデーモンモードで実行しない場合は、受信メールの配信を防止することしかできませんでした。version 8.12 より、デフォルトの構成で、sendmail デーモンを実行しない場合、送信メールの配信もまた防止することができます。クライアントキューランナー (メール配信プログラム) を設定して、ローカル SMTP ポートのデーモンにメールを送信できるようにする必要があります。クライアントキューランナーが SMTP のセッションをローカルホストで開こうとした場合で、デーモンが SMTP ポートで待機していないときには、メールはキューにとどまります。デフォルトの構成では、デーモンが実行されます。そのため、デフォルト構成を使用する場合には、この問題は発生しません。ただし、デーモンを無効にした場合の解決方法については、 「sendmail.cf の代替構成を使ってメール配信を管理する方法」を参照してください。
次の表では、 sendmail の追加されたコマンド行オプションまたは推奨されないコマンド行オプションについて説明します。コマンド行のほかのオプションについては、sendmail(1M) のマニュアルページを参照してください。
表 14–19 sendmail の version 8.12 から追加されたまたは推奨されないコマンド行オプション
オプション |
説明 |
---|---|
オペレーションモードが初期メール配信を示していない場合でも、構成ファイル submit.cf を使用します。submit.cf についての詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。 |
|
オペレーションモードが初期メール配信を示している場合でも、構成ファイル sendmail.cf を使用します。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。 |
|
各キューのエントリ数を出力します。 |
|
コマンド行から送信されたメッセージが、初期送信のためでなく、中継のためであることを示します。アドレスが絶対パスではない場合は、メッセージは拒否されます。正規化は実行されません。ftp://ftp.sendmail.org で sendmail とともに配布しているリリースノートで説明しているように、将来のリリースでは、不適切な形式のメッセージが拒否される可能性があります。 |
|
指定された syslog メッセージに使用する識別子を タグ (tag) に設定します。 |
|
受信者にこの部分文字列 (substring) を含むジョブだけを処理します。オプションに ! を追加すると、受信者にこの部分文字列 (substring) を含まないジョブだけを処理します。 |
|
キュー ID にこの部分文字列 (substring) を含むジョブだけを処理します。オプションに ! を追加すると、キュー ID にこの部分文字列 (substring) を含まないジョブだけを処理します。 |
|
送信者にこの部分文字列 (substring) を含むジョブだけを処理します。オプションに ! を追加すると、送信者にこの部分文字列 (substring) を含まないジョブだけを処理します。 |
|
キューにあるメッセージをシステムコール fork を使用しないで一度処理し、フォアグラウンドでプロセスを実行します。fork(2) のマニュアルページを参照してください。 |
|
name で指定するキューグループにあるメッセージだけを処理します。 |
|
各キュー用にフォークされた子プロセスを使用して、キューに保存されているメッセージを指定した間隔で処理します。次にキューが実行されるまでの間、その子プロセスはスリープしています。この新しいオプションは -qtime に似ています。qtime は、定期的に子をフォークしてキューを処理します。 |
|
ftp://ftp.sendmail.org で sendmail とともに配付しているリリースノートで説明しているように、このオプションは version 8.12 以降では使用できません。メールユーザーエージェントでは、引数 -G を使用することをお勧めします。 |
次の表では、PidFile オプションおよび ProcessTitlePrefix オプションにおけるマクロ処理の追加引数について説明します。これらのオプションについては、sendmail(1M) のマニュアルページを参照してください。
表 14–20 PidFile オプションおよび ProcessTitlePrefix オプションの引数
マクロ |
説明 |
---|---|
${daemon_addr} |
0.0.0.0 などのデーモンアドレスを提供します。 |
${daemon_family} |
inet や inet6 などのデーモンファミリーを提供します。 |
${daemon_info} |
SMTP+queueing@00: 30:00 などのデーモン情報を提供します。 |
${daemon_name} |
MSA などのデーモン名を提供します。 |
${daemon_port} |
25 などのデーモンポートを提供します。 |
${queue_interval} |
キューを実行する間隔を提供します (00:30:00 など)。 |
次の表では、sendmail プログラムで使用するための追加マクロについて説明しています。マクロの値は、内部で割り当てられています。詳細は、sendmail(1M) のマニュアルページを参照してください。
表 14–21 sendmail に追加定義されたマクロ
マクロ |
説明 |
---|---|
${addr_type} |
現在のアドレスを、エンベロープの送信側または受信者アドレスと認定します。 |
${client_resolve} |
${client_name} の解釈処理コールの結果、 つまり OK、FAIL、FORGED、または TEMP を保持します。 |
${deliveryMode} |
DeliveryMode オプションの値ではなく、sendmail が使用している現在のデリバリモードを指定します。 |
${dsn_notify}、${dsn_envid}、${dsn_ret} |
対応する DSN パラメータ値を保持します。 |
${if_addr} |
インタフェースがループバックネット上にない場合に、受信接続用インタフェースのアドレスを提供します。このマクロは、特に仮想ホスティングに便利です。 |
${if_addr_out}、${if_name_out}、${if_family_out} |
${if_addr} の再利用を避けます。次の値を、それぞれ保持します。 送信接続用インタフェースのアドレス 送信接続用インタフェースのホスト名 送信接続用インタフェースのファミリ |
${if_name} |
受信接続用のインタフェースのホスト名を提供します。これは、特に仮想ホスティングに便利です。 |
${load_avg} |
実行キューにあるジョブの現在の平均数を確認して報告します。 |
${msg_size} |
ESMTP ダイアログにあるメッセージサイズの値 (SIZE=parameter) を保持してから、メッセージを収集します。その後、sendmail によって計算されたメッセージサイズを保持したマクロを check_compat で使用します。check_compat については、表 14–25 を参照してください。 |
${nrcpts} |
妥当性検査を行なった受信者の数を保持します。 |
${ntries} |
配信を試みた回数を保持します。 |
${rcpt_mailer}、${rcpt_host}、${rcpt_addr}、${mail_mailer}、${mail_host}、および ${mail_addr} |
引数 RCPT および MAIL を構文解析した結果を保持します。つまり、メール配信エージェント ($#mailer)、ホスト ($@host)、およびユーザー ($:addr) から解釈処理された RHS (Right-Hand Side) トリプレットを保持します。 |
この節では、構成ファイル sendmail を構築するのに使用する追加マクロについて説明した表を示します。
表 14–22 構成ファイル sendmail を構築するのに使用する追加マクロ
マクロ |
説明 |
---|---|
LOCAL_MAILER_EOL |
ローカルメールプログラムの行末を示すデフォルト文字列を置きかえます。 |
LOCAL_MAILER_FLAGS |
デフォルトで Return-Path: ヘッダーを追加します。 |
MAIL_SETTINGS_DIR |
メール設定ディレクトリのパスを格納します (末尾のスラッシュを含む)。 |
MODIFY_MAILER_FLAGS |
*_MAILER_FLAGS を拡張します。このマクロは、フラグを設定、追加、または削除します。 |
RELAY_MAILER_FLAGS |
中継メールプログラムの追加フラグを定義します。 |
次のマクロを使用して、受け入れ可能なコマンドを最大数設定し、sendmail による配信の遅れを防止することができます。これらの MAX マクロは、コンパイル時に設定できます。次の表にある最大値は、現在のデフォルト値でもあります。
表 14–23 追加された MAX マクロ
マクロ |
最大値 |
各マクロが検査するコマンド |
---|---|---|
25 |
未知のコマンド |
|
20 |
NOOP、VERB、ONEX、XUSR |
|
3 |
HELO、EHLO |
|
6 |
VRFY、EXPN |
|
8 |
ETRN |
マクロによる確認を無効にするには、マクロの値を 0 に設定します。
この節では、sendmail において追加または改訂された m4 構成マクロの表を示します。これらのマクロを宣言するには、次の構文を使用します。
symbolic-name(`value') |
新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
表 14–24 sendmail において追加または改訂された m4 構成マクロ
m4 マクロ |
説明 |
---|---|
FEATURE() |
詳細は、「sendmail の version 8.12 からの FEATURE() の宣言についての変更点」を参照してください。 |
このマクロは、クラス w ($=w) にエントリを追加します。 |
|
マスカレードできないホストやサブドメインを定義する新しいマクロ。 |
|
このマクロは user@[host] のように、括弧で囲まれたアドレスに使用できます。 |
|
これらのマクロを使用する場合は、$=R に $={VirtHost} を含めます。$=R は、中継が許可された一連のホスト名です。 |
FEATURE() の宣言についての変更点については、次の表を参照してください。
FEATURE の新しい名前および改訂された名前を使用するには、次の構文を使用します。
FEATURE(`name', `argument') |
新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
表 14–25 追加または改訂された FEATURE() の宣言
FEATURE() の名前 |
説明 |
---|---|
引数 : 次の段落の例を参照してください。 この新しい FEATURE() によって、送信者アドレスと受信者アドレスからなるアクセスマップ内でキーを検索できます。この FEATURE() は、文字列 <@> で区切ります。たとえば、sender@ sdomain<@>recipient @rdomain のようにします。 |
|
引数 : friend にすると、スパムメールの friend テストを実行できます。また、hater にすると、スパムメールの hater テストを実行できます。 すべての検査作業を遅らせる新しい FEATURE()。FEATURE(`delay_checks') を使用すると、クライアントが接続する場合、またはクライアントが MAIL コマンドを発行する場合に、ルールセット check_mail および check_relay は呼び出されません。代わりに、これらのルールセットはルールセット check_rcpt によって呼び出されます。詳細については、/etc/mail/cf/README ファイルを参照してください。 |
|
引数 : この FEATURE() は、最大次の 2 つの引数を受け入れます。
DNS 参照の戻り値を検査する回数を複数にできる新しい FEATURE()。この FEATURE() を使用して、参照が一時的に失敗した場合の動作を指定できます。 |
|
引数 : ドメイン名。 dnsbl の強化バージョンの新しい FEATURE() 。この FEATURE を使用して、DNS 参照の戻り値を検査できます。詳細は、/etc/mail/cf/README を参照してください。 |
|
引数 : なし。 genericstable を $=G のサブドメインに適用するのにも使用できる新しい FEATURE()。 |
|
引数 : 詳細は、http://www.sendmail.org の「リリースノート」を参照してください。 LDAP アドレスルーティングを実装する新しい FEATURE()。 |
|
引数 : LMTP (Local Mail Transfer Protocol) を使用できるメールプログラムのパス名。デフォルトは mail.local であり、今回の Solaris リリースでは LMTP を使用できます。 ローカルメールプログラムの DSN (delivery status notification) 診断コードのタイプを SMTP の正しい値に設定する FEATURE()。 |
|
引数 : なし。 ローカルメールプログラムをマスカレードしないようにするために使用する新しい FEATURE()。 |
|
引数 : なし。 アクセスマップの .domain を参照するのに使用する新しい FEATURE()。 |
|
引数 : canonify_hosts またはなし。 FEATURE() には次の機能が含まれます。 CANONIFY_DOMAIN または CANONIFY_DOMAIN_FILE で指定した、ドメインのリストを演算子 $[ および $] に渡して正規化することができます。 canonify_hosts がそのパラメータとして指定されている場合には、<user@host> など、ホスト名だけを含むアドレスを正規化できます。 複数のコンポーネントを持つアドレスの末尾にドットを追加できます。 |
|
引数 : なし。 sendmail のデフォルト設定を m4 構成ファイルでオフにする新しい FEATURE()。このファイルは、複数の異なるポート上で待機するために生成されたもので、RFC 2476 に実装されています。 |
|
引数 : reject にすると、! トークンを使用できません。 nospecial にすると、! トークンを使用できます。 ! トークンをアドレスのローカルの部分に使用するかどうかを決定する FEATURE()。 |
|
引数 : なし。 通常の構成ですべてのルールセットを提供する FEATURE()。スパムメール対策チェックを実行します。 |
|
引数 : なし。 sendmail がアドレスをローカル配信エージェントに渡す際に、アドレスの +detail の部分を保存できる新しい FEATURE()。 |
|
引数 : なし。 LUSER_RELAY を使用している場合に、受信者のホスト名を保存できる新しい FEATURE()。 |
|
引数 : なし。 電子メールのアドレス全体または受信者のドメインに基づいたキューグループを選択できる新しい FEATURE()。 |
|
引数 : ドメインは、任意の引数です。 メールの送信側がアクセスマップに RELAY として指定されており、それをヘッダー行 From: でタグ付けされている場合に、リレーを許可する新しい FEATURE()。省略可能な引数 domain を指定すると、メール送信側のドメイン部も検査されます。 |
|
引数 : なし。 $={VirtHost} を適用するのに使用する FEATURE()。$={VirtHost} は、VIRTUSER_DOMAIN または VIRTUSER_DOMAIN_FILE を使って生成できる virtusertable エントリを一致させるための新しいクラス。 また、FEATURE(`virtuser_entire_domain') を使用して、クラス $={VirtHost} をサブドメイン全体に適用することもできます。 |
次の FEATURE () 宣言はサポートされなくなりました。
表 14–26 宣言がサポートされていない FEATURE()
MAILER() を宣言すると、配信エージェントのサポートを指定できます。配信エージェントを宣言するには、次の構文を使用します。
MAILER(`symbolic-name') |
次の変更に注意してください。
この新しいバージョンの sendmail では、MAILER(`smtp') を宣言すると、メールプログラム dsmtp が追加されます。dsmtp により、メールプログラムのフラグ F=% を使用して、オンデマンドに配信することができます。dsmtp メールプログラムを定義する際には、新しい DSMTP_MAILER_ARGS を使用します。DSMTP_MAILER_ARGS のデフォルトは IPC $h です。
MAILER によって使用されるルールセットの番号は削除されました。MAILER(`uucp') を除いて、MAILER の表示順を自由に設定できます。uucp-dom および uucp-uudom を使用する場合には、MAILER(`smtp') のあとに MAILER(`uucp') を配置する必要があります。
メールプログラムの詳細は、「メールプログラムと sendmail」を参照してください。新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
次の表では、配信エージェントの追加されたフラグについて説明しています。デフォルトでは、これらのフラグは設定されていません。これらの 1 文字のフラグはブール型です。このフラグを設定したりその設定を解除したりするには、次の例のように、フラグを構文ファイルの F= 文に含めるか除外します。
Mlocal, P=/usr/lib/mail.local, F=lsDFMAw5:/|@qSXfmnz9, S=10/30, R=20/40, Mprog, P=/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/, Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990, Msmtp8, P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990, Mrelay, P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040, |
フラグ |
説明 |
---|---|
% |
このフラグを使用するメールプログラムは、ETRN 要求や次のいずれかのキューオプションを使ってキューにあるメッセージを選択しないかぎり、最初の受信者宛にメールを配信したり、キューを実行したりしません。 -qI、-qR、または -qS。 |
1 |
このフラグは、\0 などのヌル文字を送信するメールプログラムの機能を無効にします。 |
2 |
このフラグは、ESMTP の使用を無効にし、代わりに SMTP を使用するように要求します。 |
6 |
このフラグを指定すると、メールプログラムでヘッダーを 7 ビットにすることができます。 |
次の表では、配信エージェントを定義するコマンド M とともに使用できる新しい設定について説明しています。次の構文は、設定を新たに付加する方法、および構成ファイルの既存の設定に新しい引数を付加する方法を示しています。
Magent-name, equate, equate, ... |
次の例には、新しい設定 W= が含まれています。この設定は、すべてのデータが送信されたあとでメールプログラムが戻るまでの最長待ち時間を指定します。
Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, W=2m |
m4 の構成値の定義を変更するには、次の例のような構文を使用します。
define(`SMTP_MAILER_MAXMSGS', `1000') |
この例では、smtp メールプログラムで 1 回の接続で配信されるメッセージ数を 1000 に制限しています。
新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
通常、mailer ディレクトリで、この設定の定義を変更するのは、微調整が必要な場合だけです。
本リリースでは、複数のキューディレクトリをサポートしています。複数のキューを使用するには、次の例のように、アスタリスク (*) で終わっている QueueDirectory オプション値を構成ファイルに追加します。
O QueueDirectory=/var/spool/mqueue/q* |
このオプション値 /var/spool/mqueue/q* は、「q」で始まっているすべてのディレクトリ (またはディレクトリへのシンボリックリンク) をキューのディレクトリとして使用します。sendmail の実行中には、キューのディレクトリ構造を変更しないでください。キューを実行すると、デーモン以外のキューの実行時に冗長フラグ (-v) を使用しないかぎり、各キューについての実行プロセスが作成されます。この新しい項目が、無作為にキューに割り当てられます。
この新しいキューのファイルの名前付けシステムで使用する名前は、60 年間一意であることが保証されます。このシステムでは、キュー ID が複雑なファイルシステムのロックを使用しないで割り当てられるため、キューにある項目を簡単にほかのキューに移動することができます。
version 8.12 より、root だけがメールキューを実行できます。この変更の詳細は、mailq(1) のマニュアルページを参照してください。新しい作業手順については、「キューディレクトリの管理 (作業マップ)」を参照してください。
エンベロープの分割に対応するために、キューファイルの名前は 14 文字ではなく、15 文字にします。14 文字までの名前を持つファイルシステムは、サポートされません。
作業手順については、「キューディレクトリの管理 (作業マップ)」を参照してください。
次に、LDAP (Lightweight Directory Access Protocol) を sendmail で使用する際の変更点について説明します。
LDAPROUTE_EQUIVALENT() および LDAPROUTE_EQUIVALENT_FILE() を使用して、同じホスト名を指定することができます。これらのホスト名は、LDAP ルーティング参照のマスカレードドメイン名と置き換えられます。詳細は、/etc/mail/cf/README を参照してください。
ftp://ftp.sendmail.org で sendmail とともに配布しているリリースノートで説明しているように、LDAPX マップの名前は LDAP に変更されました。LDAP には、次の構文を使用します。
Kldap ldap options |
本リリースでは、一度の LDAP 参照に複数の値を返すことができます。次の例のように、返す値を -v オプションを付加したコンマ区切りの文字列に配置します。
Kldap ldap -v"mail,more-mail" |
LDAP マップの宣言で LDAP 属性が指定されていない場合は、一致した属性がすべて返されます。
このバージョンの sendmail は、LDAP 別名ファイルに指定された引用符などで囲まれたキーや値の文字列内のコンマによって、1 つのエントリが複数のエントリに分割されるのを防止します。
このバージョンの sendmail には、LDAP マップ用の新しいオプションがあります。この -Vseparator オプションを使用して、区切り文字を指定できます。そのため、検索を行うと、該当する separator によって区切られた属性と値の両方を返すことが可能です。
%s トークンを使用した LDAP フィルタ指定の構文解析に加えて、新しいトークンである %0 を使用して、キーバッファーを符号化することもできます。%0 トークンは、LDAP の特殊文字に対して、文字どおりの意味を適用します。
次の例では、これらのトークンが「 *」検索でどのように違うかを説明します。
表 14–29 トークンの比較
LDAP のマップ指定 |
同等の指定 |
結果 |
---|---|---|
-k"uid=%s" |
-k"uid=*" |
ユーザー属性を持つ任意のレコードに一致します |
-k"uid=%0" |
-k"uid=\2A" |
「 *」という名前を持つユーザーに一致します |
次の表では、LDAP マップの追加されたフラグについて説明しています。
表 14–30 LDAP マップの追加されたフラグ
フラグ |
説明 |
---|---|
-1 |
一致したレコードが 1 つだけだった場合、そのレコードを返します。複数のレコードが一致して返される場合には、結果として、レコードが検出されなかったことと同じとなります。 |
-r never|always|search|find |
LDAP 別名の参照を解除するオプションを設定します。 |
-Z size |
一致したもののうち、返すレコード数を制限します。 |
前のバージョンに組み込まれていたメールプログラム [TCP] は使用できません。代わりに、新しく組み込まれたメールプログラム P=[IPC] を使用してください。プロセス間通信 ([IPC]) 組み込みメールプログラムで、それをサポートするシステム上の UNIX ドメインソケットへの配信を行えるようになりました。このメールプログラムは、指定したソケットで待機している LMTP 配信エージェントとともに使用できます。次に、メールプログラムの例を示します。
Mexecmail, P=[IPC], F=lsDFMmnqSXzA5@/:|, E=\r\n, S=10, R=20/40, T=DNS/RFC822/X-Unix, A=FILE /var/run/lmtpd |
[IPC] メールプログラムの最初の引数の値が妥当であるか検査されるようになりました。次の表では、最初のメールプログラム引数に設定可能な値について説明しています。
表 14–31 最初のメールプログラム引数に設定可能な値
値 |
説明 |
---|---|
A=FILE |
UNIX ドメインソケットによる配信に使用します。 |
A=TCP |
TCP/IP 接続に使用します。 |
A=IPC |
最初のメールプログラム引数としては使用できません。 |
次の表では、追加されたルールセットとその動作について説明しています。
表 14–32 新しいルールセット
ルールセット |
説明 |
---|---|
ヘッダーから収集した情報を相関させ、欠けているヘッダーを検査します。このルールセットは、マクロストレージマップとともに使用し、すべてのヘッダーが収集されたあと、呼び出されます。 |
|
check_rcpt が RCPT を使用するように、ETRN コマンドを使用します。 |
|
check_rcpt が RCPT を使用するように、EXPN コマンドを使用します。 |
|
check_rcpt が RCPT を使用するように、VRFY コマンドを使用します。 |
次に、ルールセットの追加機能について説明します。
番号が付けられたルールセットには、名前も付けられました。ただし、これらのルールセットに、番号でアクセスすることもできます。
H ヘッダー構成ファイルコマンドを使用して、デフォルトルールセットを指定し、ヘッダーを確認することができます。各ヘッダーに、独自のルールセットが割り当てられていない場合にだけ、このルールセットが呼び出されます。
ルールセット内のコメント、つまり括弧内のテキストは、構成ファイルのバージョンが 9 かそれ以上である場合には削除されません。たとえば、次のルールは、入力 token (1) を照合します。ただし、入力 token は照合しません。
R$+ (1) $@ 1 |
TCP ラッパーまたは check_relay ルールセットが原因でコマンドを拒否する場合でも、sendmail は SMTP RSET コマンドを受け入れます。
OperatorChars オプションを何度も設定すると、警告が送信されます。また、ルールセットを定義したあとで OperatorChars を設定しないでください。
無効なルールセットを宣言すると、行だけでなく、そのルールセットの名前も無視されます。そのルールセットの行は S0 に追加されません。
Solaris 10 以降のリリースでは、読み取り専用の /usr ファイルシステムをサポートするために、/usr/lib/mail ディレクトリの内容が /etc/mail/cf ディレクトリに移動されました。詳細は、「/etc/mail/cf ディレクトリの内容」を参照してください。ただし、シェルスクリプト /usr/lib/mail/sh/check-hostname および /usr/lib/mail/sh/check-permissions は、/usr/sbin ディレクトリに置かれるようになりました。「メールサービスに使用するその他のファイル」を参照してください。下位互換性を確保するために、シンボリックリンクが各ファイルの新しい位置を示します。
/usr/lib/mail/cf/main-v7sun.mc の新しい名前は /etc/mail/cf/cf/main.mc です。
/usr/lib/mail/cf/subsidiary-v7sun.mc の新しい名前は /etc/mail/cf/cf/subsidiary.mc です。
helpfile は /etc/mail/helpfile にあります。古い名前 (/etc/mail/sendmail.hf) には、新しい名前へのシンボリックリンクがあります。
trusted-users ファイルは /etc/mail/trusted-users にあります。アップグレード中に、新しい名前は検出されず、古い名前である /etc/mail/sendmail.ct が検出されると、古い名前から新しい名前へのハードリンクが作成されます。それ以外の場合には、変更されません。デフォルトの内容は、root です。
local-host-names ファイルは /etc/mail/local-host-names にあります。アップグレード中に、新しい名前は検出されず、古い名前である /etc/mail/sendmail.cw が検出されると、古い名前から新しい名前へのハードリンクが作成されます。それ以外の場合には、変更されません。デフォルトの内容は、ゼロ長です。
sendmail の version 8.12 より、アドレスを正しく識別するために、構成に使用する IPv6 アドレスの前に IPv6: タグを付ける必要があります。IPv6 アドレスを識別しない場合は、タグを前に付けません。