Solaris のシステム管理 (第 3 巻)

メールサービスの関連用語

メールファイルとプログラムに加え、メールサービスを構築するには、その他多数の構成要素が必要です。次の節ではこれらの構成要素と、それらを説明するのに使用する用語の一部を定義します。

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

メールサービスソフトウェアの関連用語

ここでは、メールシステムのソフトウェアの構成要素について説明します。サービスには次のものがあります。

メールユーザーエージェント
メール転送エージェント
メール配信エージェント

それ以外のソフトウェアの構成要素には、ドメイン名、メールアドレス、メールボックス、そしてメールの別名があります。

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

「メールユーザーエージェント」は、ユーザーと sendmail プログラムなどのメール転送エージェントとの間のインタフェースとして機能します。Solaris オペレーティング環境に搭載されているメールユーザーエージェントは、/usr/bin/mail、/usr/bin/mailx、$OPENWINHOME/bin/mailtool、および /usr/dt/bin/dtmail です。

メール転送エージェント

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

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

メール配信エージェント

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

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

メールプログラム

「メールプログラム」は sendmail 独自の用語です。メール配信エージェントはカスタマイズできます。メールプログラムは sendmail によって使用され、カスタマイズしたメール配信エージェントまたはメール転送エージェントの特定のインスタンスを指定します。

ネットワークのすべてのシステムの sendmail.cf ファイルには、1 つ以上のメールプログラムを指定する必要があります。

smtp メールプログラムは SMTP を使用してメッセージを転送します。SMTP はインターネットで使用される標準のメールプロトコルです。SMTP メールヘッダーは次のようになります。

To: paul@phoenix.stateu.edu
From: Iggy.Ignatz@eng.acme.com

同じドメインの 2 人のユーザー間でメールが送信されると、ヘッダーは次のようになります。

To: Irving.Who@eng.acme.com
From: Iggy.Ignatz@eng.acme.com

ドメイン外にメールを送信するとき、特にインターネット経由でメールボックスに送信する必要がある場合は、SMTP を使用してください。

uucp-old メールプログラムはメッセージの配信に uux を使用しますが、ヘッダーをドメイン形式のアドレスでフォーマットします。To: 行と Cc: 行は SMTP ヘッダーとほぼ同様にドメインによってフォーマットされます。uucp ヘッダーは次のようになります。

To: paul@phoenix.stateu.com
From: ignatz@eng.acme.com

ドメイン形式の名前を処理し、理解できるシステムへの UUCP メールには uucp-uudom を使用してください。また、発信者はドメイン形式の名前を処理し、インターネットからの返信を受信できるようにしておく必要があります。

uucp-old メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。これはオリジナルのメールプログラムの 1 つであり、ヘッダーは次のようになります。

To: edu!stateu!phoenix!paul
From: acme!ignatz

sendmail.cf ファイルにメールプログラム仕様を提供して、他のメール配信エージェントを定義できます。メールプログラムに関しては、/usr/lib/mail/README にも記載してあります。

ドメイン名

「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。電子メールのアドレスにもドメインが使用されています。電子メールのアドレスは、次のようなフォーマットになっています。

user@subdomain. ... .subdomain2.subdomain1.top-level-domain

アドレスの @ 記号より左の部分はローカルアドレスです。ローカルアドレスには次の情報が含まれます。

別のメールトランスポートを使用するルーティング (たとえば、bob::vmsvax@gateway または smallberries%mill.uucp@gateway )

別名 (たとえば、iggy.ignatz )

受信側のメールプログラムでアドレスのローカル部分を解釈する必要があります。

アドレスの @ 記号より右の部分は、ローカルアドレスが位置するドメインアドレスを示します。ドットはドメインアドレスの各部分を区切ります。ドメインは、組織、物理的なエリア、地理的な領域などを表します。

ドメインアドレスは大文字と小文字を区別しません。アドレスのドメイン部分で大文字、小文字、またはそれらを混用しても相違はありません。

ドメイン情報の順序は階層的です。つまり、アドレスがローカルであるほど @ 記号に近づきます。

サブドメインの数が多いほど、宛先に関して提供される情報が詳細になります。ファイルシステム階層におけるサブディレクトリがその上のディレクトリの中にあると解釈されるのと同様に、メールアドレス内の各サブドメインは、その右にあるドメインの中にあると解釈されます。

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

表 35-3 米国の最上位のドメイン


ドメイン	説明
`Com`	企業
`Edu`	教育機関用
`Gov`	米国の政府機関
`Mil`	米国の軍事機関
`Net`	ネットワーク組織
`Org`	非営利組織

