7    メール・システム

Tru64 UNIX のメール・システムを使用すれば,同じシステムや同じネットワークのユーザばかりでなく, 異なるシステムやネットワークにいるユーザにもメールを送信できます。 この章では,以下の項目について説明しています。

メールについての詳細は, mail_intro(7),『sendmail』(O'Reilly & Associates),および『Sendmail Installation and Operation Guide』を参照してください (PDF 形式 のファイルが Tru64 UNIX Documentation CD-ROM に用意されています)。 sendmail ユーティリティの問題解決情報については 9.12 節を,POP および IMAP メールについての問題解決情報については 9.13 節を参照してください。

Tru64 UNIX のメール・デーモン群は,Sendmail 社の sendmail Version 8.11.1,Qualcomm 社の POP3 Version 3.0.2,およびカーネギー・メロン大学の Cyrus IMAP4 Version 1.6.24 をベースにしています。 オペレーティング・システムに付属しているバージョンより新しいバージョンのパッケージが必要であれば,上記の提供元から直接入手することができます。 また,Internet Express for Tru64 UNIX も利用できます。 Internet Express は,主要なオープンソース・ソフトウェアを 1 枚の CD-ROM に集めた製品です。

Internet Express キットは年に数回アップデートされ配布されています。 このため Internet Express キットには通常,オペレーティング・システムよりも新しいバージョンのオープンソース・ソフトウェアが収録されています。 さらに Internet Express には,マスカレード機能や,仮想ドメイン,スパム対策,LDAP (Lightweight Directory Access Protocol) といった,高度な sendmail 機能を容易に構成できる管理ユーティリティも含まれています。 Internet Express についての詳細は,次の URL を参照してください。

http://h50146.www5.hp.com/products/software/oe/tru64unix/internet/

7.1    メール環境

メール環境における各システムの役割は次のとおりです。

図 7-1に示すのは, すべてのシステムがメール・スタンドアロン・システムとして構成されているスタンドアロン構成の LAN の例です。 ホスト B は NFS サーバでもあり, /var/spool/mail ディレクトリをホスト A,C,D および E にエクスポートしています。 ホスト A, C,D および E は NFS クライアントでもあり, /var/spool/mail ディレクトリをホスト B からインポートしています。

各ホストは,passwd および aliases ファイルに識別情報を持っている必要があります。 この情報は,NIS によってあるいは各システムのファイルを手で編集することによって分散させることができます。

図 7-1:  メール・スタンドアロン構成の例

図 7-2 に示すのは,ホスト B がメール・サーバとして構成され, ホストA,C,D および E がメール・クライアントとして構成されているクライアント/サーバ構成の例です。 このような構成は,複数のドメインとインターネットあるいはその他のネットワークとの接続からなる大規模なエンタープライズ・ネットワークにおいて有効です。

このような構成は,複数のドメインを含む大規模エンタープライズ・ネットワークにおいて自然発生的なメール・サーバの階層を作成することにもなります。 各ドメインのメール・クライアントは,すべてのトラフィックを, ドメインのクライアント数に依存して 1 つあるいは複数のメール・サーバに送ります。 各ドメインのサーバは,それらのメールをインターネットに転送するために, エンタープライズの最上位ドメイン・サーバに転送します。 ほとんどすべてのローカル・ドメインのメール・トラフィックがこのサーバを通過するため, このサーバを管理するだけでメール環境の管理および問題解決を簡単に行うことができます。

図 7-2 のインターネットへの接続は, 直接行うことも,ローカルのアクセス・プロバイダを通して行うことができます。 ビジネス環境における典型的な構成では, ファイアウォールと専用のメール・サーバを使用します。 ファイアウォールを使用する場合は, ファイアウォールとメール・サーバが相互に機能するように構成することが必要です。 詳細については,ファイアウォール製品のドキュメントを参照してください。

図 7-2:  メール・クライアント/サーバ構成の例

SMTP (Simple Mail Transfer Protocol),UUCP (UNIX-to-UNIX Copy Program),DECnet など,異なるメール・プロトコルを使用しているシステム間でメールを送信する必要がある場合は,これらの機能を実行する専用のサーバ・システムをネットワーク内に設けることをお勧めします。 このようなサーバ・システムをメール中継と呼びます。

その他のメール構成も可能ですが,その場合はより綿密な計画と構成が必要になります。 詳細については,『sendmail』(O'Reilly and Associates) および『Sendmail Installation and Operation Guide』を参照してください。

クライアント/サーバ・メール環境を実現するためには, 次のことを決める必要があります。

次の各項でこれらについて説明します。

7.1.1    発信メールのサーバへの配信

サーバに対して発信メールに関する指定をするには,/etc/namedb/hosts.db ファイルに DNS メール・エクスチェンジャ (MX) のエントリを含めます。 このエントリは,ローカル・ネットワークに直接接続されていないシステムにメールを送ることが可能な,ローカル・ドメインのシステムを指定します。 MX を使用してメールの経路を決めると次のような利点があります。

/etc/namedb/hosts.db ファイルへのエントリの追加についての説明は,2.8.2 項および bind_manual_setup(7) を参照してください。

7.1.2    ドメインに対する着信メールの処理

ドメインへの着信メールの処理を簡単にし信頼性を向上させるために,メール環境では,ドメイン・ベースのアドレスを使用します。 インターネットに送信されるメールは,次のフォーマットでアドレスを指定します。

username@hostname.domain

次に例を示します。 joe@host1.nyc.big.com

ドメイン・ベースのアドレスを使用すると,上記のアドレスは,次のようになります。

joe@.nyc.big.com

メールは,ローカル・ドメイン内の特定のホスト host1.nyc.big.com に送信される代わりに,ローカル・ドメイン nyc.big.com に送信されます。 つまり,リターン・アドレスも @nyc.big.com です。 その後に,ローカル・ドメイン内のメール・サーバ・マシンが, メールをユーザ・アカウントに配布する方法を決定します。

ドメイン・ベースのアドレスを使用すると,メール環境の管理を簡単にすることができます。 ドメイン・ベース・アドレスを使用すると, メールの配布を一時不通にしないでもシステムの変更 (ユーザ・アカウントの移動,システムの入れ替え/移動など) を行うことができます。 これらの変更を行っても,ご使用のシステムへメールを送ってくるユーザには影響を与えません。

7.1.3    クライアントへのメールの配布

メールがドメインへ送られると, 次のいずれかのメカニズムでクライアントへ配布されます。

各クライアントにメールを送るためには, ドメイン内の各サーバがクライアント上の各ユーザのエントリを含む別名ファイルを持っていることが必要です。 次に例を示します。

username1: username1@client1
username2: username2@client1

7.1.4    別名ファイルの分散

スタンドアロンおよびサーバ・システムに対しては,NIS を使用して 1 つのマシンからメール別名ファイルを分散させます。 スタンドアロン・システムの LAN 環境では,NFS サーバ・システムからメール別名ファイルを分散します。 クライアント/サーバ環境では,ドメインのサーバに別名(aliases)ファイルを分散します。 システム間で別名(aliases)ファイルを共有することにより,どちらの場合も,メール別名の変更は 1 つの別名ファイルに対してだけ行えはよいので管理が簡単になります。

データベースについての詳細は, aliases(4) を参照してください。 NIS でのデータベースの分散についての詳細は,7.6.3 項 および 第 3 章 を参照してください。

7.1.5    passwd ファイルの分散

1 つのドメインで複数のサーバ・システムを使用している場合は, passwd 情報が各システムで同一になるようにしてください。 セキュリティの確保と確実なメール配送を期するためにも,passwd ファイルの編集は,各サーバ・システムごとに手作業で実施するようにしてください。

7.1.6    DECnet メールの処理

メール・サーバ・システムを設定する場合には,DECnet Phase IV と DECnet/OSI のメール・アドレスのフォーマットが,TCP/IP のメール・アドレスのフォーマットとは異なることを考慮する必要があります。 したがって,DECnet ノードと TCP/IP ノードの間でメールを送信する場合には,マップ・スキーマを確立してメール・アドレスを変換する必要があります。

DECnet Phase IV の sendmail プログラムの Tru64 UNIX バージョンで使用しているマップ・スキーマは,擬似ドメイン内に DECnet アドレスをカプセル化する方式です。 たとえば,通常の DECnet Phase IV アドレスは,次のフォーマットを使用しています。

nodename::username

このフォーマットでアドレスを指定されたメールは,次のフォーマットのアドレスにマップされます。

username@nodename.pseudodomain.top.domain

各変数の意味は次のとおりです。

username

ユーザ名です。

nodename

DECnetのノード名です。

pseudodomain

DECnet の擬似ドメインを指定する任意の文字列です。 擬似ドメインには自由な文字を使用することができますが,組織内で統一されていることが必要です。 すべてのメール・システムは同じ擬似ドメイン名を使用して構成しなければなりません。

top.domain

通常,ユーザの会社のドメイン名です。 たとえば,abc.com です。

DECnet/OSI のマッピングも,同様の方式を使用します。 通常の DECnet/OSI アドレスは,次のフォーマットを使用します。

username@namespace:.site.nodename

このフォーマットでアドレスを指定されたメールは,次のようにマップされます。

username@nodename.site.namespace.pseudodomain.top.domain

DECnet Phase IV と同じように,擬似ドメインには,任意の文字列を使用できます。 ただし,ユーザの組織内で DECnet Phase IV と DECnet Phase V の両方を使用する場合は,別の擬似ドメイン名を使用するようにしてください。

DECnet Phase IV と DECnet/OSI の両方をサポートする環境では, DECnet ベースのメールの処理に DECnet Phase IV のシンタックスを使用します。 これによりメールの管理作業が簡単になっています。 この動作を実現するためには, すべての DECnet-OSI ノードがユニークな Phase IV シノニムを持ちそのシノニムを使用して構成されていなければなりません。 次のコマンドを入力することによって,DECnet/OSI ホストを再構成することができます。

# ncl set session control application mail11 Node Synonym=true

詳細については,DECnet/OSI のドキュメントを参照してください。

7.2    メール・システムの計画

この節では,メールを構成する前に必要な作業について説明します。

7.2.1    必要なプロトコルがインストールされているかどうかの確認

メール・サーバでサポートしているプロトコルに依存して, 次に示す必要なサブセットがインストールされ構成されているかどうか確認します。

各製品のインストレーションおよび構成については, それぞれの製品のドキュメントを参照してください。 UUCP サブセットがインストールされているかどうかは, 次のコマンドを使用して確認することができます。

# setld -i | grep OSFUUCP

必要なサブセットがインストールされていない場合は,setld コマンドを使用してインストールしてください。 サブセットのインストレーションについては, setld(8) または『インストレーション・ガイド』を参照してください。

7.2.2    必要なサービスが構成されているかどうかの確認

次の表に,特定のメール構成に対して必要なサービスについて示します。

使用するメール機能 必要なサービス
別名ファイルの分散 NIS
ドメイン・ベース・アドレッシングの使用 DNS/BIND

NIS が必要な場合,NIS が構成されたかどうかを確認するためにroot ユーザとして次のコマンドを入力します。

# rcmgr get NIS_CONF

コマンドが NO を返した場合は,NIS は構成されていません。 NIS の構成方法と aliases ファイルの分散方法については, 第 3 章を参照してください。

DNS が必要な場合は,DNS が構成されたかどうかを確かめるために root ユーザとして次のコマンドを入力します。

# rcmgr get BIND_SERVERTYPE

コマンドが何も返さない場合は,DNS は構成されていません。 DNS を構成する方法については,第 2 章を参照してください。

7.2.3    構成の準備

必要なプロトコルをインストールし必要なサービスを構成したら, メール設定アプリケーションを使用してメールを構成します。

メールの構成には次の処理が必要です。

この後の項には,メールを構成するのに必要な情報を記録するワークシートが含まれます。

7.2.3.1    一般的なシステム情報

図 7-3 に基本メール設定ワークシートを示します。 本書をオンラインで参照している場合には,プリント機能を使用してこのワークシートをプリントすることができます。 この後の項では,ワークシートに記録するのに必要な情報について説明します。

図 7-3:  基本メール設定ワークシート

メール・サーバ (クライントのみ)

foo.dec.com のような,メール・サーバの完全な名前。 または,ドメイン・ベース・ルーティングを使用している場合は,dec.com というようなドメイン名。 これは,メール・サービスがシングル・メール・サーバが利用できなくなったときに切断されないので,ドメイン名自身を指定するのに好都合です。

トップ・ドメイン (サーバのみ)

組織ないでユニークに識別される,組織内の最上位ドメインの名前。 たとえば,サーバ・ドメイン名が nyc.big.com の場合,トップ・ドメインは big.com です。 サーバ・ドメイン名が cs.big.univ.ac.uk の場合,トップ・ドメインは big.univ.ac.uk です。

メールボックス・ディレクトリ

メールボックスの位置です。

スタンドアロンまたはクライアント・システムで,メールボックス・ディレクトリがローカル・システムにある場合は,「ローカル」をチェックします。 メールボックスがリモート・システムにあり,NFS を使用してローカル・システムにマウントされている場合は,「NFS クライアント」をチェックします。 ローカル・システムがメールボックスを NFS クライアントにエクスポートする場合は,「NFS サーバ」をチェックします。

サーバ・システムの場合は,他のシステムに対してもメールボックス・ディレクトリが使用できるように「NFS サーバ」をチェックしてください。 メールボックス・ディレクトリを共用したくない場合は,「ローカル」をチェックします。 この場合,aliases コマンドを使用して各ユーザのメールを適切なシステムへ送ります。 詳細については,7.6.3 項 および aliases(4) を参照してください。

ロッキング

メールボックスで使用するファイル・ロックのタイプです。

スタンドアロンおよびクライアント・システムの場合,メールボックス・ディレクトリを持つホストが Tru64 UNIX システムである場合は,「lockf」をチェックします。 こうすることにより最大の性能が得られます。 メールボックス・ディレクトリを持つホストのオペレーティング・システムがわからない場合は,「ロック・ファイル」をチェックします。 両方を使用したい場合は,「両方」をチェックします。

注意

選択するロック・メカニズムは,NFS サーバで使用するものと同じでなければなりません。 NFS サーバで設定されているロック・メカニズムがわからない場合は,NFS サーバの管理者に確認してください。

サーバ・システムの場合,メールボックスの位置をとして「ローカル」を指定していれば,「Lockf」をチェックします。 メールボックスの位置をとして「NFS クライアント」を指定していれば,「ロック・ファイル」をチェックします。 メールボックスの位置をとして「NFS サーバ」を指定していれば,「両方」をチェックします。

メールボックス・サーバ

メールボックスをユーザのローカル・システムにエクスポートするシステムの名前です。

7.2.3.2    プロトコル情報

図 7-4 にメール・プロトコル・ワークシートを示します。 本書をオンラインで参照している場合は,このワークシートをプリント機能を使用してプリントすることができます。 この後の項では,ワークシート上に記録する必要のある情報につて説明します。

図 7-4:  メール・プロトコル・ワークシート

システムをインターネット (SMTP) サーバとして構成するには,次の情報を収集する必要があります。

転送

中継ホストに転送するメールのタイプです。 ローカルホストがインターネットに直接アクセスでき,メールをまったく転送しない場合は,「無し」をチェックします。 ローカルホストが,最上位ドメインの外部にアドレスを指定したメールをすべて転送する必要がある場合は,「インターネット」をチェックします。 ローカルホストが,ローカル・インターネット・ドメインの外部にアドレスを指定したメッセージをすべて転送する必要がある場合は,「ローカル以外」をチェックします。 ローカルホストが,ローカル・ドメイン・メールを含むメールをすべて転送する必要がある場合は,「ローカル」をチェックします。

中継ホスト名

SMTP メールを処理するリモート・ホストの名前です。

中継プロトコル

サーバが中継ホストへのメッセージ転送に使用するプロトコルの名前です。

擬似ドメイン

SMTP メールの擬似ドメインを指定する任意の文字列です。 擬似ドメイン名はプロトコルごとに一意とし,組織内全体で一貫性を持たせなければなりません。

擬似ドメインの別名

擬似ドメインを指定する別名です。

ホストの別名

ホストにメールを送信するために,他のシステムが使用する可能性がある代替名。

システムを他のメール・プロトコル用のサーバとして構成するには,次の情報を収集する必要があります。

プロトコル

メール・ゲートウェイとして機能しているシステムについて,サポートしているメール・プロトコルのタイプです。 使用できるプロトコルには,次のものがあります。

ルーティング

DECnet,DECnet/OSI,UUCP,MTS,および X.25 専用です。 特定のプロトコルのメールをネットワーク経由でゲートウェイに転送する場合は,「インターネット」をチェックします。 インターネットは DNS によって適切な中継を選択します。 したがって,インターネットに対する中継ホスト名は指定しないでください。

特定のプロトコルがサーバにインストールされている場合は,「直接」をチェックします。 特定のプロトコルを必要とするメールを他のシステムへ転送して処理する場合は,「中継」をチェックします。 この場合,「中継ホスト名」および「中継プロトコル」フィールドを埋める必要があります。

中継ホスト名

対象プロトコルのメールを処理回送するリモート・ホスト名です。

中継プロトコル

サーバが中継ホストにメッセージを転送するために使用するプロトコルの名前です。

ノード・アドレス (DECnet)

マシンのアドレスです (DECnet 専用)。

DNS ネーム・スペース (DECnet/OSI)

このノードの,完全な DNS ネーム・スペース名です (DECnet/OSI 専用)。 DNS ネーム・スペースの構文は,次のとおりです。

namespace:.site.nodename

擬似ドメイン

擬似ドメインを指定する任意の文字列です (DECnet,DECnet/OSI,および MTS 専用)。 擬似ドメイン名は各プロトコルでユニークで,企業全体で一貫して使用される必要があります。

擬似ドメインの別名

擬似ドメインの任意の別名です (DECnet,DECnet/OSI,UUCP,および MTS 専用)。

ホストの別名

ホストにメールを送信するために,他のシステムが使用する可能性のある別名です。

7.3    メールの構成

グラフィック機能を備えているシステムでメールを構成するには,CDE のアプリケーション・マネージャから起動できるメール設定アプリケーションを使用します。

注意

別の方法として,SysMan Menu (/usr/sbin/sysman mailsetup) または mailsetup ユーティリティを使用してシステムにメールを構成することもできます。 詳細については,オンライン・ヘルプおよび mailsetup(8) を参照してください。

次のシステムを構成できます。

メール設定アプリケーションをスタートさせるには,次の手順に従ってください。

  1. ルートとしてログインします。

  2. CDE フロント・パネルのアプリケーション・マネージャ・アイコンをクリックします。

  3. 「システム管理」アプリケーション・グループ・アイコンをダブルクリックします。

  4. 「システム設定」アプリケーション・グループ・アイコンをダブルクリックします。

  5. 「メール」アプリケーション・アイコンをダブルクリックします。 「メールの設定」メイン・ウィンドウが表示され,使用可能なメール・サービスのタイプと,構成済みのメール・サービスのタイプが表示されます。

メール設定アプリケーションを終了するには,[ファイル] メニューから [終了]を選択します。 詳しくは, mailconfig(8) を参照してください。

メール設定アプリケーションには,オンラインヘルプが用意されています。

7.3.1    スタンドアロン・メール・システムの構成

スタンドアロン・システムのメールを構成するには,次の手順に従ってください。

  1. 「メールの設定」ウィンドウから, 「利用可能なメール・サービスの種類」リスト・ボックスから「Standalone」を選択します。

  2. [設定...] を選択します。 「Standalone Setup」ダイアログ・ボックスが表示されます。

  3. システム・メールボックス・ディレストリ (たとえば /var/spool/mail) をインポートまたはエクスポートするのに NFS を使用する場合は, [メールボックスの設定] を選び「メールボックスの設定」ダイアログ・ボックスを表示します。 それ以外の場合は,手順 7 に進みます。 省略時の設定は,ユーザのメール構成に適用されます。

  4. システムが,NFS を使用して自分のメールボックスをインポートする場合は, 「NFS クライアント」ラジオ・ボタンを選択し,次のことを行います。

    1. 「メールボックス・サーバ」フィールドにサーバ名を入力します。

    2. 「lockf」,「ロック・ファイル」,「両方」のロック・メカニズムのうちいずれか 1 つを選択します。

  5. システムが NFS クライアントにメールボックスを配布する場合は,「NFS サーバ」ラジオ・ボタンを選択し,「両方」を選択します。

  6. [了解] をクリックしてメールボックスの設定を完了し, 「メールボックスの設定」ダイアログ・ボックスをクローズします。

  7. [コミット] をクリックして,変更を保存します。 sendmail デーモンを再起動するかどうか質問がきます。

  8. [再起動] をクリックして,sendmail デーモンを再起動して変更を有効にします。 または,[いいえ] をクリックして次回システムをリブートする際に変更が有効になるようにします。

    [再起動] を選択すると,sendmail デーモンが開始されたことが知らされます。 [了解] をクリックするとそのメッセージは消えます。

  9. [閉じる] をクリックして「Standalone Setup」ダイアログ・ボックスをクローズします。

7.3.2    メール・クライアントの構成

メール・クライアントを構成するには,次の手順に従ってください。

  1. 「メールの設定」ウィンドウから, 「利用可能なメール・サービスの種類」リスト・ボックスの「Client」を選択します。

  2. [設定...] ボタンをクリックします。 「Client Setup」ダイアログ・ボックスが表示されます。

  3. 「メールボックス・サーバ」入力テキスト・ボックスをクリックして, メール・サーバの名前を入力します。

  4. [メールボックスの設定] をクリックします。 「メールボックスの設定」ダイアログ・ボックスが表示されます。

  5. サイトがシステム・メールボックス・ディレクトリを共用するためにNFSを使用する場合は, 「メールボックス・ディレクトリ」の「NFS クライアント」ラジオ・ボタンを選択します。 それ以外の場合は,「ローカル」をクリックし,手順 7 に進みます。

  6. メールボックス・ディレクトリをシステムへエクスポートするサーバの名前を「メールボックス・サーバ」フィールドに入力します。

  7. ロッキング・メカニズムを有効にするために「loackf」,「ロック・ファイル」,または「両方」のいずれか 1 つのラジオ・ボタンをクリックします。

  8. [了解] をクリックしてメールボックスの設定を終了し, 「メールボックスの設定」ダイアログ・ボックスをクローズします。

  9. [コミット] をクリックして変更を保存します。 sendmail デーモンを再起動するかどうかの質問がきます。

  10. 「設定」ダイアログ・ボックスの [再起動] をクリックして, sendmail デーモンを再起動し変更を有効にします。 または,[いいえ] を選択して次回システムをリブートする際に変更が有効になるようにします。

    [再起動] を選択するとsendmail デーモンが開始されたことが知らされます。 [了解] をクリックするとメッセージは消えます。

  11. [閉じる] をクリックして「Client Setup」ダイアログ・ボックスをクローズします。

7.3.3    メール・サーバの構成

メール・サーバを構成するには,次の手順に従ってください。 POP または IMAP デーモンをインプリメントする場合は,SMTP とその他必要なプロトコルを最初に構成してから, 7.4 節および 7.5 節を参照してください。

  1. 「メールの設定」ウィンドウから, 「利用可能なメール・サービスの種類」リスト・ボックスの「Server」を選択します。

  2. [設定...] ボタンをクリックします。 「Server Setup」ダイアログ・ボックスが表示されます。

  3. 「利用可能なプロトコル」リスト・ボックスから,このシステムで使用するために構成したいメール・プロトコルを選択します。 Internet Mail Protocol (SMTP) プロトコルは,唯一の必須プロトコル構成です。 必要に応じて,追加のプロトコルを構成します。

  4. [設定...] ボタンをクリックします。 選択したプロトコルのプロトコル設定ダイアログ・ボックスが表示されます。

  5. SMTP プロトコルの場合は,このサーバの転送のタイプを選択します。 [なし] をクリックした場合は,手順 11 に進みます。 [なし] をクリックしない場合は,手順 7 に進みます。

  6. DECnet,DECnet/OSI,MTS,UUCP,およびX.25プロトコルの場合は,ルーティングを選択します。 [インターネット] または [直接] をクリックした場合は,手順 9 に進みます。 [中継] をクリックした場合は,手順 7 に進みます。

  7. メールを別のシステムに転送して処理する場合は,「中継ホスト名」フィールドにホスト名を入力します。 それ以外の場合は,手順 9 に進みます。

  8. [中継プロトコル] プルダウン・メニューで中継ホストとの通信に使用するプロトコルを選択します。

  9. DECnet,DECnet/OSI,および MTS のプロトコルの場合は, 「擬似ドメイン」テキスト入力フィールドに, 選択したプロトコルを必要とするメールの識別に使用するドメイン名を入力します。

  10. DECnet,DECnet/OSI,MTS,UUCP,および X.25 プロトコルの場合に,擬似ドメインの別名を追加するには, [擬似ドメインの別名] をクリックして「擬似ドメインの別名」を表示し,次の手順に従ってください。

    1. 「別名」フィールドに別名を入力し,[追加] をクリックします。

    2. 1 つ前の手順を必要な回数だけ繰り返します。

    3. [了解] をクリックして,「擬似ドメインの別名」ダイアログ・ボックスをクローズします。

  11. このメール・サーバの別名を追加するには,[ホスト別名] をクリックして「ホスト別名」を表示し,次の手順を行います。

    1. 「別名」フィールドに別名を入力して,[追加] をクリックします。

    2. 1 つ前の手順を必要な回数だけ繰り返します。

    3. [了解] をクリックし,「ホスト別名」ダイアログ・ボックスをクローズします。

  12. DECnet プロトコルの場合は,「Node Address」フィールドに DECnet ノード・アドレス(area.node) を入力します。 たとえば,32.958です。

  13. DECnet/OSIプロトコルの場合は,「DNS Name Space」フィールドにノードのネーム・スペースを入力します。 通常,DECnet Phase V アドレスのコロン (:) の前にあるトークンです。

  14. [了解] をクリックし,選択したプロトコルの「設定」ダイアログ・ボックスをクローズします。 「Server Setup」ダイアログ・ボックスが有効になります。

  15. 必要な場合には,別のプロトコルを構成します。 各プロトコルに対して,手順 3 から 15 の操作を行います。

  16. [メールボックスの設定] をクリックします。 「メールボックスの設定」ダイアログ・ボックスが表示されます。

  17. [メールボックス・ディレクトリ] をクリックします。

    サイトがシステム・メールボックス・ディレクトリを分散するために,NFSを使用しない場合は,[NFS クライアント] の代わりに [ローカル] をクリックして,手順 19 に進みます。

  18. メールボックス・ディレクトリとして [NFS クライアント] を選択した場合は, 「メールボックス・サーバ」フィールドにメール・サーバ名を入力します。 必ずドメインを含めます。 たとえば,mailhub という名前のサーバの場合は, ドメインを含めたサーバ名が mailhub.nyc.dec.com になります。

  19. 「lockf」,「ロック・ファイル」,「両方」のロック・メカニズムのうちのいずれか 1 つをクリックします。

  20. [了解] をクリックしてメールボックスの設定を完了し,「メールボックスの設定」ダイアログ・ボックスをクローズします。

  21. 「設定」ダイアログ・ボックスの [再起動] をクリックして,sendmail デーモンを再起動し変更を有効にします。

  22. [再起動] を選択して sendmail デーモンを開始し,変更をすぐに有効にします。 または [いいえ] を選択して,次回システムをリブートする際に変更が有効になるようにします。

    [再起動] を選択すると,sendmail デーモンが開始されたことが知らされます。 [了解] を選択してメッセージを消します。

  23. [閉じる] をクリックして「Server Setup」ダイログ・ボックスをクローズします。

  24. 必要に応じて,システム環境の各ホストごとに DNS メール・エクスチェンジャ (MX) レコードを /etc/namedb/hosts.db ファイルに追加します。 詳細については,7.1.1 項 を参照してください。

7.3.4    新しいメール・ホストの追加

既存のメール環境に新しいメール・ホストを追加するには,次のことを行います。

  1. ネットワークおよびネットワーク・サービスをホスト上に構成します。 詳細については,『ネットワーク管理ガイド:接続編』を参照してください。

  2. 既存の環境で DNS MX レコードを使用している場合は,DNS データ・ファイルをアップデートします。 詳細については,7.1.1 項を参照してください。

7.4    POP (Post Office Protocol)

POP3 または POP (Post Office Protocol Version 3) は,ユーザがメール・サーバからリモート・クライアントに,電子メールをダウンロードできるようにするためのクライアント/サーバ・プロトコルです。 これは主に,ユーザがオフライン・モードで電子メールにアクセスすることを前提としています。 オフライン・モードでは,メッセージがサーバに配信され,ユーザがサーバに接続して着信メッセージをクライアント・マシン (Windows,Macintosh,UNIX,その他のオペレーティング・システムを実行しているデスクトップまたはラップトップ・コンピュータ) にダウンロードするまで,サーバ上に置かれます。 それ以降,すべてのメッセージは,クライアント・マシンおよび環境でローカルに処理されます。 これは,今日,ISP (インターネット・サービス・プロバイダ) が顧客に電子メールを提供するために広く使用している方法です。 詳細については, pop3d(8) を参照してください。

7.4.1    POP のインストール

このオペレーティング・システムは,Qualcomm, Incorporated の POP サーバ (/usr/sbin/pop3d) を提供しており,OSFINET サブセットのインストール時に,フル・インストレーションと構成が行われます (警告やエラーについては,インストレーション・ログ・ファイルを参照してください)。 pop3d デーモンは,ポート 110 で着信接続を待つように構成されているので,システムのすべてのユーザが POP クライアント経由で自分の電子メールにアクセスすることができます。  

インストール時に,/etc/passwd/etc/services,および /etc/inetd.conf 構成ファイルが更新されます。 次の例に表示される行が構成ファイルに存在しない場合,POP3 サービスが適切に動作しないことがあります。 旧バージョンの POP が検出された場合,または OSFINET サブセットが正しくインストールされていない場合,ファイルが更新されないために,手動で変更を行わなければならないことがあります。

/etc/passwd ファイルには,次の行が必要です。 存在しない場合は,ファイルに追加します。

pop:*:13:6:POP Mail Service Account:/:
 

必要に応じて,13 というユーザ ID をシステムに適した値に変更します。

/etc/services ファイルには,次の行が必要です。 存在しない場合は,ファイルに追加します。

pop3    110/tcp
 

/etc/inetd.conf ファイルには,次の行が必要です。 存在しない場合は,ファイルに追加します。

pop3    stream  tcp     nowait  root    /usr/sbin/pop3d    pop3d
 

7.4.2    新しい POP3 実装への移行

Tru64 UNIX Version 5.0 で,POP サービスがアップグレードされました。 移行パスは,OSFMH (RAND Corp. Mail Handler) サブセットまたはQualcomm POP3 サービス (使用しているバージョンが直接 Qualcomm から提供されている場合) のいずれかで提供されているバージョンの POP3 を実行しているシステムについて用意されています。

MH POP3 サービスを使用している場合,POP ユーザ アカウントを /usr/spool/pop/POP ファイルから mailauth データベースに移行し,メールボックスを新しい形式に変換する必要があります。

Qualcomm POP3 サービスを使用している場合,POP ユーザ・アカウントを popauth データベースから mailauth データベースに移行する必要があります。 ただし,メールボックスの変換は不要です。 Qualcomm POP3 と Tru64 UNIX における Qualcomm POP3 の実装の相違点は,POP および IMAP のセカンダリ・パスワードを格納するよう拡張されたメール認証データベースだけです。

次の項では,各サービスの移行パスを説明します。 詳細については, popcv(8) を参照してください。

7.4.2.1    MH POP3 からの移行

MH POP3 から新しく実装された POP3 に移行するには,次のタスクを実行します。

  1. /sbin/rc ディレクトリにある /usr/lib/mh/popd ファイル用のスタートアップ・スクリプトをすべて削除します。

  2. /etc/inetd.conf および /etc/services 構成ファイルが 7.4.1 項 で説明されているとおりに,正しいエントリによって更新されていることを確認します。

  3. 次のコマンドを入力して,mailauth データベースを初期化します。

    # /usr/bin/mailauth -init
    

  4. popcv ユーティリティを使用して,ユーザ名とパスワードを /usr/spool/pop/POP ファイルから mailauth データベース (/etc/pop.auth.pag および /etc/pop.auth.dir) に移動します。 次のコマンドを入力します。 ここで,filename は,POP パスワードの格納に使用するファイル名に変更します)。

    # /usr/bin/popcv [filename]
    

  5. mailcv ツールを使用して,既存の MH POP3 メール・フォルダを新しい POP3 形式に変換します。

    1. ディレクトリを MH POP3 メール・フォルダ・ディレクトリに変更します。

      # cd /usr/spool/mail/POP
      

      MH POP3 の構成方法に応じて,ディレクトリは /usr/spool/pop または 他のディレクトリになります。

    2. 各メール・ユーザについて,次のコマンドを入力します。 ここで,input は,ユーザの MH POP3 フォルダのファイル名です。

      # /usr/dt/bin/mailcv -Q -f input
      

      通常,ファイル名は,POP ユーザのユーザ名と同じです。 たとえば,ユーザ名が Jake の場合,/usr/spool/mail/POP/jake というファイルを変換します。

      オプションとして,変換プロセスの際に,次の例のように新しいファイル名をコマンドの後に付けて,メール・フォルダの名前を変更することができます。

      # /usr/dt/bin/mailcv -Q -f charlie chuck
      

      詳細については, mailcv(1) を参照してください。

7.4.2.2    Qualcomm POP3 からの移行

Qualcomm の POP3 サービスから新しく実装された POP3 に移行するには,次のタスクを実行します。

  1. /etc/inetd.conf および /etc/services 構成ファイルが,7.4.1 項 で説明されているとおりに,正しいエントリによって更新されていることを確認します。

  2. 古い popauth データベースが存在する場合は,次のコマンドを使用して mailauth データベースに変換します。

    # /usr/bin/mailauth -convert
    

メール・フォルダの変換が必要になるのは,以前に MH POP3 サーバを実行していた場合のみです。

7.4.3    POP メール・アカウントの構成

POP メール・アカウントを構成するには,ユーザ用の UNIX アカウントがまだ作成されていない場合は,『システム管理ガイド』 ガイドの説明に従ってアカウントを作成します。 ユーザのメールボックスは,自動的にセットアップされます。

ユーザのアカウントがサーバにセットアップされると,ユーザは,たとえば Netscape Communicator のような,オペレーティング・システム・ソフトウェアにバンドルされた POP3 互換のメール・アプリケーションを構成できるようになります。 ユーザには,ファシリティのメール・サービスについて,最低限,次の情報を提供する必要があります。

7.4.4    ログイン認証の変更

POP サービスは,一般には,与えられたユーザ名とパスワードを UNIX パスワード・ファイル (通常,/etc/passwd ファイル) に照らして確認することにより,ユーザ・アカウントを認証します。 Tru64 UNIX による POP の実装では,必要に応じて,C2 セキュア・システム上における認証のための SIA インタフェースをサポートするよう拡張されています。

セキュリティを向上させるため,システム管理者は,POP ユーザにログイン・パスワードに変わる代替パスワードを使用させることができます。 このため,POP パスワードがネットワーク上で侵害を受けた場合でも,システムへのアクセスが危険にさらされることがなくなります。

POP 認証のための代替パスワードを有効にするには,次の 2 つの方法があります。

CDE (Common Desktop Environment) のアプリケーション・マネージャの SysMan Menu アプリケーションを使用すれば,いずれの認証方法も有効にすることができます。 SysMan Menu アプリケーションを起動するには,1.2.1 項 の指示に従った後,次の手順を実行してください。

注意

管理している環境にいるユーザが,従来の POP3 を実装したアプリケーションを使用している場合,7.4.2 項の説明に従ってそれらを新しい POP3 の実装に移行してから,代替パスワードを有効にします。

  1. SysMan Menu で,[メール] --> [メール・アカウントの管理] を選択します。 「メール・ユーザ管理」ウィンドウが表示されます。 また,次のコマンドを実行して,このユーティリティを起動することも可能です。

    # sysman mailusradm &
    

  2. 「特定のユーザのリスト」ラジオ・ボタンを選択し,[コンパイル・リスト] をクリックします。

  3. ダイアログ・ボックスにユーザ名またはワイルドカードを入力して [了解] を選択します。

  4. 代替パスワードを必要とするユーザの名前を選択します。

  5. プルダウン・メニューから,対象のメール・サービス・タイプを選択します。 ユーザに対して POP メール用の代替パスワードを使用するよう要求するには, [POP with Mail Password] を選択します。 ユーザのメール・サービスを APOP に切り替えるには,[APOP with Mail Password] を選択します。

  6. [了解] を選択して,変更内容を保存します。

  7. POP または APOP の代替パスワードを入力して,[了解] を選択します。

    ユーザは,オプションを指定せずに mailauth コマンドを実行することにより,後でパスワードを変更することができます。 次に例を示します。

    % /usr/bin/mailauth
    

  8. [了解] を選択して,アカウントが正常に変更されたというメッセージを消去します。

  9. [終了] を選択して,「メール・ユーザ管理」ウィンドウを閉じます。

複数のアカウントについて認証を変更する必要がある場合は,手順 2 で [すべてのローカル・ユーザのリスト] を選択します。 [Ctrl] キーを押しながらマウスの右ボタンをクリックすると,リストから複数のユーザ名を選択することができます。 メール・ユーザ管理 ユーティリティの詳細については, mailusradm(8) を参照してください。

オプションで,mailauth を使用して認証をセットアップすることもできます。 詳細については, mailauth(8) を参照してください。

7.4.5    管理ツール

POP サービスの管理には,次のツールを使用することができます。

POP サーバは,ログ・メッセージを syslogd デーモンに送信します。 ログ情報は,/var/adm/syslog.dated/date/mail.log ファイルに格納されます。 このデータは,問題解決に使用することができます。 重大度は,認証の成功と失敗については NOTICE で,デバッグ情報についてはすべて DEBUG で示されます。

7.4.6    ディレクトリ構造

POP 構成およびメール・ファイルは,図 7-5 に示すように,ファイル・システムの中に分散されています。

図 7-5:  POP ディレクトリの構造

表 7-1 に,これらのファイルおよびディレクトリの目的を説明します。

表 7-1:  POP3 ファイルおよびディレクトリ

ファイルまたはディレクトリ 目的

/etc/passwd file

システムの各ユーザについてのアカウント情報が入っている。 このファイルの中に構成されたユーザは,省略時の設定で,POP メールを使用することができる。

/etc/pop.auth.* files

POP および IMAP ユーザの認証に使用される,暗号化されたメール認証データベースが入っている。 このデータベースの編集の詳細については, mailusradm(8) および mailauth(8) を参照。

/var/spool/mail directory

システム上の すべての POP および UNIX メール・ユーザのためのメール・フォルダが入っている。 各フォルダは,通常,ユーザのログイン名と同じ名前のファイルである。

7.5    IMAP (Internet Message Access Protocol)

IMAP4 (Internet Message Access Protocol Version 4) または IMAP は,メール・クライアントがサーバ上のメール・メッセージにアクセスするためのクライアント/サーバ・プロトコルです。 これにより,ユーザはサーバにログインすることなく,リモートにメール・フォルダにアクセスしたり,その内容を操作したりすることができます。 このプロトコルを使用すると,クライアントはメール・フォルダの作成,削除および名前の変更,新しいメッセージのチェックと古いメッセージの削除ができ,また選択したメッセージだけ検索してそれをローカルで表示することができます。 さらに,メッセージを属性によって選択したり,RFC 822 や MIME 形式のメッセージを解析したりすることもできます。

このプロトコルは,オフライン,オンライン,または切断モードのいずれかで使用できます。 オフライン・モードは,7.4 節 の説明と同じです。 オンライン・モードでは,メッセージがサーバ上でメール・クライアント・プログラムによってリモートに操作されます。 切断モードでは,メール・クライアントがメール・サーバに接続し,選択したメッセージのキャッシュ・コピーを作成してからサーバから切断し,後でサーバに再接続して再同期化します。 オンライン・モードと切断アクセス・モードでは,いずれもメールがサーバ上に格納されますが,これは,そのときどきで異なるコンピュータを使用するユーザが自分のメッセージにアクセスする際にしばしば必要とされる機能です。

詳細については, imapd(8)deliver(8),および imapd.conf(4) を参照してください。

7.5.1    IMAP のインストール

このオペレーティング・システムには,カーネギー・メロン大学による Cyrus IMAP4 Revision 1 サーバ (/usr/sbin/imapd) が含まれており,OSFINET サブセットのインストール時にインストールして構成されます (警告やエラーについては,インストレーション・ログ・ファイルを確認してください)。  imapd デーモンは,ポート 143 で着信接続を待つよう構成されています。

インストール時には,/etc/passwd/etc/services,および/etc/inetd.conf 構成ファイルが更新されます。 次の例に示される行が構成ファイルに存在しない場合,IMAP サービスが適切に動作しない可能性があります。

/etc/passwd ファイルには,次の行が必要です。 存在しない場合は,ファイルに追加します。

imap:*:14:6:IMAP Mail Service Account:/:
 

必要に応じて,14 というユーザ ID 番号をシステムに適した値に変更します。

/etc/services ファイルには,次の行が必要です。 存在しない場合は,ファイルに追加します。

imap    143/tcp

/etc/inetd.conf ファイルには,次の行が必要です。 存在しない場合は,ファイルに追加します。

imap    stream  tcp    nowait   imap    /usr/sbin/imapd     imapd
 

7.5.2    IMAP のアップグレード

Cyrus IMAP4 Revision 1 サーバのバージョン 1.6.1 から,quota および user 構成ディレクトリ内の IMAP ファイル群は,各ユーザ名の最初の 1 文字によって分類されて,az のサブディレクトリに格納されるようになりました。 IMAP メール・スプール内のユーザ・メール・ディレクトリも,オプションで同様に処理されます。 このように配置すると,各ディレクトリ内のエントリ数が少なくなるため,性能とスケーラビリティが向上します。

旧バージョンのオペレーティング・システムの IMAP サーバを実行しており,Tru64 UNIX をバージョン 5.1x にアップグレードする場合には,quota および user 構成ディレクトリを新しいフォーマットに変換しなければなりません。 これらの構成ディレクトリを変換する前に,/etc/imapd.conf ファイル内で hashimapspool オプションを使用可能にすると,IMAP メール・スプールも同様に分類できます。 詳細については, imapd.conf(4) を参照してください。

構成ディレクトリを新しいフォーマットに変換するには,dohash ユーティリティを使用します。 詳細については, dohash(8) を参照してください。

7.5.3    IMAP メール・アカウントの構成

ユーザが IMAP メールを受信できるようにするには,次の 2 つのタスクを行う必要があります。 まず,ユーザがシステム上にアカウントを持たない場合,それを作成します。 詳細については,『システム管理ガイド』および adduser(8) を参照してください。

次に,それらのユーザのメールが IMAP サーバによって処理されるよう,ユーザ・アカウントのプロパティを変更します。 CDE (Common Desktop Environment) のアプリケーション・マネージャの SysMan Menu アプリケーションを使用して,ユーザのメール・サービス・タイプを構成します。 SysMan Menu アプリケーションを起動するには,1.2.1 項 の説明に従ってください。

ユーザのメール・サービス・タイプを変更するには,次の手順を実行してください。

  1. SysMan Menu で,[メール] --> [メール・アカウントの管理] を選択します。 「メール・ユーザ管理」ウィンドウが表示されます。 また,次のコマンドを実行してこのユーティリティを起動することも可能です。

    # sysman mailusradm &
    

  2. 「特定のユーザのリスト」のラジオ・ボタンを選択し,[コンパイル・リスト] をクリックします。

  3. ダイアログ・ボックスにユーザ名またはワイルドカードを入力して [了解] を選択します。

  4. メール・サービス・タイプを変更するユーザの名前をリストから選択します。

  5. プルダウン・メニューから,対象のメール・サービス・タイプを選択します。 ユーザに対して IMAP メール用の代替パスワードを使用するよう要求するには,[IMAP with Mail Password] を選択します。 そうでない場合は,[IMAP] を選択して同じパスワードを使用します。

    このオプションを有効にすると,代替パスワードが,/etc/pop.auth.dir および /etc/pop.auth.pag ファイルにある mailauth データベースに格納されます。 詳細については, mailauth(8) を参照してください。

  6. [了解] を選択して,変更内容を保存します。

  7. メール管理者のパスワードを入力します。 ほとんどの場合,このパスワードはルート・アカウントのパスワードと同じです。 [了解] を選択します。

  8. ユーザのメールボックスに設定する特権を選択します。 ほとんどの場合,「All」を選択して,ユーザがメールボックスのメッセージの表示,変更,および削除を行えるようにします。 [了解] を選択します。

    手順 5 で [IMAP with Mail Password] を選択しなかった場合は,手順 10 に進みます。

  9. IMAP の代替パスワードを入力して,[了解] を選択します。

    ユーザは,オプションを指定せずに mailauth コマンドを実行することにより,後でパスワードを変更することができます。 次に例を示します。

    % /usr/bin/mailauth
    

  10. [了解] を選択して,アカウントが正常に変更されたというメッセージを消去します。

  11. [終了] を選択して,「メール・ユーザ管理」ウィンドウを閉じます。

複数の IMAP アカウントをセットアップする必要がある場合は,手順 2 で [すべてのローカル・ユーザのリスト] を選択します。 [Ctrl] キーを押しながらマウスの右ボタンをクリックすると,リストから複数のユーザ名を選択することができます。

詳細については,オンライン・ヘルプおよび mailusradm(8) を参照してください。

いったんユーザの IMAP アカウントがサーバ側にセットアップされると,ユーザはたとえば Netscape Communicator のような,オペレーティング・システム・ソフトウェアにバンドルされた IMAP4 互換のメール・アプリケーションを構成できるようになります。 ユーザには,ファシリティのメール・サービスについて,最低限,次の情報を提供する必要があります。

7.5.4    UNIX および POP3 メールからのユーザの移行

既存の UNIX または POP3 メール・ユーザを IMAP メールに変換するには,まず,7.5.3 項に説明するように,ユーザの IMAP アカウントをセットアップする必要があります。 さらに,次のように mailcv ツールを使用して,ユーザのメール・フォルダを IMAP に変換します。

注意

MH POP3 またはこのオペレーティング・システムに付属していないバージョンの Qualcomm POP3 を使用している場合は,7.4.2 項の説明に従ってそれらを新しい POP3 の実装に移行してから,IMAP に変換します。

  1. ディレクトリを UNIX/POP3 メール・フォルダ・ディレクトリに変更します。

    # cd /usr/spool/mail
    

  2. 次のように su コマンドを使用して,そのユーザになります。

    # su username
    

    mailcv コマンドを使用してユーザのメール・フォルダを IMAP 形式に変換するには,そのユーザになる必要があります。

  3. 次のコマンドを入力します。 ここで,folder は,ユーザのメール・フォルダのファイル名です。

    % /usr/dt/bin/mailcv -I -f folder
    

    このコマンドを使用するには,ユーザの IMAP パスワードが必要です。

    メール・フォルダのファイル名は,通常,ユーザのユーザ名と同じです。 たとえば,ユーザ名が Jake の場合,jake というファイルを変換します。

    オプションで,変換プロセスの際に,次の例のようにサブフォルダ名をコマンドの後に付けて,変換したメッセージを IMAP サブフォルダに移動することができます。

    # /usr/dt/bin/mailcv -I -f charlie business
    

    IMAP サブフォルダについては,7.5.7 項 に説明があります。 mailcv コマンドの詳細については, mailcv(1) を参照してください。

  4. 次のように入力して,ユーザのアカウントへの su セッションを終了します。

    % exit
    # 
    

アカウントを IMAP に変更した後,変換プロセスの前に届いたメールは失われません。 新たに変換されたメッセージは,ユーザのメールボックスにある既存のメッセージに追加されます。

ユーザの UNIX または POP アカウントがサーバ上の IMAP アカウントに変換されたら,ユーザはメール・アプリケーションを再度構成する必要があります。 ユーザが,たとえばこのオペレーティング・システムに付属の Netscape Communicator のような,IMAP4 と互換性のあるメール・アプリケーションを持っていることを確認します。

また,ファシリティのメール・サービスについて,7.5.3 項 に示す情報をユーザに提供する必要があります。

7.5.5    管理ツール

IMAP サーバの管理には,次のツールを使用することができます。

IMAP サーバ・ソフトウェアは,syslogd デーモンにログ・メッセージを送信します。 ログ情報は,/var/adm/syslog.dated/date/mail.log ファイルに格納されます。 このデータは問題解決に使用することができます。 重大度のレベルは次のとおりです。

NOTICE

認証の成功および失敗。

ERR

クォータの使用状況についての障害を含む I/O エラー。 メッセージには,特定のファイルおよび UNIX エラーが含まれます。

WARNING

保護メカニズム障害,クライアント・インアクティビティ・タイムアウト。

INFO

メールボックスのオープン。

7.5.6    ディレクトリ構造

IMAP 構造およびメール・ファイルは,図 7-6 に示すように,ファイル・システム中に分散されています。

図 7-6:  IMAP ディレクトリの構造

実行時の構成情報は,すべて /etc/imapd.conf ファイルに格納されます。 このファイルには,次のサイト構成およびポリシのオプションが入っています。

詳細については, imapd.conf(4) を参照してください。

/etc/imapd.conf ファイルの中で指定された構成ディレクトリには,表 7-2に示す項目が入っています。

表 7-2:  構成ディレクトリの内容

ファイルまたはディレクトリ 目的

mailboxes ファイル

サーバ上の IMAP メールボックスのソートされたリストに加え,メールボックスのクォータ・ルートおよびアクセス制御リスト (ACL) が入っている。 クォータ・ルートと ACL については,それぞれ 7.5.9 項7.5.8 項で説明する。 ACL は,他の場所に格納された情報から再構築できない,セキュリティの重要度が非常に高い情報なので,mailboxes が破壊された場合はこれを回復するユーティリティはない。 メールボックスの内容を保護するためには,mailboxes ファイルをディスクの他の部分に頻繁に (1 時間おきにも) バックアップする必要がある。

user/a...z ディレクトリ

ユーザの加入情報が入っている。 ユーザごとに対応するファイルが 1 つ存在しており,各ファイルにはユーザのメールボックスの分類済みリストが格納されている。

各ファイルは,対応するユーザの名前に拡張子 .sub を付けた名前を持つ。 これらのファイルは,ユーザ名の先頭 1 文字を使用して,サブディレクトリ az のいずれかに分類される。

加入ファイルが破壊された場合,これを回復するユーティリティは存在しない。 バックアップから失われたファイルをリストアすることは可能である。

proc ディレクトリ

アクティブなサーバ・プロセスごとにファイルが 1 つずつ用意される。 ファイル名はプロセス ID の ASCII 表示で,ファイルにはタブで区切られた次のフィールドがある。

  • クライアントのホスト名

  • ログインしている場合はユーザ名

  • メールボックスが選択されている場合は,選択されたメールボックス

proc サブディレクトリは,通常,サーバを再起動したときにパージされる。

quota/a...z ディレクトリ

制限付き IMAP ユーザのクォータ指定が格納されている。 1 人のユーザ用に複数のファイルが存在する場合もある。 各ファイルは,クォータ・ルートの限界値を示している (7.5.9 項 を参照)。

各ファイルは,文字列 user に 1 つ以上の拡張子 (先頭の拡張子は,対応するユーザの名前) を付けた名前となる (たとえば,user.hansen)。 これらのファイルは,ユーザ名の先頭 1 文字を使用して,サブディレクトリ az のいずれかに分類される。

imapquota プログラムは,-f スイッチを付けて起動すると,各ユーザのクォータを再計算する。 ユーザのクォータに対する制約を削除するには,ユーザのクォータ・ファイルを削除する。 次に,imapquota -f を実行して,クォータ・ファイル間の一貫性を再度図る。

log ディレクトリ

0 以上の,ユーザ名と同じ名前のサブディレクトリが入っている。 ユーザ用にサブディレクトリが存在する場合は,サーバがそのユーザだと認証しているプロトコル・セッションの遠隔測定ログを記録する。 遠隔測定ログはサーバのプロセス ID にと同じファイル名のサブディレクトリに格納される。 この機能は,ログ・ファイルがすぐに大きくなるので,デバッグのためにのみ使用する。

IMAP サーバ上の最大のデータベースは,ユーザのメールボックス・ディレクトリです。 省略時の設定では,メールボックス・ディレクトリ群は /var/spool/imap/users ディレクトリ内に位置しています。 ユーザごとにディレクトリが 1 つ存在し,ディレクトリの名前はユーザのユーザ名と同じです。 メールボックス・ディレクトリが多すぎる場合には,メールボックス・ディレクトリを /var/spool/imap/users/a...z サブディレクトリに分類することもできます。 この分類を行うには,imapd.conf ファイル内で hashimapspool オプションを指定します。 詳細については, imapd.conf(4) および dohash(8) を参照してください。

各ユーザのディレクトリには,表 7-3 に示すファイルがあります。

表 7-3:  メールボックス・ディレクトリの内容

ファイルまたはディレクトリ 目的

メッセージ・ファイル

RFC 822 形式のメッセージが 1 つずつ入っている。 メッセージの各行は,ライン・フィードだけでなく,キャリッジ・リターンとライン・フィードで区切られる。 各メッセージのファイル名は,メッセージの UID 後にドット (.) が付いたものである。

cyrus.header

メールボックス自体についてのマジック番号と可変長情報が入っている。

cyrus.index

メールボックス自体およびメールボックスにある各メッセージについての固定長情報が入っている。

cyrus.cache

メールボックスにある各メッセージについての可変長情報が入っている。

cyrus.seen

メールボックスの読み取り許可が与えられている各ユーザの状態についての可変長情報が入っている。

reconstruct ユーティリティは,メールボックス・ディレクトリの破壊された部分を回復するために使用することができます。 reconstruct ユーティリティは,既存のヘッダおよびインデックス・ファイルを見つけると,メッセージ・ファイル自体から導き出せないデータ,たとえばフラグ名,フラグ状態,および内部日付のようなデータをすべてそれらの中に保存しようとします。 このユーティリティは,他の情報をすべてメッセージ・ファイルから導き出します。

損傷を受けたディスクは,メッセージ・ファイルをバックアップからリストアし,reconstruct ユーティリティを実行して他のファイルから再度生成することにより回復が可能です。 reconstruct プログラムは,クォータ・ファイルに記録されたクォータ使用量の調整は行いません。 したがって,reconstruct を実行した後,imapquota -f を実行して,クォータ・ルート・ファイルを修正してください。

7.5.7    メールボックスのネームスペース

IMAP サーバは,netnews ネームスペース規則を使用してメールボックスを表現します。 メールボックス名には,次の制約があります。

ユーザ用の個人メールボックスはすべて,user.username. という文字列で始まります。 たとえば,Hansen という名前のユーザのメールボックスは,user.hansen. という文字列で始まります。 Hansen が仕事関係の電子メール用にメールボックスを用意する場合,たとえば user.hansen.work という名前を付けることができます。

ユーザのメール・アプリケーションでは,通常,user.hansen. という接頭辞が INBOX. と表示されます。 したがって,メールボックス user.hansen.work は,INBOX.work と表示されます。 しかしながら,メールボックスのアクセス制御リスト (ACL) で,他のユーザがそのメールボックスを見ることが許可されている場合は,それらのユーザに対しては user.hansen.work と表示されます。

ユーザのメールボックスの作成または削除は,ユーザの INBOX を作成または削除することにより行います。 INBOX を持つユーザは,個人メールボックスを作成して,それに加入することができます。 ユーザ名にドットが入っているユーザはログインはできますが,INBOX を持ったり,IMAP メールを受信したりすることはできません。 ユーザの INBOX を削除すると,それに関連付けられた個人メールボックスもすべて削除されます。

INBOX を除いて,メールボックス名はすべてシステム・ワイドで,ユーザに関係なく同じメールボックスを参照します。 ACL は,メールボックスにどのユーザがアクセスしたり,それを表示したりできるかを定義します。

相対メールボックス名を使用できる状況では,メールボックスのネームスペースは次の規則に従います。

トラブルシューティングのために telnet を使用して IMAP ポートに接続している場合,または IMAP 呼び出しを実行するアプリケーションを作成する場合,この規則を使用しなければならないことがあります。

フォルダ名を扱っている場合,階層の最上位が user.hansen であれば,.work.personnel.issues という名前は user.hansen.work.personnel.issues に,work.personnel.issues という名前は work.personnel.issues に解決されます。

7.5.8    アクセス制御リスト

メールボックスへのアクセスは,それぞれのメールボックスが持つアクセス制御リスト (ACL) によって制御されます。 ACL は,メールボックスへのアクセス許可を持つユーザまたはユーザ・グループを指定するためのメカニズムを提供します。

ACL は,エントリが 0 以上のリストです。 それぞれのエントリは識別子とアクセス権のセットからなります。 識別子は,そのエントリが適用されるユーザまたはユーザ・グループを指定します。 アクセス権のセットは,1 つ以上の文字または数字からなり,それぞれの文字や数字が,特定の特権を付与することを表します。 詳細については, cyradm(1) を参照してください。

アクセス権は,次のように定義されています。

lookup (l)

ユーザは,メールボックスが存在していることを確認できます。

read (r)

ユーザは,メールボックスの読み取りが可能です。 すなわち,メールボックスの選択,データの取得,検索の実行,およびメールボックスからのメッセージのコピーを行うことができます。

seen (s)

ユーザ別の seen 状態が保存されています。 サーバは,ユーザの Seen および Recent フラグを保存します。

write (w)

ユーザは,Seen および Deleted (他のアクセス権で制御されます) 以外のフラグやキーワードを変更することができます。

insert (i)

ユーザは,新規メッセージをメールボックスに挿入することができます。

post (p)

ユーザは,メールをメールボックスのサブミッション・アドレスに送信することができます。 この権利は i 権とは異なり,配信システムによって送信メッセージの中に追跡情報が挿入されます。

create (c)

ユーザは,新規のサブメールボックスを作成することができます。

delete (d)

ユーザは,Deleted フラグの格納,抹消の実行,および削除を行うことができます。

administer (a)

ユーザは,メールボックスの ACL を変更することができます。

アクセス権はさまざまな方法で組み合わせることができます。

lrs

ユーザはメールボックスを読み取ることができます。

lrsp

ユーザはメールを読み取り,それを配信システムを通じてポストすることができます。 ほとんどの配信システムは認証機能を備えていないので,post 権は,通常,anonymous ユーザに対してのみ意味を持ちます。

lr

ユーザは,メールボックスを確認して読み取ることはできますが,サーバは Seen および Recent フラグを保存しません。 このアクセス権のセットは,主に anonymous IMAP の場合に便利です。

rs

ユーザはメールボックスを読み取ることができ,サーバは Seen および Recent フラグを保存しますが,ユーザは多様なメールボックスのリスト・コマンドを通じてメールボックスを表示することができません。 メールボックスにアクセスするためには,その名前を知る必要があります。

lrsip

ユーザは,メールボックスを読み取ることができ,また IMAP と配信システムのいずれを通じてでもメールボックスに追加することが可能です。

識別子の前に,ダッシュ文字が付くことがあります。 この場合,関連するアクセス権が識別子から削除されます。 これらは負の権利 (negative rights) と呼ばれます。

ユーザに付与されたアクセス権のセットを計算するために,サーバはまず,そのユーザとユーザが属しているグループに付与された全部の権利の合計を計算します。 次に,サーバは,そのユーザとユーザが属しているグループに付与された全部の負の権利の合計を計算して,それらを削除します。 たとえば,次の ACL では,Fred という名前のユーザが lrswip の権利を付与され,ユーザ anonymous が lrp の権利を付与されます。 :

anyone        lrsp
fred          lwi
-anonymous    s

メールボックスの ACL に関係なく,/etc/imapd.conf ファイルの admins 構成オプションにリストされているユーザは,すべてのメールボックスに対して暗黙的に lookup 権および administer 権を持ちます。 またユーザは,INBOX および自分の個人メールボックス全部について,暗黙的に lookup 権および administer 権を持ちます。

メールボックスが作成されたとき,その ACL にはそれに最も近い親メールボックスの ACL がコピーされます。 ユーザが作成されたときには,ユーザの INBOX の ACL には,ユーザに全部の権利を付与するエントリが 1 つだけ用意されます。 ユーザのないメールボックスが作成され,親が存在しない場合,その ACL は /etc/imapd.conf ファイルの defaultacl オプションの値に初期化されます。

7.5.9    クォータ

クォータは,ユーザにとって利用可能なシステム・リソースの上限を定めるために使用します。 IMAP サーバは,ストレージについてクォータをサポートします。

ストレージについてのクォータは,ユーザのメッセージが消費できるディスク容量の K バイト数で定義されます。 サーバがメッセージ・ファイルにハード・リンクを形成することによりディスク容量を節約している場合でも,それぞれのメッセージは別々にカウントされます。 メールボックスのインデックス・ファイルとキャッシュ・ファイルが使用するディスク容量オーバヘッドは,クォータの計算には含まれません。

ユーザのメールボックス全体に対して 1 つのクォータを割り当てることも,ユーザのメールボックスの階層の枝ごとに別個のクォータを割り当てることも可能です。 いずれの場合も,クォータは制限を課すメールボックスの階層のルートに対して適用します。 クォータ・ルートは,その階層にあるメールボックスをいくつでも含むことができます。 クォータ・ルートのクォータは,そのレベルとそれよりも下位にあり,下位レベルのクォータ・ルートに含まれないレベルにあるすべてのメールボックスが使用する容量の合計に対して適用されるので,すべてのメールボックスは,1 つのクォータ・ルートによってのみ制限されることになります。

図 7-7 は,Hansen という名前のユーザのクォータ・ルートの例を示します。

図 7-7:  クォータ・ルート

図 7-7 では,ユーザである Hansen は次のメール・フォルダを持ちます。

user.hansen (INBOX)
user.hansen.personnel
user.hansen.personnel.reviews
user.hansen.personnel.issues
user.hansen.saved
user.hansen.todo

quota/h ディレクトリにある次のクォータ・ルートによって,Hansen のディスク使用量が制限されます。

user.hansen
user.hansen.personnel
user.hansen.personnel.issues

クォータ・ルート user.hansen は,INBOXsaved,および todo の 3 つのメール・フォルダに適用されます。 クォータ・ルート user.hansen.personnel は,personnel および reviews の 2 つのメール・フォルダに適用されます。 クォータ・ルート user.hansen.personnel.issues は,issues メール・フォルダにのみ適用されます。 ここで,user.hansen.personnel および user.hansen.personnel.issues クォータ・ルートが存在しないと仮定すると,user.hansen ルートに対して指定された制約は,user.hansen の階層にあるすべてのメール・フォルダ (user.hansen 接頭辞を持つすべてのメール・フォルダ) に適用されます。

クォータ・ルートは,cyradm ユーティリティで setquota コマンドを使用して作成しますが,このユーティリティでクォータ・ルートを削除することはできません。 クォータ・ルートを削除するには,それに関するクォータ・ファイルを削除する必要があります。

メッセージをメールボックスに挿入するには,メッセージを挿入することによりクォータ・ルートを超過することのないよう,メールボックスが十分な容量を持つ必要があります。 これはフォルダ間の手動転送については常に正しいのですが,メール配信は特殊な例外です。 配信が開始された時点で上限を超えていなければ,メッセージはそのサイズにかかわらず配信されます。 新規メッセージを配信することによってフォルダのクォータが超過した場合,imapd デーモンがそれをユーザに通知し,ユーザはその問題を解決することができます。 このように動作するのは,この場合にメール配信が許可されなければ,メールが配信できないことがユーザにはわからないからです。

クォータ・ルートが超過すると,メール配信は一時的エラーとともに失敗します。 システムは数日間配信を試み,ユーザがそれに気付いて修正を行うのを待ちます。

クォータに近い,またはそれを超過しているメール・フォルダをユーザが選択すると,サーバは警告を発してそれをユーザに通知します。 どの程度の使用量でサーバがクォータの警告を発するかのしきい値は,quotawarn 構成オプションを使用して設定します。 サーバはユーザがフォルダに対してアクセス権を持つ場合にのみ警告を発します。 アクセス権を持ったユーザでなければ問題を解決できないからです。

7.5.10    パーティション

パーティションを使用して,メールボックスをファイル・システムの別の場所に格納することができます。 メールボックスの階層は,複数のディスクに分散することが可能です。 これらの代替パーティションを指定するには,cyradm ユーティリティを使用します。 IMAP メール・アプリケーションからはそれらを指定することはできません。

メールボックスを新たに作成したときには,そのメールボックスのパーティション名を cyradm ユーティリティの createmailbox コマンドの引数として指定します。 パーティションを指定しなければ,メールボックスはその親メールボックスのパーティションを継承します。 メールボックスに親が存在しない場合は,defaultpartition 構成オプションで指定されたパーティションが省略時のパーティションになります。

また,cyradm ユーティリティの renamemailbox を使用して,既存のメールボックスのパーティションを変更することもできます。 詳細については, cyradm(8) を参照してください。

クォータ・ルートはパーティションから独立であることに注意してください。 1 つのクォータ・ルートを複数のパーティションに散在するメールボックスの階層に適用することが可能です。

7.6    メールの管理

この節では,次に挙げるメール関連の各タスクの実施方法を説明します。

7.6.1    メール・キューの監視

メール・キューを監視することによって, リモート・システムへ転送するためにローカル・システムにキュー登録されているジョブなど, ネットワーキング・オペレーションのいくつかのタイプについて,状態を調べることができます。 一般ユーザおよびシステム管理者は,メール・キューを監視できます。

メール・キューの内容を表示するには,mailq コマンドを使用します。 このコマンドでは,要求の個数,キューID,メッセージ・サイズ,メッセージがキューに入った日付, および各要求の送信者と受信者がリストされます。 代わりに,sendmail -bp コマンドを使用できます。

詳細については, mailq(1)を参照してください。

メインのホストがある期間オフラインになると,キューのエントリ数が非常に大きくなって, メール環境の質が低下します。 これを回復するには,キューを保管する必要があります。 これについては, 7.6.2 項 を参照してください。

次の例は,メール・キューにある 2 つの要求を示します。

# mailq
                Mail Queue (2 requests)
--QID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
AA04956     1442 Tue Aug 24 10:12 <blaise>
                 (Deferred)
                                 <corcoran@host1.corp.com>
AA08618* (no control file)

7.6.2    メール・キューの保管

長期間,メインのホストがオフラインになると,メール・キューが非常に大きくなります。 その結果,sendmail ユーティリティは,大きなキューをソートすることに長時間かかり,メール環境の質にかなり影響を与えます。 メインのホストがオフラインの間,メール・キューを保管しておくと,メール環境は正常に機能できます。 メール・キューを保管するには,次の手順に従ってください。

  1. ルートとしてログインします。

  2. cd コマンドを使用して,/var/spool ディレクトリに変更します。

  3. 次のコマンドを入力して sendmail ユーティリティを停止します。

    # /sbin/init.d/sendmail stop
    

  4. 次のコマンドを入力して sendmail ユーティリティが実行していないことを確かめます。

    # ps -e | grep sendmail
    

  5. 次のコマンドを入力して sendmail 子プロセスが実行していないことを確かめます。

    # ps -e | grep queue
    

    リスト内のプロセスが,たとえばメッセージ・キュー ID が含まれているというように sendmail に関係している場合は,キューを移動する前にプロセスが終了するまで待ちます。 そうしないとキューを壊してしまう場合もあります。

  6. mv コマンドを使用して, mqueue ディレクトリを old.mqueue ディレクトリに移動します。

  7. mkdir コマンドを使用して,新しい mqueue ディレクトリを作成します。

  8. chmod コマンドを使用して,ディレクトリの許可コードを 775 に変更します。

  9. 次のコマンドを使用して,sendmail ユーティリティを再起動させます。

    # /sbin/init.d/sendmail restart
    

メインのホストがオンラインになった後に,次のコマンドを使用して, 古いメール・キューを処理します。

# /usr/sbin/sendmail -oQ/var/spool/old.mqueue -q

キューが空の場合は,次のコマンドを使用してキューを削除します。

# rm -r /var/spool/old.mqueue

7.6.3    別名情報の管理および配布

スタンドアロンまたはサーバ・システムの別名情報の管理および配布の方法によって決まりますが,メール環境で使用するために別名情報を提供する方法は 3 つあります。

省略時の設定では,/var/adm/sendmail/aliases ファイルの許可コードは 644 です。 これは,グローバル・ユーザが,ファイルの変更およびファイルへの変更内容の書き込みができないことを意味します。 これによって,十分に安全なシステムが形成される一方, グローバル・ユーザ・リストのメンテナンスは,システム管理者に委ねられます。

次の手順に従って,メンテナンスの責任を分散できます。

  1. ディレクトリにグローバル・メンテナンス担当者のためのローカル別名ファイルを作成します。 このファイルおよびディレクトリの両方は,別のメンテナンス担当者によってアクセスできなければなりません。

  2. 追加の別名ファイルを含むエントリを /var/adm/sendmail/aliases ファイルに作成します。 エントリの形式は,次のとおりです。

    alias_name: :include:filename

    filenameは,別名ファイルの完全パス名およびファイル名です。

  3. newaliases コマンドを使用して,新しいバージョンの別名ファイルを構築します。

詳細については, aliases(4)を参照してください。

メール環境で使用する別名情報を管理し,配布するためにオプションとして NIS を使用することができます。 NIS 別名データベースを使用するには,次の手順に従ってください。

  1. NISをまだインストールして構成していない場合は, nissetup スクリプトを使用して行います。

  2. svcsetup スクリプトを使用して svc.conf ファイルを編集し,別名エントリを変更して yp (NIS)を含めます。

  3. NIS 別名マップを編集して,必要な別名情報を含めます。

NISの構成についての説明は第 3 章を,NISマップの更新についての説明は3.4.5 項を参照してください。

最後に,メール環境で使用する別名情報を管理,配布する手段として,LDAP を使用することもできます。 LDAP による別名情報の管理は,別名データベースが非常に大きな場合や,ネットワーク上のいくつものシステムが同じ情報を共有する場合に最適です。

LDAP を使用して別名情報を管理するには,次の手順を実行します。

  1. LDAP サーバを構成し,環境に応じたスキーマを作成します。 LDAP サービスはメール・サーバ上に構成することもできますが,可能であれば独立したシステム上に構成してください。 詳細については, sendmail.m4(8) と LDAP サーバのドキュメントを参照してください。

  2. スキーマに 2 つの属性を作成します。 1 つはユーザのメール・アドレス用,もう 1 つはユーザの別名用です。

  3. /var/adm/sendmail ディレクトリ内の hostname.m4 ファイルを手作業で編集し,次の変更を加えます。

    1. _LDAPMap{T} を設定し,ルックアップを使用可能にします。

    2. _LDAPParam を設定し,マップとその引数リストを定義します。 詳細については, sendmail.m4(8) を参照してください。

  4. /var/adm/sendmail ディレクトリに移動し,次のコマンドを実行します。

    # make -f Makefile.cf.hostname
    

  5. 次のコマンドを実行し,hostname.cf ファイルの名前を sendmail.cf に変更します。

    # mv hostname.cf sendmail.cf
    

  6. 次のコマンドを実行して sendmail デーモンを再起動します。

    # /sbin/init.d/sendmail restart
    

上記の 3 〜 6 の手順は,mailsetup ユーティリティや mailconfig ユーティリティを使用してメールを構成するたびに実行する必要があります。

7.6.4    メール統計情報の表示

次の mailstats コマンドを使用して, システムのメール通信量についての統計情報を表示できます。

# /usr/sbin/mailstats

次のコマンドを実行することによって,いつでも,統計情報ファイルを初期化できます。

# cp /dev/null /var/adm/sendmail/sendmail.st
# chmod 666 /dev/null /var/adm/sendmail/sendmail.st

7.7    メール・ユーティリティ

Tru64 UNIX には,次に挙げるメール・ユーティリティが含まれています。

sendmail についての詳細は, sendmail(8)sendmail.cf(4),および sendmail.m4(8) を参照してください。