第 1 章 メールサービスについて

電子メールサービスの設定と維持管理は複雑な作業であり、ネットワークの日常の運用にとっても不可欠です。ネットワーク管理者は、既存のメールサービスを拡張したり、新規のネットワークやサブネットワークにメールサービスを設定することが必要なこともあります。ネットワークでのメールサービスの計画に役立つように、この章ではメールサービスの概念について説明し、典型的なメール構成の設定に必要な作業を手短かに述べます。

• 「メールサービスの関連用語」

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

• 「メールサービスのプログラムとファイル」

• 「メールアドレス指定の動作」

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

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

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

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

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

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

• メール転送エージェント

• メール配信エージェント

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

「メールユーザーエージェント」は、ユーザーと 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 )

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

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

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

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

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

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

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+ といったネームサービスは、電子メールのアドレスに別名を作成するメカニズムを持っているため、ユーザーは、ユーザーのメールボックスの正確なローカル名を知る必要はありません。

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

バージョン 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 番目の要素であるメールゲートウェイを追加する必要があります。

図 1-1 には、一般的な電子メール構成を示しますが、ここでは基本的な 3 つのメール要素とメールゲートウェイが使用されています。以下の節では、各要素が何であるかを示してその説明を行います。

図 1-1 一般的な電子メール構成

メールホスト

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

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

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

メールサーバー

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

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

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

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

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

メールクライアント

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

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

メールゲートウェイ

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

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

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

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

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

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

メールサービスのプログラムとファイル

メールサービスには、相互に対応する数多くのプログラムやデーモンが含まれています。この節では、電子メールの管理に関するプログラムや用語、あるいは概念について述べます。表 1-3 には、メールサービスに使用する /usr/bin ディレクトリの内容を示します。

表 1-4 に、/etc/mail ディレクトリの内容を示します。

表 1-5 にメールサービスに使用する /usr/lib ディレクトリの内容を示します。

/usr/lib ディレクトリ内は、sendmail.cf ファイルの構築に必要なファイルをすべて含むサブディレクトリです。このディレクトリの内容は、表 1-6 に示すとおりです。

メールサービスは、その他のいくつかのファイルおよびディレクトリを使用します。これらを 表 1-7 に示します。

これらのプログラムの組合せによるメールサービスが提供されていますが、その相互作用を図 1-3 に簡略に示します。

図 1-3 メールプログラムの相互作用

ユーザーは、mailx や mailtool などのプログラムを使用してメッセージを送信します。これらのプログラムの詳細については、mailx(1) または mailtool(1) のマニュアルページを参照してください。

メッセージは、メッセージを生成するのに使用されたプログラムにより収集され、sendmail デーモンに渡されます。sendmail デーモンは、メッセージのアドレスを「解釈」し (識別可能なセグメントに分割)、構成ファイル /etc/mail/sendmail.cf からの情報を使用して、ネットワークの名前構文、別名、転送情報、およびネットワークトポロジを決定します。sendmail はこの情報を使用して、メッセージが受信者に到達する経路を決定します。

sendmail デーモンはメッセージを適切なシステムに渡します。ローカルシステムの /usr/lib/mail.local プログラムは、メッセージの受信者の /var/mail/username ディレクトリのメールボックスにメールを配信します。

受信者は、メールが届いたことが通知されるので、mail、mailx、mailtool などのプログラムを使用してこれを受け取ります。

sendmail プログラム

sendmail プログラムは、TCP/IP や UUCP などの異なる通信プロトコルを使用できます。また SMTP サーバー、メッセージキュー、メーリングリストも実装します。名前の解釈は、ドメインベースのネーミングとその環境で指定されている規則の両方を処理できるパターンマッチングシステムで制御されます。

sendmail プログラムは、ドメインベースのネーミングと任意の (古い) 名前構文を受け入れて、指定されている補完方法を使用して曖昧さを解決します。sendmail は共通点のないネーミングスキーム間でメッセージを変換することもできます。ドメインの手法は、物理的なネーミング対論理的なネーミングの問題を分離します。インターネットドメインのネーミングの規則の詳細は、『TCP/IP とデータ通信』を参照してください。