Donnalyn Frey および Rick Adams による『A Directory of Electronic Mail Addressing and Networks』(O'Reilly & Associates, Inc., 1993) には、国際的な最上位のドメインアドレスリストが載っており、定期的に更新されています。

メールの配信においては、名前空間のドメイン名とメールドメイン名は一致しないことがあります。しかし、DNS ドメイン名とメールドメイン名は同じでなければなりません。sendmail プログラムは、デフォルトでドメイン名から最初の構成要素を取り除き、メールドメイン名とします。たとえば、NIS+ ドメイン名が bldg5.eng.acme.com であれば、そのメールドメイン名は eng.acme.com となります。

注 -

メールドメインアドレスは大文字と小文字の区別をしませんが、名前空間のドメイン名は異なります。メールと名前空間のドメイン名を設定するときは、小文字を使用するのが最善です。

メールアドレス

「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。

ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。

ただし、複数のメールボックスと、複数のドメインを持つ複数のメールシステムを管理する場合、または外部に UUCP (またはその他の) メール接続がある場合は、メールアドレス指定はもっと複雑になります。メールアドレスには「経路依存型」と「経路非依存型」があり、2 つの混用も可能です。経路依存のアドレス指定は、古い仕様に基づいており、ほとんどの場合は必要なく、また望ましくありません。

経路に依存しないアドレス指定

経路に依存しないアドレス指定では、電子メールメッセージの発信者は、受信者の名前と最終の宛先アドレスを指定する必要があります。経路に依存しないアドレスは通常インターネットのような高速ネットワークで使用されます。さらに、新しい UUCP 接続はドメイン形式の名前を頻繁に使用します。経路に依存しないアドレスは次のようなフォーマットになります。

user@host.domain

UUCP 接続は次のアドレスフォーマットで使用できます。

host.domain!user

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

user@domain

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

経路依存のアドレス指定

経路依存のアドレス指定では、電子メールメッセージの発信者が、ローカルアドレス (通常はユーザー名) とその最終の宛先、および最終の宛先に到達するためにメッセージが通らなければならない経路を指定する必要があります。経路依存のアドレスは、UUCP ネットワーク上では一般的に使用され、フォーマットは次のとおりです。

path!host!user

電子メールアドレスの一部に感嘆符がある場合は、常に経路のすべて (またはその一部) が発信者によって指定されています。経路依存のアドレスは常に左から右に読みます。

この場合、電子メールアドレスは、次のようになります。

venus!acme!sierra!ignatz

これは、ignatz というユーザーに送信されたメールは、venus というシステムにまず送られ、それに引き続いて、acme、sierra に転送されることを示しています (これはあくまでも実在する経路ではないので注意してください)。 4 つのメールハンドラのいずれかが機能しないときは、メッセージは遅れるか、配信できないとして戻されます。

uucp メールプログラムを通してメールが送信される場合、アドレス指定は経路依存に制限されません。uucp メールプログラムによっては、経路に依存しないアドレス指定も処理します。

メールボックス

「メールボックス」は、電子メールメッセージの最終宛先であるメールサーバー内のファイルです。メールボックスの名前は、ユーザー名、またはポストマスターのような特定の職務を持つ人にメールを届ける場所の名前でもかまいません。メールボックスは、ユーザーのローカルシステムかリモートのメールサーバーのいずれかの /var/mail/username ファイルにあります。ただし、いずれの場合でも、メールボックスはメールが配信されるシステム上にあります。

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

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

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

表 35-4 メールボックス名のフォーマットについての規則


フォーマット	説明
`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`	パーセント記号 (`%`) は、メッセージがその宛先に着くと展開されるローカルアドレスを示す。ほとんどのメールシステムは、`%` 記号つきのメールボックス名を全メールアドレスとして翻訳する。`%` は `@` と置き換えられ、メールはそれに応じてリダイレクトされる。多くの人が `%` を使用するが、これは正式な標準ではない。電子メールの世界では「パーセントハック」と呼ばれている。この機能は、メールに問題が起こった場合にデバッグに使用されることが多い

バージョン 8 から、所有者別名が存在する場合には、グループ別名に送信されたメールの封筒の送信者は、所有者別名から拡張されたアドレスに変更されるようになりました。この変更によって、メールエラーは、送信者に返送されるのではなく、別名の所有者に送信されるようになりました。別名に送信したメールは、配信時に、別名の所有者から来たようにみえます。つまり、別名宛てではなく、直接返信が必要な場合には、ユーザーは自らを識別するように注意する必要があります。次の別名のフォーマットは、この変更に関連したいくつかの問題に対応します。

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

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

メールの別名

別名 (alias) とは、もう 1 つの別の名前を指します。電子メールでは、メールボックスの位置を割り当てたり、メールリストを定義したりするために別名を使用できます。

大きなサイトでは通常、メール別名は、メールボックスの位置を定義します。メール別名を作成するのは、企業で個人のアドレスの一部としてメールストップを設定するのと似ています。メールストップを提供しない場合は、メールは中央アドレスに配信されます。建物内のどこにメールを配信するかを決定するには、別の作業が必要となり、ミスの可能性が増えます。たとえば、同じ建物に Kevin Smith という名前の人が 2 人いる場合、どちらの Kevin も、別の Kevin 宛のメールを受け取る可能性が高くなります。

メールリストを作成するときは、なるべくドメインの位置に依存しないアドレスを使用してください。別名ファイルの移植性と柔軟性を高めるため、別名エントリをできる限り一般的でシステムに依存しない形式にしてください。たとえば、システム mars のドメイン eng.acme.com に ignatz というユーザー名がある場合、別名は ignatz@mars ではなく、ignatz@eng としてください。ユーザー ignatz がシステム名を変更しても、eng ドメインには存在し続ける場合、システム名の変更を反映するように別名ファイルを更新する必要はありません。

別名エントリを作成するときは、1 行ごとに 1 つの別名を入力します。ユーザーのシステム名を含むエントリは 1 つだけにしてください。たとえば、ユーザー ignatz には、次のエントリを作成できます。

ignatz: iggy.ignatz
iggyi: iggy.ignatz
iggy.ignatz: ignatz@mars

ローカル名やドメインに別名を作成できます。たとえば、システム mars にメールボックスがあり、ドメイン planets 内のユーザー fred の別名エントリでは、 NIS+ 別名テーブルに次のエントリを作成できます。

fred: fred@planets

ドメイン外のユーザーを含むメールリストを作成するときは、ユーザー名とドメイン名を持つ別名を作成してください。たとえば、システム privet のドメイン mgmt.acme.com に smallberries というユーザー名がある場合、別名は smallberries@mgmt.acme.com とします。

送信者の電子メールアドレスは、メールがユーザードメイン外に発信されるときは、完全に修飾されたドメイン名に自動的に変換されます。

別名ファイルの使用

NIS+ mail_aliases テーブル、NIS aliases マップ、または、ローカルの /etc/mail/aliases ファイルでグローバルに使用するメール別名を作成します。また、同じ別名ファイルを使用してメールリストを作成して管理することができます。

メールサービスの構成に応じて、NIS または NIS+ ネームサービスを使用して別名を管理し、グローバル aliases データベースを維持したり、ローカルの /etc/mail/aliases ファイルをすべて同時に更新することにより、別名を同一にできます。

また、ユーザー自身が別名を作成して使用できます。ユーザーは、別名をユーザーだけが使用できるようにローカル ‾/.mailrc ファイルで作成することも、誰でも使用できるようにローカル /etc/mail/aliases ファイルで作成することもできます。ユーザーは通常は、NIS または NIS+ 別名ファイルを作成または管理できません。

メール構成のハードウェア要素

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

メールホスト
メールサーバー (1 つ以上)
メールクライアント

ユーザーがドメイン外のネットワークと通信をするためには、4 番目の要素であるメールゲートウェイを追加する必要があります。次の節では各ハードウェアコンポーネントについて説明しています。

メールホスト

「メールホスト」は、ネットワーク上でメインのメールマシンとして指定するマシンです。これはサイトにおいて、他のシステムでは配信できないメールを転送するためのマシンになります。hosts データベースにシステムをメールホストとして指定するには、ローカルの /etc/hosts ファイルか、ネームサービスのホストファイルで、IP アドレスの右に mailhost を追加します。メールホストシステムでは、main.cf ファイルもメール構成ファイルとして使用する必要があります。

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

サイトの中には、タイムシェアリング構成でネットワークに接続されていないスタンドアロンのマシンを使用するものがあります。つまり、スタンドアロンのマシンが、シリアルポートに接続された端末として機能する場合です。このような構成では、スタンドアロンのシステムを 1 つのシステムネットワークのメールホストとして扱うことで、電子メールを設定できます。

メールサーバー

「メールボックス」は単独のファイルで、特定ユーザー用の電子メールが含まれています。メールはユーザーのメールボックスが置かれている場所のシステム、つまりローカルマシンかリモートサーバーに配信されます。「メールサーバー」は、/var/mail ディレクトリにユーザーのメールボックスを保持しているいずれかのシステムになります。

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

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

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

全メールボックス用に 1 台のメールサーバーを設定する利点の一つは、バックアップが簡単になることです。数多くのシステムにメールを分散すると、バックアップが難しくなります。 1 つのサーバーに多くのメールボックスを格納する際の欠点は、そのサーバーの故障が多くのユーザーに影響することですが、バックアップの簡便さは、この危険性を補って余りあります。

メールクライアント

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

メールクライアントには、/etc/vfstab ファイルに適切なエントリがあり、メールサーバーからメールボックスをマウントするマウント先があることを確認する必要があります。またクライアントの別名の宛先が、クライアントではなく、メールサーバーのホスト名になっていることを確認してください。

メールゲートウェイ

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

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

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

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

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

インターネットに接続できるマシンがある場合は、そのマシンをメールゲートウェイとして構成できます。メールゲートウェイを構成するときは、まずサイトのセキュリティ要件を慎重に考慮する必要があります。社内ネットワークを外部と接続するには、ファイアウォールゲートウェイを構築し、メールゲートウェイとして設定する必要がある場合があります。