Solaris のシステム管理 (資源管理とネットワークサービス)

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

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

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

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

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

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

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

/usr/bin/mail
/usr/bin/mailx
$OPENWINHOME/bin/mailtool
/usr/dt/bin/dtmail

メール転送エージェント

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

メールユーザーエージェントからメッセージを受信する
宛先アドレスを認識する
適切な配信エージェントを選択してメールを配信する
他のメール転送エージェントからのメールを受信する

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

「ローカル配信エージェント」は、メールの配信プロトコルを実行するプログラムです。Solaris オペレーティング環境に搭載されているローカル配信エージェントについては以下に述べます。

UUCP ローカル配信エージェントは uux を使ってメールを配信します。
標準の Solaris リリースでは mail.local であるローカル配信エージェントを配信します。

第 27 章「メールサービスの新機能 (リファレンス)」では、以下の関連項目について説明します。

メールプログラム

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

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

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

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

smtp は、他のサーバーへの通常 (従来の形式) の SMTP 転送機能を提供します。
esmtp は、他のサーバーへの拡張 SMTP 転送機能を提供します。
smtp8 は、8 ビットデータを MIME に変更することなく、他のサーバーに SMTP 転送機能を提供します。
dsmtp は、F=% メールプログラムフラグを使ってオンデマンド配信機能を提供します。第 27 章「メールサービスの新機能 (リファレンス)」の MAILER() の宣言についての変更点と配信エージェントの新しいフラグを参照してください。

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

UUCP の使用は、できるだけ避けてください。説明については、http://www.sendmail.org/m4/uucp.html を参照するか、/usr/lib/mail/README で「UUCP メールプログラムの使用」の文字列を検索してください。

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

uucp-old: $=U クラスの名前が uucp-old に送られます。 uucp は、このメールプログラムの以前の名前です。uucp-old メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。
uucp-new: $=Y クラスの名前が uucp-new に送られます。受信側の UUCP メールプログラムが単一の転送で複数の受信者を管理できる場合は、このメールプログラムを使用します。suucp は、このメールプログラムの以前の名前です。uucp-new メールプログラムはヘッダーで感嘆符を用いるアドレスも使用します。

構成に MAILER(smtp) も指定されている場合は、さらに以下の 2 つのメールプログラムが定義されます。

uucp-dom: このメールプログラムは、ドメインスタイルアドレスを使用し、基本的に SMTP のリライトルールを適用します。
uucp-uudom: $=Z クラスの名前が uucp-uudom に送られます。uucp-uudom と uucp-dom は、ドメインスタイルアドレスという同じヘッダーアドレスフォーマットを使用します。

注 -

smtp メールプログラムは UUCP メールプログラムを変更するので、.mc ファイルの MAILER(uucp) の前に必ず MAILER(smtp) を記述します。

メールアドレス

「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。メールボックスを含む複数のシステムで構成されるメールシステム、または 1 つ以上のドメインで構成されるメールシステムを管理する場合は複雑になります。UUCP またはその他のメールシステムによって外部に接続する場合は、さらに複雑になります。以下の節で、メールアドレスの各部とその複雑さを説明しています。

ドメインとサブドメイン

電子メールのアドレス指定には、ドメインが使用されます。「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。ドメインは 1 つ以上のサブドメインを持つことができます。アドレスのドメインとサブドメインは、ファイルシステムの階層と比較できます。サブディレクトリが上位のディレクトリに含まれるように、メールアドレスの各サブドメインもその右のドメインに含まれると考えられます。

次の表に米国における最上位のドメインを示します。

表 26-7 最上位のドメイン


ドメイン	説明
`com`	企業
`edu`	教育機関用
`gov`	米国の政府機関
`mil`	米国の軍事機関
`net`	ネットワーク組織
`org`	その他の非営利組織

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

ドメインについての詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「ドメインネームシステム (概要)」を参照してください。

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

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

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 )

注 -

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

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

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

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

user@host.domain

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

host.domain!user

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

user@domain

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

メールボックスファイル

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

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

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

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

表 26-8 メールボックス名の書式についての規則


書式	説明
`username`	多くの場合、ユーザー名はメールボックス名と同じ
`Firstname` `.Lastname` `Firstname` `_Lastname` `Firstinitial` `.Lastname` `Firstinitial_Lastname`	ユーザー名は、ドット (または下線) でファーストネームとラストネームに区切ったフルネームか、あるいはファーストネームがイニシャルで、ドット (または下線) でイニシャルとラストネームを区切ったもの
`postmaster`	ユーザーは、`postmaster` のメールボックスに質問を送ったり、問題点を報告したりできる。通常は各サイトとドメインに `postmaster` メールボックスがある
`MAILER-DAEMON`	`sendmail` は、`MAILER-DAEMON` 宛てのメールを自動的にポストマスターに送る
`aliasname` `-request`	`-request` で終わる名前は、配布リストの管理アドレス。このアドレスは、配布リストを管理する人にメールをリダイレクトする
`owner-` `aliasname`	`owner-` で始まる名前は、配布リストの管理アドレス。このアドレスは、メールエラーを処理する人にメールをリダイレクトする
`owner-owner`	この別名は、エラーを戻す先の `owner-aliasname` の別名がない場合に使用される。このアドレスは、メールエラーを処理する人にメールをリダイレクトし、大量の別名を管理する任意のシステムで定義される
`local` `%domain`	パーセント記号 (`%`) は、メッセージがその宛先に着くと展開されるローカルアドレスを示す。ほとんどのメールシステムは、`%` 記号つきのメールボックス名を全メールアドレスとして翻訳する。`%` は `@` と置き換えられ、メールはそれに応じてリダイレクトされる。多くの人が `%` を使用するが、これは正式な標準ではない。この規則は、電子メールの世界では「パーセントハック」と呼ばれている。この機能は、メールに問題が起こった場合にデバッグに使用されることが多い

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

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

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

メール別名

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

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

メールホストとして適切なのは、ローカルエリアネットワーク上のシステムで、電話回線に PPP または UUCP リンクを設定するためのモデムがあるものです。もう 1 つの候補は、ネットワークからグローバルなインターネットネットワークへのルーターとして構成されたシステムです。詳細は、第 29 章「Solaris PPP 4.0 (概要)」、第 38 章「UUCP (概要)」、および『Solaris のシステム管理 (IP サービス)』の「ルーターの構成」を参照してください。ローカルネットワークのどのシステムにもモデムがない場合は、その中の 1 つをメールホストに指定します。

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

メールサーバー

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

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

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

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

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

メールクライアント

「メールクライアント」は、メールサーバーでメールを受信し、ローカルの /var/mail のないシステムです。このような構成は、リモートモードと呼ばれます。リモートモードは、デフォルトでは /etc/mail/subsidiary.cf で使用することができます。

メールクライアントには、/etc/vfstab ファイルに適切なエントリがあり、メールサーバーからメールボックスをマウントするマウント先があることを確認する必要があります。またクライアントの別名の宛先が、クライアント名ではなく、メールサーバーのホスト名になっていることを確認してください。作業手順については、第 25 章「メールサービス (手順)」のメールクライアントを設定する方法を参照してください。

メールゲートウェイ

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

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

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

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

この図は、異なるメールプログラムを使用する 2 つのメールゲートウェイを示しています。

メールゲートウェイを設定する場合に、必要とするものにもっとも近いゲートウェイ構成ファイルを見つけ、状況に合わせて修正する必要があります。

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