他のネットワーク上のホストに対してローカルのように見えるネットワーク名を提供するなど、その環境で指定されている技法によって特殊な場合を処理できます。

Solaris オペレーティング環境では、sendmail プログラムをメールルーターとして使用します。sendmail は、電子メールメッセージの受信と配信を担当します。これは、mail、mailx、mailtool といったメール読み取りプログラムと、uucp のようなメールトランスポートプログラムの間のインタフェースです。sendmail プログラムは、ユーザーが送った電子メールメッセージを制御し、受信者のアドレスを判断し、適切な配信プログラムを選び、配信エージェントが処理できるフォーマットにアドレスを書き直し、必要に応じてメールヘッダーをフォーマットし直し、最後に変換したメッセージを配信のためのメールプログラムに渡します。

Solaris 2.4 以前の旧リリース版には、sendmail.mx と呼ばれるバイナリが含まれていました。現在このプログラムは sendmail プログラムに含まれており、これを有効にするには、/etc/nsswitch.conf のホストエントリに dns フラグを追加します。詳細は、「DNS を設定して sendmail で作業する方法」 を参照してください。

sendmail プログラムでは、メールルーティングに必要な 3 つのメカニズムをサポートしています。どのメカニズムを選択するかは、サーバーまたはドメイン全体の変更なのか、または単に 1 人のユーザーの変更であるかによって決まります。また、異なる再ルーティングメカニズムを選択することにより、必要な管理レベルに変更できます。

1 つめの再ルーティングメカニズムはエイリアシングです。エイリアシングとは、使用するファイルのタイプに基づいて、サーバー全体、または名前空間全域ごとに名前をアドレスに対応させるメカニズムです。名前空間の別名ファイルを使用すると、メール再ルーティングの変更を単一のソースで管理できますが、この変更が伝達されるときに、遅延時間が発生する可能性があります。また、名前空間管理は、通常、システム管理者の選択グループに限定されるため、一般ユーザーが実行できる変更ではありません。サーバーの別名ファイルを通じて処理された再ルーティングは、そのサーバーのスーパーユーザーによって管理されます。通常、この変更の伝達に関連した遅延時間はほとんどみられませんが、この変更はローカルサーバーにしか反映されません。この制約事項は、メールのほとんどが 1 つのサーバーに送信される場合には問題ありませんが、この変更を多数のメールサーバーに配信する場合には、ネームサービスを使用した方が簡単です。これも一般ユーザーが実行できる変更ではありません。

次のメカニズムは、転送と取り込みです。このメカニズムを使用すると、ユーザーはメールの再ルーティングを実行できます。転送を使用すると、ローカルユーザーは、着信メールを他のメールボックス、別のメールプログラム、あるいは他のメールホストにルーティングし直すことができます。このメール再ルーティングの形式は、.forward ファイルを使用することによりサポートされます。これらのファイルの詳細は、「.forward ファイル」を参照してください。

最後の再ルーティングメカニズムは取り込みで、これを使用すると、別名リストを、ルートアクセスを要求する代わりに、ユーザーによって保守できます。このメカニズムを提供するには、スーパーユーザーは、サーバー上の別名ファイル内に適切なエントリを作成する必要があります。このエントリが作成されると、ユーザーは必要に応じてメールをルーティングし直すことができるようになります。取り込みの詳細は、「/etc/mail/aliases」を参照してください。

図 1-4 は、sendmail がユーザー別名をどのように使用するかを示します。/usr/bin/mailx のようなメールを読み取るプログラムは、プログラム自身の別名を持つことができ、それらはメッセージが sendmail に達する前に展開されます。sendmail の別名は、多くの名前空間ソース (ローカルファイル、NIS、NIS+) からのものでも構いません。検索順序は nsswitch.conf ファイルによって決定されます。nsswitch.conf(4) のマニュアルページを参照してください。

