Tru64 UNIX のメール・システムを使用すれば,同じシステムや同じネットワークのユーザばかりでなく, 異なるシステムやネットワークにいるユーザにもメールを送信できます。 この章では,以下の項目について説明しています。
メールについての詳細は,
mail_intro
(7)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 メール環境
スタンドアロン
メール・スタンドアロン・システムは,メールをローカルに処理/送信/配布するシステムです。 この形態は,1〜 6 のシステム構成の場合に便利です。 2 つあるいはそれ以上の小規模な LAN 構成では, 1 つのシステムが,NFS を使用している他のシステムへメール・ボックスを提供します。 この場合,すべてのシステムで NFS が構成されている必要があります。
クライアント
メール・クライアント・システムは, 処理および配布のためにすべてのメールをメール・サーバに送信するシステムです。 クライアント・システム上にメール・アドレスがある場合は,メールはそのシステムへ送られます。 それ以外の場合は,デスティネーション・システムへ転送されます。
メール・サーバ・システムは, ローカル・ドメインのクライアントからメールを受け取り, 他のドメイン,インターネット,あるいは他のネットワークへ配布するシステムです。 サーバは他のドメインからのメールの受け取りも行います。
図 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 を使用してメールの経路を決めると次のような利点があります。
MX レコードを定義して,ローカル・ドメイン内のメール・サーバのすべてを指名できます。 1 つのメール・サーバにアクセスできない場合は,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 クライアントへのメールの配布
メールがドメインへ送られると, 次のいずれかのメカニズムでクライアントへ配布されます。
各クライアントの省略時の
/var/spool/mail
ディレクトリへメールを送る。
サーバへメールを送り,NFS を使用して各クライアントのメール・ディレクトリにメールを送る。
サーバから,POP を使用しているローカル・クライアント・マシンへメールを送る。 (7.4 節 を参照)
IMAP を使用しているサーバへメールを送る。 (7.5 節 を参照)
各クライアントにメールを送るためには, ドメイン内の各サーバがクライアント上の各ユーザのエントリを含む別名ファイルを持っていることが必要です。 次に例を示します。
username1: username1@client1 username2: username2@client1
スタンドアロンおよびサーバ・システムに対しては,NIS を使用して 1 つのマシンからメール別名ファイルを分散させます。
スタンドアロン・システムの LAN 環境では,NFS サーバ・システムからメール別名ファイルを分散します。
クライアント/サーバ環境では,ドメインのサーバに別名(aliases
)ファイルを分散します。
システム間で別名(aliases
)ファイルを共有することにより,どちらの場合も,メール別名の変更は 1 つの別名ファイルに対してだけ行えはよいので管理が簡単になります。
データベースについての詳細は,
aliases
(4)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
各変数の意味は次のとおりです。
ユーザ名です。
DECnetのノード名です。
DECnet の擬似ドメインを指定する任意の文字列です。 擬似ドメインには自由な文字を使用することができますが,組織内で統一されていることが必要です。 すべてのメール・システムは同じ擬似ドメイン名を使用して構成しなければなりません。
通常,ユーザの会社のドメイン名です。
たとえば,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 必要なプロトコルがインストールされているかどうかの確認
メール・サーバでサポートしているプロトコルに依存して, 次に示す必要なサブセットがインストールされ構成されているかどうか確認します。
DECnet
DECnet/OSI
X.25 (PSInet)
UUCP
各製品のインストレーションおよび構成については, それぞれの製品のドキュメントを参照してください。 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-4
にメール・プロトコル・ワークシートを示します。
本書をオンラインで参照している場合は,このワークシートをプリント機能を使用してプリントすることができます。
この後の項では,ワークシート上に記録する必要のある情報につて説明します。
図 7-4: メール・プロトコル・ワークシート
システムをインターネット (SMTP) サーバとして構成するには,次の情報を収集する必要があります。
中継ホストに転送するメールのタイプです。 ローカルホストがインターネットに直接アクセスでき,メールをまったく転送しない場合は,「無し」をチェックします。 ローカルホストが,最上位ドメインの外部にアドレスを指定したメールをすべて転送する必要がある場合は,「インターネット」をチェックします。 ローカルホストが,ローカル・インターネット・ドメインの外部にアドレスを指定したメッセージをすべて転送する必要がある場合は,「ローカル以外」をチェックします。 ローカルホストが,ローカル・ドメイン・メールを含むメールをすべて転送する必要がある場合は,「ローカル」をチェックします。
SMTP メールを処理するリモート・ホストの名前です。
サーバが中継ホストへのメッセージ転送に使用するプロトコルの名前です。
SMTP メールの擬似ドメインを指定する任意の文字列です。 擬似ドメイン名はプロトコルごとに一意とし,組織内全体で一貫性を持たせなければなりません。
擬似ドメインを指定する別名です。
ホストにメールを送信するために,他のシステムが使用する可能性がある代替名。
システムを他のメール・プロトコル用のサーバとして構成するには,次の情報を収集する必要があります。
メール・ゲートウェイとして機能しているシステムについて,サポートしているメール・プロトコルのタイプです。 使用できるプロトコルには,次のものがあります。
DECnet (フェーズ IV)
DECnet/OSI (フェーズ V)
SMTP (Internet Mail Protocol) (必須)
IMAP (Internet Message Access Protocol)
MTS (Message Transport System)
POP (Post Office Protocol)
UUCP
X.25 (PSInet)
DECnet,DECnet/OSI,UUCP,MTS,および X.25 専用です。 特定のプロトコルのメールをネットワーク経由でゲートウェイに転送する場合は,「インターネット」をチェックします。 インターネットは DNS によって適切な中継を選択します。 したがって,インターネットに対する中継ホスト名は指定しないでください。
特定のプロトコルがサーバにインストールされている場合は,「直接」をチェックします。 特定のプロトコルを必要とするメールを他のシステムへ転送して処理する場合は,「中継」をチェックします。 この場合,「中継ホスト名」および「中継プロトコル」フィールドを埋める必要があります。
対象プロトコルのメールを処理回送するリモート・ホスト名です。
サーバが中継ホストにメッセージを転送するために使用するプロトコルの名前です。
マシンのアドレスです (DECnet 専用)。
このノードの,完全な DNS ネーム・スペース名です (DECnet/OSI 専用)。 DNS ネーム・スペースの構文は,次のとおりです。
namespace:.site.nodename
擬似ドメインを指定する任意の文字列です (DECnet,DECnet/OSI,および MTS 専用)。 擬似ドメイン名は各プロトコルでユニークで,企業全体で一貫して使用される必要があります。
擬似ドメインの任意の別名です (DECnet,DECnet/OSI,UUCP,および MTS 専用)。
ホストにメールを送信するために,他のシステムが使用する可能性のある別名です。
グラフィック機能を備えているシステムでメールを構成するには,CDE のアプリケーション・マネージャから起動できるメール設定アプリケーションを使用します。
注意
別の方法として,SysMan Menu (
/usr/sbin/sysman mailsetup
) またはmailsetup
ユーティリティを使用してシステムにメールを構成することもできます。 詳細については,オンライン・ヘルプおよびを参照してください。 mailsetup
(8)
次のシステムを構成できます。
スタンドアロン・システム
クライアント・システム
サーバ・システム
メール設定アプリケーションをスタートさせるには,次の手順に従ってください。
ルートとしてログインします。
CDE フロント・パネルのアプリケーション・マネージャ・アイコンをクリックします。
「システム管理」アプリケーション・グループ・アイコンをダブルクリックします。
「システム設定」アプリケーション・グループ・アイコンをダブルクリックします。
「メール」アプリケーション・アイコンをダブルクリックします。 「メールの設定」メイン・ウィンドウが表示され,使用可能なメール・サービスのタイプと,構成済みのメール・サービスのタイプが表示されます。
メール設定アプリケーションを終了するには,[ファイル] メニューから [終了]を選択します。
詳しくは,
mailconfig
(8)
メール設定アプリケーションには,オンラインヘルプが用意されています。
7.3.1 スタンドアロン・メール・システムの構成
スタンドアロン・システムのメールを構成するには,次の手順に従ってください。
「メールの設定」ウィンドウから, 「利用可能なメール・サービスの種類」リスト・ボックスから「Standalone」を選択します。
[設定...] を選択します。 「Standalone Setup」ダイアログ・ボックスが表示されます。
システム・メールボックス・ディレストリ (たとえば
/var/spool/mail
) をインポートまたはエクスポートするのに NFS を使用する場合は,
[メールボックスの設定] を選び「メールボックスの設定」ダイアログ・ボックスを表示します。
それ以外の場合は,手順 7 に進みます。
省略時の設定は,ユーザのメール構成に適用されます。
システムが,NFS を使用して自分のメールボックスをインポートする場合は, 「NFS クライアント」ラジオ・ボタンを選択し,次のことを行います。
「メールボックス・サーバ」フィールドにサーバ名を入力します。
「lockf」,「ロック・ファイル」,「両方」のロック・メカニズムのうちいずれか 1 つを選択します。
システムが NFS クライアントにメールボックスを配布する場合は,「NFS サーバ」ラジオ・ボタンを選択し,「両方」を選択します。
[了解] をクリックしてメールボックスの設定を完了し, 「メールボックスの設定」ダイアログ・ボックスをクローズします。
[コミット] をクリックして,変更を保存します。
sendmail
デーモンを再起動するかどうか質問がきます。
[再起動] をクリックして,sendmail
デーモンを再起動して変更を有効にします。
または,[いいえ] をクリックして次回システムをリブートする際に変更が有効になるようにします。
[再起動] を選択すると,sendmail
デーモンが開始されたことが知らされます。
[了解] をクリックするとそのメッセージは消えます。
[閉じる] をクリックして「Standalone Setup」ダイアログ・ボックスをクローズします。
メール・クライアントを構成するには,次の手順に従ってください。
「メールの設定」ウィンドウから, 「利用可能なメール・サービスの種類」リスト・ボックスの「Client」を選択します。
[設定...] ボタンをクリックします。 「Client Setup」ダイアログ・ボックスが表示されます。
「メールボックス・サーバ」入力テキスト・ボックスをクリックして, メール・サーバの名前を入力します。
[メールボックスの設定] をクリックします。 「メールボックスの設定」ダイアログ・ボックスが表示されます。
サイトがシステム・メールボックス・ディレクトリを共用するためにNFSを使用する場合は, 「メールボックス・ディレクトリ」の「NFS クライアント」ラジオ・ボタンを選択します。 それ以外の場合は,「ローカル」をクリックし,手順 7 に進みます。
メールボックス・ディレクトリをシステムへエクスポートするサーバの名前を「メールボックス・サーバ」フィールドに入力します。
ロッキング・メカニズムを有効にするために「loackf」,「ロック・ファイル」,または「両方」のいずれか 1 つのラジオ・ボタンをクリックします。
[了解] をクリックしてメールボックスの設定を終了し, 「メールボックスの設定」ダイアログ・ボックスをクローズします。
[コミット] をクリックして変更を保存します。
sendmail
デーモンを再起動するかどうかの質問がきます。
「設定」ダイアログ・ボックスの [再起動] をクリックして,
sendmail
デーモンを再起動し変更を有効にします。
または,[いいえ] を選択して次回システムをリブートする際に変更が有効になるようにします。
[再起動] を選択するとsendmail
デーモンが開始されたことが知らされます。
[了解] をクリックするとメッセージは消えます。
[閉じる] をクリックして「Client Setup」ダイアログ・ボックスをクローズします。
メール・サーバを構成するには,次の手順に従ってください。 POP または IMAP デーモンをインプリメントする場合は,SMTP とその他必要なプロトコルを最初に構成してから, 7.4 節および 7.5 節を参照してください。
「メールの設定」ウィンドウから, 「利用可能なメール・サービスの種類」リスト・ボックスの「Server」を選択します。
[設定...] ボタンをクリックします。 「Server Setup」ダイアログ・ボックスが表示されます。
「利用可能なプロトコル」リスト・ボックスから,このシステムで使用するために構成したいメール・プロトコルを選択します。 Internet Mail Protocol (SMTP) プロトコルは,唯一の必須プロトコル構成です。 必要に応じて,追加のプロトコルを構成します。
[設定...] ボタンをクリックします。 選択したプロトコルのプロトコル設定ダイアログ・ボックスが表示されます。
SMTP プロトコルの場合は,このサーバの転送のタイプを選択します。 [なし] をクリックした場合は,手順 11 に進みます。 [なし] をクリックしない場合は,手順 7 に進みます。
DECnet,DECnet/OSI,MTS,UUCP,およびX.25プロトコルの場合は,ルーティングを選択します。 [インターネット] または [直接] をクリックした場合は,手順 9 に進みます。 [中継] をクリックした場合は,手順 7 に進みます。
メールを別のシステムに転送して処理する場合は,「中継ホスト名」フィールドにホスト名を入力します。 それ以外の場合は,手順 9 に進みます。
[中継プロトコル] プルダウン・メニューで中継ホストとの通信に使用するプロトコルを選択します。
DECnet,DECnet/OSI,および MTS のプロトコルの場合は, 「擬似ドメイン」テキスト入力フィールドに, 選択したプロトコルを必要とするメールの識別に使用するドメイン名を入力します。
DECnet,DECnet/OSI,MTS,UUCP,および X.25 プロトコルの場合に,擬似ドメインの別名を追加するには, [擬似ドメインの別名] をクリックして「擬似ドメインの別名」を表示し,次の手順に従ってください。
「別名」フィールドに別名を入力し,[追加] をクリックします。
1 つ前の手順を必要な回数だけ繰り返します。
[了解] をクリックして,「擬似ドメインの別名」ダイアログ・ボックスをクローズします。
このメール・サーバの別名を追加するには,[ホスト別名] をクリックして「ホスト別名」を表示し,次の手順を行います。
「別名」フィールドに別名を入力して,[追加] をクリックします。
1 つ前の手順を必要な回数だけ繰り返します。
[了解] をクリックし,「ホスト別名」ダイアログ・ボックスをクローズします。
DECnet プロトコルの場合は,「Node Address」フィールドに DECnet ノード・アドレス(area.node) を入力します。
たとえば,32.958
です。
DECnet/OSIプロトコルの場合は,「DNS Name Space」フィールドにノードのネーム・スペースを入力します。 通常,DECnet Phase V アドレスのコロン (:) の前にあるトークンです。
[了解] をクリックし,選択したプロトコルの「設定」ダイアログ・ボックスをクローズします。 「Server Setup」ダイアログ・ボックスが有効になります。
必要な場合には,別のプロトコルを構成します。 各プロトコルに対して,手順 3 から 15 の操作を行います。
[メールボックスの設定] をクリックします。 「メールボックスの設定」ダイアログ・ボックスが表示されます。
[メールボックス・ディレクトリ] をクリックします。
サイトがシステム・メールボックス・ディレクトリを分散するために,NFSを使用しない場合は,[NFS クライアント] の代わりに [ローカル] をクリックして,手順 19 に進みます。
メールボックス・ディレクトリとして [NFS クライアント] を選択した場合は,
「メールボックス・サーバ」フィールドにメール・サーバ名を入力します。
必ずドメインを含めます。
たとえば,mailhub
という名前のサーバの場合は,
ドメインを含めたサーバ名が
mailhub.nyc.dec.com
になります。
「lockf」,「ロック・ファイル」,「両方」のロック・メカニズムのうちのいずれか 1 つをクリックします。
[了解] をクリックしてメールボックスの設定を完了し,「メールボックスの設定」ダイアログ・ボックスをクローズします。
「設定」ダイアログ・ボックスの [再起動] をクリックして,sendmail
デーモンを再起動し変更を有効にします。
[再起動] を選択して
sendmail
デーモンを開始し,変更をすぐに有効にします。
または [いいえ] を選択して,次回システムをリブートする際に変更が有効になるようにします。
[再起動] を選択すると,sendmail
デーモンが開始されたことが知らされます。
[了解] を選択してメッセージを消します。
[閉じる] をクリックして「Server Setup」ダイログ・ボックスをクローズします。
必要に応じて,システム環境の各ホストごとに DNS メール・エクスチェンジャ (MX) レコードを
/etc/namedb/hosts.db
ファイルに追加します。
詳細については,7.1.1 項
を参照してください。
既存のメール環境に新しいメール・ホストを追加するには,次のことを行います。
ネットワークおよびネットワーク・サービスをホスト上に構成します。 詳細については,『ネットワーク管理ガイド:接続編』を参照してください。
既存の環境で 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
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 に移行するには,次のタスクを実行します。
/sbin/rc
ディレクトリにある
/usr/lib/mh/popd
ファイル用のスタートアップ・スクリプトをすべて削除します。
/etc/inetd.conf
および
/etc/services
構成ファイルが
7.4.1 項
で説明されているとおりに,正しいエントリによって更新されていることを確認します。
次のコマンドを入力して,mailauth
データベースを初期化します。
#
/usr/bin/mailauth -init
popcv
ユーティリティを使用して,ユーザ名とパスワードを
/usr/spool/pop/POP
ファイルから
mailauth
データベース (/etc/pop.auth.pag
および
/etc/pop.auth.dir
) に移動します。
次のコマンドを入力します。
ここで,filename
は,POP パスワードの格納に使用するファイル名に変更します)。
#
/usr/bin/popcv [filename]
mailcv
ツールを使用して,既存の MH POP3 メール・フォルダを新しい POP3 形式に変換します。
ディレクトリを MH POP3 メール・フォルダ・ディレクトリに変更します。
# cd /usr/spool/mail/POP
MH POP3 の構成方法に応じて,ディレクトリは
/usr/spool/pop
または 他のディレクトリになります。
各メール・ユーザについて,次のコマンドを入力します。 ここで,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)
Qualcomm の POP3 サービスから新しく実装された POP3 に移行するには,次のタスクを実行します。
/etc/inetd.conf
および
/etc/services
構成ファイルが,7.4.1 項
で説明されているとおりに,正しいエントリによって更新されていることを確認します。
古い
popauth
データベースが存在する場合は,次のコマンドを使用して
mailauth
データベースに変換します。
#
/usr/bin/mailauth -convert
メール・フォルダの変換が必要になるのは,以前に MH POP3 サーバを実行していた場合のみです。
7.4.3 POP メール・アカウントの構成
POP メール・アカウントを構成するには,ユーザ用の UNIX アカウントがまだ作成されていない場合は,『システム管理ガイド』 ガイドの説明に従ってアカウントを作成します。 ユーザのメールボックスは,自動的にセットアップされます。
ユーザのアカウントがサーバにセットアップされると,ユーザは,たとえば Netscape Communicator のような,オペレーティング・システム・ソフトウェアにバンドルされた POP3 互換のメール・アプリケーションを構成できるようになります。 ユーザには,ファシリティのメール・サービスについて,最低限,次の情報を提供する必要があります。
POP ユーザ名 -- UNIX ユーザ名と異なる場合に指定します。
POP 固有のパスワード -- UNIX パスワードと異なる場合に指定します。
POP サーバ名 -- メール・アプリケーションは,着信メールをこのサーバから収集します。
SMTP サーバ名 -- メール・アプリケーションは,発信メールをこのサーバに配信します。
ドメイン名 -- メール・アプリケーションは,アドレスが修飾されていない場合,このドメイン名を追加してドメイン・ベースのメール・アドレスを指定します。
POP サービスは,一般には,与えられたユーザ名とパスワードを UNIX パスワード・ファイル (通常,/etc/passwd
ファイル) に照らして確認することにより,ユーザ・アカウントを認証します。
Tru64 UNIX による POP の実装では,必要に応じて,C2 セキュア・システム上における認証のための SIA インタフェースをサポートするよう拡張されています。
セキュリティを向上させるため,システム管理者は,POP ユーザにログイン・パスワードに変わる代替パスワードを使用させることができます。 このため,POP パスワードがネットワーク上で侵害を受けた場合でも,システムへのアクセスが危険にさらされることがなくなります。
POP 認証のための代替パスワードを有効にするには,次の 2 つの方法があります。
POP ユーザが
mailauth
データベース (/etc/pop.auth.dir
および
/etc/pop.auth.pag
) に,代替パスワードを格納するよう手配する方法。
メール・ユーザを APOP (Authenticated POP) ユーザとして同じ
mailauth
データベースに追加する方法。
APOP は,暗号化認証メカニズムおよび代替パスワードを使用するので,標準の POP よりも安全ですが,これを利用するためにはユーザが APOP と互換性のあるメール・クライアント・アプリケーションを使う必要があります。
CDE (Common Desktop Environment) のアプリケーション・マネージャの SysMan Menu アプリケーションを使用すれば,いずれの認証方法も有効にすることができます。 SysMan Menu アプリケーションを起動するには,1.2.1 項 の指示に従った後,次の手順を実行してください。
注意
管理している環境にいるユーザが,従来の POP3 を実装したアプリケーションを使用している場合,7.4.2 項の説明に従ってそれらを新しい POP3 の実装に移行してから,代替パスワードを有効にします。
SysMan Menu で,[メール] --> [メール・アカウントの管理] を選択します。 「メール・ユーザ管理」ウィンドウが表示されます。 また,次のコマンドを実行して,このユーティリティを起動することも可能です。
# sysman mailusradm &
「特定のユーザのリスト」ラジオ・ボタンを選択し,[コンパイル・リスト] をクリックします。
ダイアログ・ボックスにユーザ名またはワイルドカードを入力して [了解] を選択します。
代替パスワードを必要とするユーザの名前を選択します。
プルダウン・メニューから,対象のメール・サービス・タイプを選択します。 ユーザに対して POP メール用の代替パスワードを使用するよう要求するには, [POP with Mail Password] を選択します。 ユーザのメール・サービスを APOP に切り替えるには,[APOP with Mail Password] を選択します。
[了解] を選択して,変更内容を保存します。
POP または APOP の代替パスワードを入力して,[了解] を選択します。
ユーザは,オプションを指定せずに
mailauth
コマンドを実行することにより,後でパスワードを変更することができます。
次に例を示します。
% /usr/bin/mailauth
[了解] を選択して,アカウントが正常に変更されたというメッセージを消去します。
[終了] を選択して,「メール・ユーザ管理」ウィンドウを閉じます。
複数のアカウントについて認証を変更する必要がある場合は,手順 2 で [すべてのローカル・ユーザのリスト] を選択します。
[Ctrl] キーを押しながらマウスの右ボタンをクリックすると,リストから複数のユーザ名を選択することができます。
メール・ユーザ管理
ユーティリティの詳細については,
mailusradm
(8)
オプションで,mailauth
を使用して認証をセットアップすることもできます。
詳細については,
mailauth
(8)7.4.5 管理ツール
POP サービスの管理には,次のツールを使用することができます。
mailauth
-- セカンダリ・メール認証データベースの管理に使用するユーティリティです。
詳細については,
mailauth
(8)
mailusradm
-- メール・ユーザを構成するために使用する管理 GUI ユーティリティです。
詳細については,
mailusradm
(8)
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 ファイルおよびディレクトリ
ファイルまたはディレクトリ | 目的 |
|
システムの各ユーザについてのアカウント情報が入っている。 このファイルの中に構成されたユーザは,省略時の設定で,POP メールを使用することができる。 |
|
POP および IMAP ユーザの認証に使用される,暗号化されたメール認証データベースが入っている。
このデータベースの編集の詳細については,
|
|
システム上の すべての 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
Cyrus IMAP4 Revision 1 サーバのバージョン 1.6.1 から,quota
および
user
構成ディレクトリ内の IMAP ファイル群は,各ユーザ名の最初の 1 文字によって分類されて,a
〜
z
のサブディレクトリに格納されるようになりました。
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 項 の説明に従ってください。
ユーザのメール・サービス・タイプを変更するには,次の手順を実行してください。
SysMan Menu で,[メール] --> [メール・アカウントの管理] を選択します。 「メール・ユーザ管理」ウィンドウが表示されます。 また,次のコマンドを実行してこのユーティリティを起動することも可能です。
# sysman mailusradm &
「特定のユーザのリスト」のラジオ・ボタンを選択し,[コンパイル・リスト] をクリックします。
ダイアログ・ボックスにユーザ名またはワイルドカードを入力して [了解] を選択します。
メール・サービス・タイプを変更するユーザの名前をリストから選択します。
プルダウン・メニューから,対象のメール・サービス・タイプを選択します。 ユーザに対して IMAP メール用の代替パスワードを使用するよう要求するには,[IMAP with Mail Password] を選択します。 そうでない場合は,[IMAP] を選択して同じパスワードを使用します。
このオプションを有効にすると,代替パスワードが,/etc/pop.auth.dir
および
/etc/pop.auth.pag
ファイルにある
mailauth
データベースに格納されます。
詳細については,
mailauth
(8)
[了解] を選択して,変更内容を保存します。
メール管理者のパスワードを入力します。 ほとんどの場合,このパスワードはルート・アカウントのパスワードと同じです。 [了解] を選択します。
ユーザのメールボックスに設定する特権を選択します。 ほとんどの場合,「All」を選択して,ユーザがメールボックスのメッセージの表示,変更,および削除を行えるようにします。 [了解] を選択します。
手順 5 で [IMAP with Mail Password] を選択しなかった場合は,手順 10 に進みます。
IMAP の代替パスワードを入力して,[了解] を選択します。
ユーザは,オプションを指定せずに
mailauth
コマンドを実行することにより,後でパスワードを変更することができます。
次に例を示します。
% /usr/bin/mailauth
[了解] を選択して,アカウントが正常に変更されたというメッセージを消去します。
[終了] を選択して,「メール・ユーザ管理」ウィンドウを閉じます。
複数の IMAP アカウントをセットアップする必要がある場合は,手順 2 で [すべてのローカル・ユーザのリスト] を選択します。 [Ctrl] キーを押しながらマウスの右ボタンをクリックすると,リストから複数のユーザ名を選択することができます。
詳細については,オンライン・ヘルプおよび
mailusradm
(8)
いったんユーザの IMAP アカウントがサーバ側にセットアップされると,ユーザはたとえば Netscape Communicator のような,オペレーティング・システム・ソフトウェアにバンドルされた IMAP4 互換のメール・アプリケーションを構成できるようになります。 ユーザには,ファシリティのメール・サービスについて,最低限,次の情報を提供する必要があります。
IMAP ユーザ名 -- UNIX ユーザ名と異なる場合に指定します。
IMAP パスワード -- UNIX パスワードと異なる場合に指定します。
IMAP メールボックス・ロケーション接頭辞 --
user.username
IMAP サーバ名 -- メール・アプリケーションは,着信メールをこのサーバから収集する。
SMTP サーバ名 -- メール・アプリケーションは,発信メールをこのサーバに配信する。
ドメイン名 -- メール・アプリケーションは,アドレスが修飾されていない場合,このドメイン名を追加してドメイン・ベースのメール・アドレスを指定する。
7.5.4 UNIX および POP3 メールからのユーザの移行
既存の UNIX または POP3 メール・ユーザを IMAP メールに変換するには,まず,7.5.3 項に説明するように,ユーザの IMAP アカウントをセットアップする必要があります。
さらに,次のように
mailcv
ツールを使用して,ユーザのメール・フォルダを IMAP に変換します。
注意
MH POP3 またはこのオペレーティング・システムに付属していないバージョンの Qualcomm POP3 を使用している場合は,7.4.2 項の説明に従ってそれらを新しい POP3 の実装に移行してから,IMAP に変換します。
ディレクトリを UNIX/POP3 メール・フォルダ・ディレクトリに変更します。
# cd /usr/spool/mail
次のように
su
コマンドを使用して,そのユーザになります。
# su username
mailcv
コマンドを使用してユーザのメール・フォルダを IMAP 形式に変換するには,そのユーザになる必要があります。
次のコマンドを入力します。 ここで,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)
次のように入力して,ユーザのアカウントへの
su
セッションを終了します。
% exit #
アカウントを IMAP に変更した後,変換プロセスの前に届いたメールは失われません。 新たに変換されたメッセージは,ユーザのメールボックスにある既存のメッセージに追加されます。
ユーザの UNIX または POP アカウントがサーバ上の IMAP アカウントに変換されたら,ユーザはメール・アプリケーションを再度構成する必要があります。 ユーザが,たとえばこのオペレーティング・システムに付属の Netscape Communicator のような,IMAP4 と互換性のあるメール・アプリケーションを持っていることを確認します。
また,ファシリティのメール・サービスについて,7.5.3 項
に示す情報をユーザに提供する必要があります。
7.5.5 管理ツール
IMAP サーバの管理には,次のツールを使用することができます。
cyradm
-- ユーザ,フォルダ,サブフォルダなどの構成および管理に使用するコマンド行ユーティリティです。
詳細については,
cyradm
(1)
deliver
-- メールを IMAP メールボックスに配信するために使用するユーティリティです。
詳細については,
deliver
(8)
dohash
-- IMAP 構成ディレクトリを,旧バージョンの Cyrus IMAP4 Revision 1 サーバのフォーマットから,バージョン 1.6.1 以降の新しいフォーマットに変換するユーティリティです。
逆方向の変換を行う
undohash
ユーティリティもあります。
詳細については,
dohash
(8)
imapquota
-- IMAP のメール・クォータの使用状況の報告と修正に使用するユーティリティです。
詳細については,
imapquota
(8)
mailauth
-- セカンダリ・メール・パスワード・データベースの管理に使用するユーティリティです。
詳細については,
mailauth
(8)
mailusradm
-- メール・ユーザの構成に使用するシステム管理 GUI ユーティリティです。
詳細については,
mailusradm
(8)
reconstruct
-- IMAP メールボックスの再構築に使用するユーティリティです。
詳細については,
reconstruct
(8)
IMAP サーバ・ソフトウェアは,syslogd
デーモンにログ・メッセージを送信します。
ログ情報は,/var/adm/syslog.dated/date/mail.log
ファイルに格納されます。
このデータは問題解決に使用することができます。
重大度のレベルは次のとおりです。
認証の成功および失敗。
クォータの使用状況についての障害を含む I/O エラー。 メッセージには,特定のファイルおよび UNIX エラーが含まれます。
保護メカニズム障害,クライアント・インアクティビティ・タイムアウト。
メールボックスのオープン。
IMAP 構造およびメール・ファイルは,図 7-6
に示すように,ファイル・システム中に分散されています。
図 7-6: IMAP ディレクトリの構造
実行時の構成情報は,すべて
/etc/imapd.conf
ファイルに格納されます。
このファイルには,次のサイト構成およびポリシのオプションが入っています。
構成ディレクトリの位置
パーティション名およびそれに対応するディレクトリ・ルート
警告メッセージを発するクォータのしきい値
匿名ログインを許可するかどうか
ユーザ用の
INBOX
を自動的に作成するかどうか
詳細については,
imapd.conf
(4)
/etc/imapd.conf
ファイルの中で指定された構成ディレクトリには,表 7-2に示す項目が入っています。
表 7-2: 構成ディレクトリの内容
ファイルまたはディレクトリ | 目的 |
|
サーバ上の IMAP メールボックスのソートされたリストに加え,メールボックスのクォータ・ルートおよびアクセス制御リスト (ACL) が入っている。
クォータ・ルートと ACL については,それぞれ
7.5.9 項と
7.5.8 項で説明する。
ACL は,他の場所に格納された情報から再構築できない,セキュリティの重要度が非常に高い情報なので, |
|
ユーザの加入情報が入っている。 ユーザごとに対応するファイルが 1 つ存在しており,各ファイルにはユーザのメールボックスの分類済みリストが格納されている。 各ファイルは,対応するユーザの名前に拡張子
加入ファイルが破壊された場合,これを回復するユーティリティは存在しない。 バックアップから失われたファイルをリストアすることは可能である。 |
|
アクティブなサーバ・プロセスごとにファイルが 1 つずつ用意される。 ファイル名はプロセス ID の ASCII 表示で,ファイルにはタブで区切られた次のフィールドがある。
|
|
制限付き IMAP ユーザのクォータ指定が格納されている。 1 人のユーザ用に複数のファイルが存在する場合もある。 各ファイルは,クォータ・ルートの限界値を示している (7.5.9 項 を参照)。 各ファイルは,文字列
|
|
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 後にドット (.) が付いたものである。 |
|
メールボックス自体についてのマジック番号と可変長情報が入っている。 |
|
メールボックス自体およびメールボックスにある各メッセージについての固定長情報が入っている。 |
|
メールボックスにある各メッセージについての可変長情報が入っている。 |
|
メールボックスの読み取り許可が与えられている各ユーザの状態についての可変長情報が入っている。 |
reconstruct
ユーティリティは,メールボックス・ディレクトリの破壊された部分を回復するために使用することができます。
reconstruct
ユーティリティは,既存のヘッダおよびインデックス・ファイルを見つけると,メッセージ・ファイル自体から導き出せないデータ,たとえばフラグ名,フラグ状態,および内部日付のようなデータをすべてそれらの中に保存しようとします。
このユーティリティは,他の情報をすべてメッセージ・ファイルから導き出します。
損傷を受けたディスクは,メッセージ・ファイルをバックアップからリストアし,reconstruct
ユーティリティを実行して他のファイルから再度生成することにより回復が可能です。
reconstruct
プログラムは,クォータ・ファイルに記録されたクォータ使用量の調整は行いません。
したがって,reconstruct
を実行した後,imapquota -f
を実行して,クォータ・ルート・ファイルを修正してください。
7.5.7 メールボックスのネームスペース
IMAP サーバは,netnews
ネームスペース規則を使用してメールボックスを表現します。
メールボックス名には,次の制約があります。
大文字小文字を区別します。
最初と最後にはピリオド (.) を使用しません。
行中にピリオドを 2 つ続けて (..) 入れてはなりません。
ASCII 文字以外の文字,シェル・メタキャラクタ,またはバックスラッシュ (/) は使用できません。
ユーザ用の個人メールボックスはすべて,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)
アクセス権は,次のように定義されています。
l
)ユーザは,メールボックスが存在していることを確認できます。
r
)ユーザは,メールボックスの読み取りが可能です。 すなわち,メールボックスの選択,データの取得,検索の実行,およびメールボックスからのメッセージのコピーを行うことができます。
s
)ユーザ別の seen 状態が保存されています。
サーバは,ユーザの
Seen
および
Recent
フラグを保存します。
w
)ユーザは,Seen
および
Deleted
(他のアクセス権で制御されます) 以外のフラグやキーワードを変更することができます。
i
)ユーザは,新規メッセージをメールボックスに挿入することができます。
p
)ユーザは,メールをメールボックスのサブミッション・アドレスに送信することができます。
この権利は
i
権とは異なり,配信システムによって送信メッセージの中に追跡情報が挿入されます。
c
)ユーザは,新規のサブメールボックスを作成することができます。
d
)ユーザは,Deleted
フラグの格納,抹消の実行,および削除を行うことができます。
a
)ユーザは,メールボックスの ACL を変更することができます。
アクセス権はさまざまな方法で組み合わせることができます。
ユーザはメールボックスを読み取ることができます。
ユーザはメールを読み取り,それを配信システムを通じてポストすることができます。
ほとんどの配信システムは認証機能を備えていないので,post
権は,通常,anonymous
ユーザに対してのみ意味を持ちます。
ユーザは,メールボックスを確認して読み取ることはできますが,サーバは
Seen
および
Recent
フラグを保存しません。
このアクセス権のセットは,主に
anonymous IMAP
の場合に便利です。
ユーザはメールボックスを読み取ることができ,サーバは
Seen
および
Recent
フラグを保存しますが,ユーザは多様なメールボックスのリスト・コマンドを通じてメールボックスを表示することができません。
メールボックスにアクセスするためには,その名前を知る必要があります。
ユーザは,メールボックスを読み取ることができ,また 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
は,INBOX
,saved
,および
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 メールの管理
この節では,次に挙げるメール関連の各タスクの実施方法を説明します。
メール・キューを監視することによって, リモート・システムへ転送するためにローカル・システムにキュー登録されているジョブなど, ネットワーキング・オペレーションのいくつかのタイプについて,状態を調べることができます。 一般ユーザおよびシステム管理者は,メール・キューを監視できます。
メール・キューの内容を表示するには,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)
長期間,メインのホストがオフラインになると,メール・キューが非常に大きくなります。
その結果,sendmail
ユーティリティは,大きなキューをソートすることに長時間かかり,メール環境の質にかなり影響を与えます。
メインのホストがオフラインの間,メール・キューを保管しておくと,メール環境は正常に機能できます。
メール・キューを保管するには,次の手順に従ってください。
ルートとしてログインします。
cd
コマンドを使用して,/var/spool
ディレクトリに変更します。
次のコマンドを入力して
sendmail
ユーティリティを停止します。
# /sbin/init.d/sendmail stop
次のコマンドを入力して
sendmail
ユーティリティが実行していないことを確かめます。
# ps -e | grep sendmail
次のコマンドを入力して
sendmail
子プロセスが実行していないことを確かめます。
# ps -e | grep queue
リスト内のプロセスが,たとえばメッセージ・キュー ID が含まれているというように
sendmail
に関係している場合は,キューを移動する前にプロセスが終了するまで待ちます。
そうしないとキューを壊してしまう場合もあります。
mv
コマンドを使用して,
mqueue
ディレクトリを
old.mqueue
ディレクトリに移動します。
mkdir
コマンドを使用して,新しい
mqueue
ディレクトリを作成します。
chmod
コマンドを使用して,ディレクトリの許可コードを 775 に変更します。
次のコマンドを使用して,sendmail
ユーティリティを再起動させます。
# /sbin/init.d/sendmail restart
メインのホストがオンラインになった後に,次のコマンドを使用して, 古いメール・キューを処理します。
# /usr/sbin/sendmail -oQ/var/spool/old.mqueue -q
キューが空の場合は,次のコマンドを使用してキューを削除します。
# rm -r /var/spool/old.mqueue
スタンドアロンまたはサーバ・システムの別名情報の管理および配布の方法によって決まりますが,メール環境で使用するために別名情報を提供する方法は 3 つあります。
/var/adm/sendmail/aliases
ファイル
NIS 別名データベース
LDAP (Lightweight Directory Access Protocol)
省略時の設定では,/var/adm/sendmail/aliases
ファイルの許可コードは 644 です。
これは,グローバル・ユーザが,ファイルの変更およびファイルへの変更内容の書き込みができないことを意味します。
これによって,十分に安全なシステムが形成される一方,
グローバル・ユーザ・リストのメンテナンスは,システム管理者に委ねられます。
次の手順に従って,メンテナンスの責任を分散できます。
ディレクトリにグローバル・メンテナンス担当者のためのローカル別名ファイルを作成します。 このファイルおよびディレクトリの両方は,別のメンテナンス担当者によってアクセスできなければなりません。
追加の別名ファイルを含むエントリを
/var/adm/sendmail/aliases
ファイルに作成します。
エントリの形式は,次のとおりです。
alias_name: :include:filename
filenameは,別名ファイルの完全パス名およびファイル名です。
newaliases
コマンドを使用して,新しいバージョンの別名ファイルを構築します。
詳細については,
aliases
(4)
メール環境で使用する別名情報を管理し,配布するためにオプションとして NIS を使用することができます。 NIS 別名データベースを使用するには,次の手順に従ってください。
NISをまだインストールして構成していない場合は,
nissetup
スクリプトを使用して行います。
svcsetup
スクリプトを使用して
svc.conf
ファイルを編集し,別名エントリを変更して
yp
(NIS)を含めます。
NIS 別名マップを編集して,必要な別名情報を含めます。
NISの構成についての説明は第 3 章を,NISマップの更新についての説明は3.4.5 項を参照してください。
最後に,メール環境で使用する別名情報を管理,配布する手段として,LDAP を使用することもできます。 LDAP による別名情報の管理は,別名データベースが非常に大きな場合や,ネットワーク上のいくつものシステムが同じ情報を共有する場合に最適です。
LDAP を使用して別名情報を管理するには,次の手順を実行します。
LDAP サーバを構成し,環境に応じたスキーマを作成します。
LDAP サービスはメール・サーバ上に構成することもできますが,可能であれば独立したシステム上に構成してください。
詳細については,
sendmail.m4
(8)
スキーマに 2 つの属性を作成します。 1 つはユーザのメール・アドレス用,もう 1 つはユーザの別名用です。
/var/adm/sendmail
ディレクトリ内の
hostname.m4
ファイルを手作業で編集し,次の変更を加えます。
_LDAPMap
に
{T}
を設定し,ルックアップを使用可能にします。
_LDAPParam
を設定し,マップとその引数リストを定義します。
詳細については,
sendmail.m4
(8)
/var/adm/sendmail
ディレクトリに移動し,次のコマンドを実行します。
# make -f Makefile.cf.hostname
次のコマンドを実行し,hostname.cf
ファイルの名前を
sendmail.cf
に変更します。
# mv hostname.cf sendmail.cf
次のコマンドを実行して
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
Tru64 UNIX には,次に挙げるメール・ユーティリティが含まれています。
mail
および
binmail
ユーティリティ (標準) --
sendmail
ユーティリティによって,ローカル環境でのメール配信に使用されます。
mail
ユーティリティの許可コードには root に対する setuid が設定されているため,/var/spool/mail
ディレクトリにあるユーザのローカル・メールボックスにすべてのメールを配信します。
詳細については,『Tru64 UNIX ユーザーズ・ガイド』および
mail
(1)
mailx
および
Mail
ユーティリティ --
BSD (Berkeley Software Distribution) と UNIX System Laboratories, Inc.
の SVIDI (System V Release 4) のメール・ユーティリティの組み合わせ。mailx
ユーティリティは,ユーザのメール・ボックスへの配信に
binmail
ユーティリティを使用し,binmail
ユーティリティよりも多くのユーザ機能を提供します。
詳細については,『Tru64 UNIX ユーザーズ・ガイド』および
mail
(1)
dtmail
ユーティリティ -- CDE での省略時のメール・プログラム。
このユーティリティはトランスポートとして
sendmail
を使用し,mailx
と同様の方法で情報を保管します。
また,POP3 メールの受信と MIME 符号化もサポートします。
詳細については,『Common Desktop Environment: ユーザーズ・ガイド』および
dtmail
(1)
mh
メッセージ・ハンドラ・ユーティリティ --
mh
コマンドおよび関連コマンドは,オプションの RAND Corporation Mail Handler サブセット (OSFMH
) に含まれています。
メッセージ・ハンドラはいくつかのシェル・コマンドから構成されており,各コマンドによって異なる機能が提供されます。
たとえば,新しいメールを読むには
inc
コマンド,メッセージの作成には
comp
コマンドがそれぞれ使用されます。mh
ユーティリティも
mailx
ユーティリティと同様,ユーザのメールボックスへのメール配信に
mail
ユーティリティを使用します。mh
ユーティリティのグラフィカル・ユーザ・インタフェースとして,xmh
コマンドも使用できます。
詳細については,
xmh
(1X)
Netscape Messenger --
Tru64 UNIX に付属している Netscape Communicator のコンポーネントの 1 つ。
Netscape Messenger では,POP3 および IMAP4 のメール・サーバからメールを受信できます。
また,画像を埋め込んだ HTML 形式の電子メールの作成,添付ファイルのMIME 符号化,メッセージの暗号化と復号化によるプライバシー保護,フィルタによる受信メッセージの各フォルダへの振り分け,および電子メール・アドレスの検出といった機能も備えています。
Netscape Communicator
についての詳細は,
netscape
(1)
sendmail
についての詳細は,
sendmail
(8)sendmail.cf
(4)sendmail.m4
(8)