ここでは、メールシステムのソフトウェアの構成要素について説明します。サービスには、メールユーザーエージェント、メール転送エージェント、メール配信エージェントのうちの 1 つ以上の機能があります。それ以外のソフトウェアの構成要素には、ドメイン名、メールアドレス、メールボックス、そしてメールの別名があります。
「メールユーザーエージェント」は、ユーザーと sendmail プログラムなどのメール転送エージェントとの間のインタフェースとして機能します。Solaris オペレーティングシステムに搭載されているメールユーザーエージェントは、/usr/bin/mail、/usr/bin/mailx、$OPENWINHOME/bin/mailtool、および /usr/dt/bin/dtmail です。
「メール転送エージェント」は、メールメッセージのルーティングとメールアドレスの解釈を行います。Solaris ソフトウェアの転送エージェントは sendmail です。転送エージェントは次の機能を実行します。
メールユーザーエージェントからメッセージを受信する
宛先アドレスを認識する
適切な配信エージェントを選択してメールを配信する
他のメール配信エージェントからのメールを受信する
「メール配信エージェント」は、メールの配信プロトコルを実行するプログラムです。Solaris オペレーティング環境に搭載されているメール配信エージェントについては以下に述べます。
UUCP メール配信エージェントは uux を使用してメールを配信します。
ローカルメール配信エージェントは mail.local を使用してメールを配信します。
「メールプログラム」は sendmail 独自の用語です。メール配信エージェントはカスタマイズできます。メールプログラムは sendmail によって使用され、カスタマイズしたメール配信エージェントまたはメール転送エージェントの特定のインスタンスを指定します。
ネットワークのすべてのシステムの sendmail.cf ファイルには、少なくても 1 つのメールプログラムを指定する必要があります。
ether メールプログラムは 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 を使用してください。
smartuucp メールプログラムはメッセージの配信に uux を使用しますが、ヘッダーをドメイン形式のアドレスでフォーマットします。To: 行と Cc: 行は SMTP ヘッダーとほぼ同様にドメインによってフォーマットされます。smartuucp ヘッダーは次のようになります。
To: paul@phoenix.stateu.com From: ignatz@eng.acme.com |
ドメイン形式の名前を処理し、理解できるシステムへの UUCP メールには smartuucp を使用してください。また、発信者はドメイン形式の名前を処理し、インターネットからの返信を受信できるようにしておく必要があります。
uucp メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。これはオリジナルのメールプログラムの 1 つであり、ヘッダーは次のようになります。
To: edu!stateu!phoenix!paul From: acme!ignatz |
sendmail.cf ファイルにメールプログラム仕様を提供して、他のメール配信エージェントを定義できます。
「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。電子メールのアドレスにもドメインが使われています。電子メールのアドレスは、次のようなフォーマットになっています。
user@subdomain. ... .subdomain2.subdomain1.top-level-domain |
アドレスの @ 記号より左の部分はローカルアドレスです。ローカルアドレスには次の情報が含まれます。
別のメールトランスポートを使用するルーティング (たとえば、bob::vmsvax@gateway または smallberries%mill.uucp@gateway )
別名 (たとえば、iggy.ignatz )
受信側のメールプログラムでアドレスのローカル部分を解釈する必要があります。
アドレスの @ 記号より右の部分は、ローカルアドレスが位置するドメインアドレスを示します。ドットはドメインアドレスの各部分を区切ります。ドメインは、組織、物理的なエリア、地理的な領域などを表します。古い形態においては、ドメインは 1 つまたは複数のコンピュータシステムを表すことができます。
ドメインアドレスは大文字と小文字を区別しません。アドレスのドメイン部分で大文字、小文字、またはそれらを混用しても、相違はありません。
ドメイン情報の順序は階層的です。つまり、アドレスがローカルであるほど @ 記号に近づきます。
サブドメインの数が多いほど、宛先に関して提供される情報が詳細になります。ファイルシステム階層におけるサブディレクトリがその上のディレクトリの中にあると解釈されるのと同様に、メールアドレス内の各サブドメインは、その右にあるドメインの中にあると解釈されます。
表 1-1 に米国における最上位のドメインを示します。
表 1-1 米国の最上位のドメイン
ドメイン |
説明 |
---|---|
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 となります。
メールドメインアドレスは大文字と小文字の区別をしませんが、名前空間のドメイン名は異なります。メールと名前空間のドメイン名を設定するときは、小文字を使うのが最善です。
このメールドメイン名の決定に関するデフォルトの規則により、ネットワークドメイン名が持つことのできる構成要素の数が制約されますが、sendmail.cf ファイルでメールドメイン名を定義できます。D マクロ定義または L マクロ定義のいずれかを使って m 変数 (メールドメイン名) を設定できます。前者は単純な割り当てであり、後者はネームサービスによって管理されるルックアップテーブル (sendmailvars) を使用します。ルックアップテーブルの長所は、各クライアントの sendmail.cf ファイルを編集することなく、メールドメイン名を容易に変更できることです。
「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。
ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。
ただし、複数のメールボックスと、複数のドメインを持つ複数のメールシステムを管理する場合、または外部に UUCP (またはその他の) メール接続がある場合は、メールアドレス指定はもっと複雑になります。メールアドレスには「経路依存型」と「経路非依存型」があり、2 つの混用も可能です。
経路依存のアドレス指定では、電子メールメッセージの発信者が、ローカルアドレス (通常はユーザー名) とその最終の宛先、および最終の宛先に到達するためにメッセージが通らなければならない経路を指定する必要があります。経路依存のアドレスは、UUCP ネットワーク上では一般的に使用され、フォーマットは次のとおりです。
path!host!user |
電子メールアドレスの一部に感嘆符がある場合は、常に経路のすべて (またはその一部) が発信者によって指定されています。経路依存のアドレスは常に左から右に読みます。
例として、次のような電子メールアドレスを示します。
venus!acme!sierra!ignatz |
これは、ignatz というユーザーに送信されたメールは、venus というシステムにまず送られ、それに引き続いて、acme、sierra に転送されることを示しています (これはあくまでも実在する経路ではないので注意してください)。 4 つのメールハンドラのいずれかが機能しないときは、メッセージは遅れるか、配信できないとして戻されます。
経路に依存しないアドレス指定では、電子メールメッセージの発信者は、受信者の名前と最終の宛先アドレスを指定する必要があります。経路に依存しないアドレスは通常インターネットのような高速ネットワークで使用されます。さらに、新しい UUCP 接続はドメイン形式の名前を頻繁に使用します。経路に依存しないアドレスは次のようなフォーマットになります。
user@host.domain |
コンピュータのドメイン階層命名方式が普及したため、経路に依存しないアドレスがより一般的になってきました。実際、以下に示すように、最も一般的な経路に依存しないアドレスはホスト名を省略し、電子メールメッセージの最終宛先の識別をドメインネームサービスにまかせています。
user@domain |
ルートに依存しないアドレスでは、まず @ 記号を検索し、ドメイン階層を右 (最上位) から左 (@ 記号の右側にある最も固有なアドレス) へと読み取ります。
「メールボックス」は、電子メールメッセージの最終宛先であるメールサーバー内のファイルです。メールボックスの名前は、ユーザー名、またはポストマスタ (郵便局長) のような特定の職務を持つ人にメールを届ける場所の名前でもかまいません。メールボックスは、ユーザーのローカルシステムかリモートのメールサーバーのいずれかの /var/mail/username ファイルにあります。ただし、いずれの場合でも、メールボックスはメールが配信されるシステム上にあります。
ユーザーエージェントがメールスプールからメールを取り出し、ローカルメールボックスに容易に格納できるように、メールは常にローカルファイルシステムに配信される必要があります。ユーザーのメールボックスの宛先として、NFS でマウントしたファイルシステムを使用しないでください。特にリモートサーバーから /var/mail ファイルシステムをマウントしているメールクライアントには、直接メールを送信しないでください。この場合ユーザー宛のメールは、クライアントのホスト名ではなく、メールサーバーにアドレス指定する必要があります。 NFS でマウントしたファイルシステムは、メールの配信と処理に問題を起こすことがあります。/var/mail を NFS でマウントしたクライアントは「リモートモード」となり、サーバーにメールの送信と受信を行うように要求を出します。
/etc/mail/aliases ファイルと NIS や NIS+ といったネームサービスは、電子メールのアドレスに別名を作成するメカニズムを持っているため、ユーザーは、ユーザーのメールボックスの正確なローカル名を知る必要はありません。
表 1-2 に、特殊な目的のメールボックスに対する共通の命名規則をいくつか示します。
表 1-2 メールボックス名のフォーマットについての規則
別名 (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 とします。
メールがユーザーのドメイン外に送信されるとき、電子メールアドレスを完全指定ドメイン名に変換するために、sendmail.cf ファイルを設定できます。
NIS+ mail_aliases テーブル、NIS aliases マップ、または、ローカルの /etc/mail/aliases ファイルでグローバルに使用するメール別名を作成します。また、同じ別名ファイルを使ってメールリストを作成して管理することが可能です。
メールサービスの構成に応じて、NIS または NIS+ ネームサービスを使って別名を管理し、グローバル aliases データベースを維持したり、ローカルの /etc/mail/aliases ファイルをすべて同時に更新することにより、別名を同一にできます。
また、ユーザー自身が別名を作成して使用できます。ユーザーは、別名をユーザーだけが使用できるようにローカル ‾/.mailrc ファイルで作成することも、誰でも使用できるようにローカル /etc/mail/aliases ファイルで作成することもできます。ユーザーは通常は、NIS または NIS+ 別名ファイルを作成したり管理したりはできません。