図 1-4 sendmail が別名を使用する方法

sendmail プログラムの機能

sendmail プログラムには、次のような機能があります。

• sendmail には高い信頼性があります。すべてのメッセージを正しく配信するように設計されています。どんなメッセージも完全に失われることはありません。

• sendmail は、既存のソフトウェアを配信に随時使用します。

• sendmail は、1 つのネットワークタイプ (UUCP や Ethernet など) に複数の接続を行う場合なども含め、複雑な環境を処理するように構成できます。sendmail は、名前とその構文をチェックし、どのメールプログラムを使用するかを判断します。

• 構成情報をコードにコンパイルする代わりに、構成ファイルを使用してメール構成を制御します。

• ユーザーは独自のメーリングリストを管理できます。各ユーザーは、ドメイン全体で有効な別名ファイル (通常、NIS または NIS+ によって管理されるドメイン全体の別名の中にある) を修正することなく自分自身のメール転送を指定できます。

• 各ユーザーはカスタムメールプログラムを指定して着信メールを処理することができます。こうすると、たとえば、「I am on vacation」というメッセージを返すといった機能を設定できます。 vacation(1) のマニュアルページを参照してください。

• 1 つのホストでアドレスを処理し、ネットワークトラフィックを削減します。

図 1-5 には、sendmail がメールシステムで他のプログラムと対話する方法を示します。

図 1-5 sendmail と他のメールプログラムとの対話

ユーザーは、メール生成プログラムおよび送信プログラムと対話します。メール送信が依頼されると、メール生成プログラムは sendmail を呼び出し、sendmail は適切なメールプログラムにメッセージを送ります。発信者の一部はネットワークサーバーであったり、またメールプログラムの一部はネットワーククライアントであるため、sendmail は、インターネットメールゲートウェイとしても使用できます。

sendmail 構成ファイル

「構成ファイル」は、sendmail がその機能を実行する方法を制御します。構成ファイルにより、配信エージェント、アドレスの変換の規則、およびメールヘッダーのフォーマットが選択されます。

sendmail プログラムは、/etc/mail/sendmail.cf ファイルの情報を使用して、その機能を実行します。各システムには、/etc/mail ディレクトリにインストールされたデフォルトの sendmail.cf ファイルがあります。メールサーバーまたはメールクライアントのためにデフォルト構成ファイルを編集したり変更したりする必要はありません。カスタマイズされた構成ファイルを必要とするシステムは、メールホストとメールゲートウェイだけです。

Solaris オペレーティング環境には、以下に示すように、/etc/mail ディレクトリに 2 つのデフォルト構成ファイルがあります。

1. メールホストまたはメールゲートウェイとして使用する 1 つのシステム (または複数のシステム) を指定するための main.cf という名前の構成ファイル

2. subsidiary.cf という名前の構成ファイル (デフォルト sendmail.cf ファイルの複製コピー)

システムで使用する構成ファイルは、システムがメールサービスで果たす役割によって異なります。

• メールクライアントまたはメールサーバーについては、デフォルト構成ファイルを設定または編集する必要はありません。

• メールホストやゲートウェイを設定するには、main.cf ファイルをコピーし、それを (/etc/mail ディレクトリで) sendmail.cf と名称変更します。次に、sendmail.cf ファイルを再構成して、リレーメールプログラムを設定して、メール設定に必要なホストパラメータをリレーします。

次に、サイトの要求に応じて変更が可能な構成パラメータをいくつか説明します。

• 時間値の指定

  • 読み取りのタイムアウトを指定します。

  • メッセージが待ち行列内にあり送信者に戻されるまでの未配信状態の時間を指定します。

• 配信 (delivery) モードは、メールが配信される速さを指定します。

• 長いメッセージ、多くの受信者へのメッセージ、および長時間ダウンしているサイトへのメッセージを配信しないことにより、ロードを制限してロード時間内の無駄を省きます。

• ログレベルは、どのような種類の問題をログするかを指定します。