第 3 章 sendmail のリファレンス

sendmail プログラムは、構成ファイルを使用して「別名」変換と転送、ネットワークゲートウェイへの自動ルーティング、柔軟な構成を提供するメール転送エージェントです。Solaris オペレーティング環境では、ほとんどのサイトで使用できる標準構成ファイルが付属しています。第 2 章「メールサービスの設定と管理」では、標準のファイルを使用して電子メールシステムを設定する方法について説明しています。この章では、sendmail の汎用バージョンと Solaris バージョンのいくつかの相違点について説明します。

• 「sendmail の新しい機能」

• 「Solaris sendmail の相違点」

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

• 「sendmail とネームサービスとの相互作用」

• 「この他のメール関連のトピック」

sendmail の新しい機能

sendmail のバージョン 8.9 は、Solaris 7 リリースに組み込まれています。ここでは、この新しいバージョンに組み込まれた重要でユーザーが管理できる変更を挙げています。

• 構成ファイル作成のための新しいシステム。この新しいシステムの使用方法の説明は、「sendmail 構成ファイルの構築」に記載されています。

• いくつかのディレクトリのアクセス権と所有権が、セキュリティを向上させる目的で変更されています。Solaris 7 リリースをインストールすると、/etc/mail と /var/spool/mqueue およびその親ディレクトリのアクセス権が適切に変更されます。

• .forward ファイルのセキュリティを向上させるために、ファイルにアクセスするためには.forward ファイルを使用しようとしたすべてのユーザーのデフォルトのシェル ( /etc/passwd 内にリストされたもの) が、/etc/shells 内にリストされている必要があります。詳細については、「/etc/shells の作成および生成方法」を参照してください。

• .forward ファイルと :include: ファイルには、制約事項が追加されました。これらのファイルとファイルが置かれているディレクトリは、グループの書き込み権、または全ユーザーの書き込みは権はありません。セキュリティ上問題のあるアクセス権のあるファイルを識別するために、/usr/lib/mail/sh/check-permissions というスクリプトが組み込まれています。

• .forward ファイルの使用が拡張されました。.forward.hostname ファイルを使用して、特定のホストのユーザーに送信されたメールをルーティングし直すことができます。また、.forward+detail ファイルを使用すると、別名を使用している人を判別できます。これらのファイルについては、「.forward ファイル」で説明しています。

• 所有者の別名が存在する場合、sendmail の動作は変更されます。この変更については、「メールボックス」を参照してください。誤って構成された所有者別名がないかどうか /etc/mail/sendmail.cf 内にリストされた別名ファイルをすべて確認する check-aliases.sh というスクリプトをダウンロードできます。

• sendmail プログラムは、その起動時に完全指定ホスト名が必要です。このリリースに付属している /usr/lib/mail/sh/check-hostname というスクリプトでは、完全指定のホスト名をサポートしていないホスト構成を識別します。

sendmail の Solaris バージョンに関する追加情報は

http://www.sendmail.org/sun-specific/migration+sun.html

に記載しています。

新しい構成ファイル

メールシステムをカスタマイズするには、sendmail を再構成する必要があります。これ以前の Solaris リリースには、多数の隠しオプションが組み込まれた大容量のファイルが入っていました。これらのオプションは、手動で編集し、sendmail を機能させる方法を変更する必要がありました。Solaris 7 リリースでは、m4 を使用して構成ファイルを作成する新しい構成システムが組み込まれました (m4(1) マニュアルページを参照)。

sendmail コマンド行オプションに対する変更内容

以下の表は、Solaris 7 の新しいオプションです。これらのオプションについては、Bryan Costales 著の『sendmail, Second Edition』を参照してください。

sendmail 構成ファイルオプションの変更内容

以下の表は、Solaris 7 の新しい構成オプションです。これらのオプションは、その複数文字の名前によって格納されます。オプションに単一文字の名前しか付いていない場合は、その名前は括弧に入れて表示されます。2.6 でサポートされていた単一文字オプションのほとんどは、Solaris 7 でもサポートされています。これらのオプションについては、Bryan Costales 著の『sendmail, Second Edition』を参照してください。

Solaris sendmail の相違点

この節では、sendmail の Solaris バージョンに組み込まれたいくつかの変更について、汎用 Berkeley バージョンと比較して説明します。

sendmail のコンパイル時に使用するフラグ

以下には、Solaris 7 に添付されている sendmail のバージョンをコンパイルするときに使用するフラグを示しています。構成に他のフラグが必要な場合は、そのソースをダウンロードし、バイナリにコンパイルし直してください。この処理については、http://www.sendmail.org に記載してあります。

• SOLARIS=20700 - Solaris 7 オペレーティング環境をサポートする

• NDBM - ndbm データベースをサポートする

• NEWDB - db データベースをサポートする

• NIS - nis データベースをサポートする

• NISPLUS - nisplus データベースをサポートする

• USERDB - ユーザーデータベースをサポートする

• MAP_REGEX - 正規表現のマップをサポートする

• SUN_EXTENSIONS - Solaris 固有のフラグで、sun_compat.o に組み込まれる Sun 固有の拡張子

• VENDOR_DEFAULT=VENDOR_SUN - Solaris 固有のフラグで、Sun をデフォルトのベンダーとして選択する

• USE_VENDOR_CF_PATH - Solaris 固有のフラグで、このフラグを使用すると構成ファイルを /etc/mail 内に配置できる

• _FFR_MAXALIASRECURSION_OPTION - Solaris 固有のフラグで、このフラグを使用すると MaxAliasRecursion オプションを選択できる

sendmail の代替コマンド

Solaris リリースには、Berkley による汎用リリースで提供されているコマンドの同義語がすべて組み込まれているわけではありません。この表には、コマンドの別名のリストと それが Solaris リリースに組み込まれているかどうか、および sendmail を使用して同じ動作を生成する方法を示しています。

構成ファイルのバージョンの定義

sendmail の新版 (バージョン 8) には、sendmail.cf ファイルのバージョンを定義するための、新しい構成オプションがあります。このオプションを使用すれば、旧バージョンの構成ファイルをバージョン 8 の sendmail で使用できます。バージョンレベルには 0 から 8 の値を設定できます。また、ベンダーの定義もできます。Berkeley または Sun がベンダーとして選択できます。構成ファイルで V オプションが定義されていない場合は、V1/Sun がデフォルトの設定となります。ベンダーを定義せずに、バージョンレベルだけが設定されている場合は、Sun がデフォルトとして使われます。表 3-4 に有効なオプションを示します。

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

配信時にメールメッセージが辿る経路は、クライアントシステムの設定とメールドメインのトポロジによって異なります。メールホストやメールドメインの各追加レベルでは、別名の解釈をさらに 1 回追加できますが、ルーティングプロセスは基本的にほとんどのホストで同じになります。

クライアントシステムを設定してメールをローカルで受信したり、リモートでクライアントシステムのためのメールを受信したりできます。メールをローカルで受信することは、ローカルモードでの sendmail の実行として知られています。すべてのメールサーバーと一部のクライアントでは、ローカルがデフォルトモードです。クライアントがサーバーから /var/mail をマウントしている場合、クライアントはリモートモードで sendmail を実行します。

sendmail.cf ファイルで設定したデフォルト規則を使用している場合の、電子メールメッセージが辿る経路を以下に示します。

リモートモードのメールクライアントでは、メールメッセージは以下のルーティングプロセスを経由して送信されます。

1. 可能な場合メール別名を展開し、ローカルのルーティングプロセスを再起動します。

   /etc/nsswitch.conf のエントリに応じて、名前空間でメール別名を検索し、新しい値が見つかった場合に置換することで、メールアドレスが展開されます。この新しい別名が次に再度チェックされます。

2. アドレスを展開できない場合、メールサーバーに転送します。

   メールアドレスを展開できない場合、アドレスに問題があるか、アドレスがローカルでない可能性があります。どちらの場合も、メールサーバーで問題を解決する必要があります。

3. 展開した別名が元の宛先にループバックすると、メールはメールサーバーに転送されます。

   このプロセスでは検索のすべての履歴が維持され、元の別名が再生成されると、メールはメールサーバーに転送されて解釈が行われます。

ローカルモードのメールサーバーやメールクライアント上で、メールメッセージは以下のルーティングプロセスを経由して送信されます。

1. 可能な場合はメール別名を展開し、ローカルのルーティングプロセスを再起動します。

   名前空間でメール別名を検索し、見つかった場合に新しい値と置換することで、メールアドレスが展開されます。次にこの新しい別名が再度チェックされます。

2. メールがローカルの場合、/usr/lib/mail.local に配信されます。

   メールはローカルのメールボックスに配信されます。

3. メールアドレスがこのメールドメインにホストを含んでいると、そのホストにメールを配信します。

4. アドレスがこのドメインにホストを含んでいない場合、メールホストにメールを転送します。

   メールホストはメールサーバーと同じルーティングプロセスを使用しますが、メールホストはホスト名に加え、ドメイン名が宛先になっているメールも受信できます。

sendmail とネームサービスとの相互作用

「メールドメイン」は、標準の sendmail.cf ファイルによって使用される概念で、メールを直接配信するか、またはメールホストによって配信するかを判断します。ドメイン内メールは直接 SMTP 接続経由で配信され、ドメイン間メールはメールホストに送られます。

セキュリティの高いネットワークでは、ほんの少数の選ばれたホストだけが、外部宛てのパケットを生成する権限を与えられています。ホストがメールドメイン外のリモートホストの IP アドレスを持っていても、これで SMTP 接続が確立できるとは限りません。標準の sendmail.cf では次のことを仮定しています。

• 現在のホストは、パケットを直接メールドメイン外のホストに送信する権限がない

• メールホストは、パケットを直接外部ホストに送信することが可能な認定ホストにメールを転送できる (実際には、メールホスト自身が認定ホストとなりうる)

このように仮定すると、ドメイン間メールの配信または転送はメールホスト側の責任です。

ネームサービスに対する sendmail 要件を設定する方法

sendmail は各種の要件をネームサービスに課します。次の節で、これらの要件とその要件を満たす方法を説明します。詳細は、in.named(1M)、nis+(1)、nisaddent(1M)、および nsswitch.conf(4) のマニュアルページを参照してください。

ネームサービスによるメールドメイン名の設定

メールドメイン名はネームサービスドメイン名の接尾辞の１つでなければなりません。たとえば、ネームサービスのドメイン名が「A.B.C.D」ならば、メールドメイン名は次のうちのいずれかであるはずです。

• A.B.C.D

• B.C.D

• C.D

• D

メールドメイン名は、最初に設定されたときには、多くの場合ネームサービスドメインと同じになります。ネットワークが大きくなれば、ネームサービスドメインを小さく分割してネームサービスを管理しやすくすることができます。ただし、メールドメインは、一貫した別名を提供するために分割されないまま残ることがあります。

ホスト名前空間データ

ネームサービスにおけるホストテーブルまたはマップは、次の 3 種類の gethostbyname() による問い合わせをサポートするように設定しなければなりません。

• mailhost

  いくつかのネームサービスの構成では、自動的にこの要件を満たします。

• 完全なホスト名 (たとえば、smith.admin.acme.com)

  多くのネームサービスの構成がこの要件を満たします。

• 短いホスト名 (たとえば、smith)

  sendmail はメールホストに接続し外部へのメールを転送します。メールアドレスが現在のメールドメイン内であるかどうかを判定するために、gethostbyname() が完全なホスト名で呼び出されます。エントリが見つかると、アドレスは内部にあるとみなされます。

  NIS、NIS+、および DNS はすべて、短いホスト名を引数にする gethostbyname() をサポートします。したがって、この要件は自動的に満たされます。

名前空間内で sendmail サービスを適切に確立するには、さらにホスト名空間に関する以下の 2 つのルールに従う必要があります。

1. 完全なホスト名による gethostbyname() と短いホスト名による gethostbyname() で、一致した結果を生じるようにします。たとえば、両関数がメールドメイン admin.acme.com. から呼び出される限り、gethostbyname (smith.admin.acme.com) と gethostbyname (smith) は同じ結果になるようにします。

2. 共通のメールドメイン下のすべてのネームサービスドメインに対しては、短いホスト名による gethostbyname() で同じ結果を生じるようにします。たとえば、メールドメイン smith.admin.acme.com があるとして、gethostbyname(smith) は、ebb.admin.acme.com または esg.admin.acme.com のいずれのドメインから呼び出されても同じ結果になるようにします。主なメールドメイン名は通常ネームサービスドメインより短く、このために各種ネームサービスにとって特別な意味のあるものになっています。

NIS と sendmail を使用する場合の設定の問題点

ネームサービスとして NIS だけを使用するときは、sendmail 使用時に事前に解決しておかなければならない設定項目を以下に示します。

• メールドメイン名 - NIS をプライマリネームサービスとして設定している場合に、sendmail は、自動的に NIS ドメイン名の最初の構成要素を取り除いた結果をメールドメイン名として使用します。たとえば、ebs.admin.acme.com は、admin.acme.com となります。

• mailhost ホスト名 - NIS のホストマップには、mailhost エントリが必要になります。

• 完全なホスト名 - 通常の NIS の設定では、完全なホスト名は、認識されません。NIS に完全なホスト名を認識させようとするよりは、sendmail.cf ファイルを編集し %l を %y で置き換えて、sendmail 側からこの要件をなくしてください。こうすることによって、sendmail のドメイン間のメール検出機能をオフにできます。ターゲットとするホストの IP アドレスを取得できれば、SMTP による直接配信が試みられます。NIS のホストマップに現在のメールドメインの外部のホストのエントリが含まれていないことを確認してください。もし、それがあれば、さらに sendmail.cf ファイルをカスタマイズする必要があります。

• ホストの完全名および短縮名のマッチング - 前述した手順を参考にして、完全なホスト名による gethostbyname() をオフにしてください。

• 1 つのメールドメイン内の複数の NIS ドメイン - 共通のメールドメインの NIS のホストマップは、ホストのエントリは同じである必要があります。たとえば、ebs.admin.acme.com ドメインのホストマップは、esg.admin.acme.com のホストマップと同じものにします。異なる場合には、ある NIS ドメインで有効なアドレスが他の NISドメインでは無効になることがあります。

sendmail と同時に NIS と DNS を使用する場合の設定の問題

ネームサービスとして NIS と DNS を同時に使用する場合に、sendmail を使用する前に解決しておかなければならない設定上の問題を以下に示します。

• メールドメイン名 - NIS をプライマリネームサービスとして設定している場合には、sendmail は、自動的に NIS ドメイン名の最初の構成要素を取り除いた結果をメールドメイン名として使用します。たとえば、ebs.admin.acme.com は、admin.acme.com となります。

• mailhost ホスト名 -DNS の転送機能がオンになっていれば、NIS で解決できない照会は DNS に転送されるため、NIS ホストマップに mailhost エントリは必要ありません。

• 完全なホスト名 - NIS が完全なホスト名を認識できなくても、DNS がそれを行います。NIS と DNS の通常の設定手順を踏んでいる場合には、完全なホスト名の要件は満たされます。

• ホストの完全名および短縮名のマッチング - NIS のホストテーブルにおけるすべてのホストエントリに対して、DNS にも対応するホストエントリが必要です。

• 1 つのメールドメイン内の複数の NIS ドメイン - 共通のメールドメインの NIS のホストマップ中のホストのエントリは同じである必要があります。たとえば、ebs.admin.acme.com ドメインのホストマップは、esg.admin.acme.com のホストマップと同じものにします。異なる場合には、ある NIS ドメインで有効なアドレスが他の NIS ドメインでは無効になることがあります。

NIS+ と sendmail を使用する場合の設定の問題点

使用するネームサービスが NIS+ だけの場合、sendmail を使用する前に解決しておかなければならない設定上の問題点を以下に記します。

• メールドメイン名 - プライマリネームサービスとして、NIS+ を設定していれば、sendmail は、NIS+ の sendmailvars テーブル (キーと値から構成される 2 列の NIS+ テーブル) からメールドメインを検索します。メールドメインを設定するには、エントリを 1 つこのテーブルに追加する必要があります。このエントリは、キーの列に文字列 maildomain が、値の列には自分のドメイン名 (たとえば、admin.acme.com) が設定されている必要があります。NIS+ では、sendmailvars テーブルにどのような文字列でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomail エントリを sendmailvars テーブルに追加できます。たとえば、次のようになります。

  nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

  ここで、メールドメインは NIS+ ドメインの接尾辞となることに注意してください。

• mailhost ホスト名 - NIS+ ホスト名には、mailhost エントリが必要です。

• 完全なホスト名 - NIS+ は、完全なホスト名を認識することができます。通常の NIS+ の設定手順を行えば、この完全なホスト名の要件は満たされます。

• ホストの完全名および短縮名のマッチング - この要件を満たすには、すべてのホストテーブルでエントリをコピーするか、ユーザーネームサービスのドメイン中の全ホストのエントリをメールドメインレベルのマスターホストテーブルに入力する必要があります。

• 1 つのメールドメイン内の複数の NIS ドメイン - この項目を満たすには、すべてのホストテーブルのエントリをコピーするか、ユーザーネームサービスのドメイン中の全ホストのエントリをメールドメインレベルのマスターホストテーブルに入力する必要があります。これは、(論理的または物理的に) 複数のホストテーブルを 1 つのホストテーブルに結合することになるので、メールドメインを共有する複数のネームサービスドメインで同じホスト名を再使用することはできません。

sendmail と同時に NIS+ と DNS を使用する場合の設定の問題点

ネームサービスとして NIS+ と DNS を同時に使用する場合に、sendmail 使用前に解決しておかなければならない設定上の問題点を以下に記します。

• メールドメイン名 - プライマリネームサービスとして、NIS+ を設定していれば、sendmail は、NIS+ の sendmailvars テーブル (キーと値から構成される 2 列の NIS+ テーブル) からメールドメインを検索します。メールドメインを設定するには、 1 つのエントリをこのテーブルに追加する必要があります。このエントリは、キーの列に文字列 maildomain が、値の列に自分のドメイン名 (たとえば、admin.acme.com) が設定されている必要があります。NIS+ では、sendmailvars テーブルに、どのような文字でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomail エントリを sendmailvars テーブルに追加できます。たとえば、次のようになります。

  nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

  ここで、メールドメインは NIS+ ドメインの接尾辞となることに注意してください。

• mailhost ホスト名 - ネットワークがホストデータベースのソースとして NIS+ と DNS の両方を使っているときは、mailhost エントリを NIS+ あるいは DNS ホストテーブルのいずれかに置くことができます。NIS+ と DNS をホストデータベースのソースとして /etc/nsswitch.conf ファイルで指定するようにしてください。

• 完全なホスト名 - NIS+ も DNS も完全なホスト名を認識します。通常の NIS+ と DNS の設定手順を踏めば、この項目の要件は満たされます。

• ホストの完全名および短縮名のマッチング - NIS+ ホストテーブルの全ホストエントリに対して、それに対応するエントリが DNS に必要です。

• 1 つのメールドメイン内の複数の NIS ドメイン - この要件を満たすには、全ホストテーブルエントリをコピーするか、ネームサービスのドメイン中の全ホストのエントリをメールドメインレベルのマスターホストテーブルに入力する必要があります。

この他のメール関連のトピック

この節では、Solaris システムで使用できる別名ファイルの様々な形式に関する特定情報と、.forward ファイルについても記載しています。

メール別名ファイル

下記の任意のファイルを使って、別名を管理できます。使用するファイルのタイプは、別名を使用する人と別名を変更する必要がある人によって決まります。別名ファイルのタイプにはそれぞれ固有の形式要件があります。これについては、以下で定義します。

.mailrc の別名

.mailrc ファイルのリストに入っている別名には、ファイルを所有するユーザーだけしかアクセスできません。これにより、ユーザーは自分で制御し、所有者だけが使用できる別名を作成できます。mailrc ファイルの別名は、次のようになります。

alias aliasname value value value ...

ここで aliasname は、ユーザーがメールの送信時に使用する名前であり、value は有効な電子メールアドレスです。

ユーザーが scott に個人的な別名を作成し、それが名前空間の scott の電子メールアドレスと一致しない場合、そのユーザーが作成したメールに他のユーザーが返信しようとするときに、メールが間違ったユーザーに転送されることになります。これを回避するには、別の別名命名方式を使用する以外にありません。

/etc/mail/aliases

/etc/mail/aliases ファイルで作成したいずれの別名も、その別名の名前とファイルを含んでいるシステムのホスト名を知っているユーザーなら誰でも使用できます。ローカルの /etc/mail/aliases ファイルの配布リストは、以下のようになります。

aliasname: value,value,value... 

ここで aliasname は、ユーザーがこの別名にメールを送信するときに使用する名前で、value は有効な電子メールアドレスになります。

/etc/mail/aliases ファイルの別名は、テキスト形式で保存されます。/etc/mail/aliases ファイルを編集するときに、newaliases プログラムを実行してデータベースを再コンパイルし、sendmail プログラムでその別名がバイナリ形式で使用できるようにします。あるいは admintool の Database Manager を使用して、ローカルの /etc ファイルに保存されているメール別名を管理できます。

通常、このファイルを編集できるのはスーパーユーザーだけです。admintool を使用する場合は、sysadmin グループであるグループ 14 のすべてのユーザーが、ローカルファイルを変更できます。別のオプションとしては、以下のようなエントリが作成できます。

aliasname: :include:/path /aliasfile

ここで aliasname は、ユーザーがメールを送信するときに使用する名前であり、/path/aliasfile は別名リストを含むファイルへの完全なパスになります。別名ファイルには、各行に 1 つの電子メールエントリを入れ、その他の表記は付けないでください。

user1@host1
user2@host2

/etc/mail/aliases に追加のメールファイルを定義して、ログやバックアップコピーの管理もできます。以下のエントリでは、filename の aliasname に送信されるすべてのメールを格納します。

aliasname: /home/backup/filename 

また、メールを他のプロセスにルーティングすることもできます。次のように入力すると、メールメッセージのコピーが filename 内に格納され、コピーが出力されます。

aliasname: "|tee -a /home/backup/filename  |lp"

NIS 別名マップ

NIS 別名マップに含まれているエントリは、ローカルドメインのすべてのユーザーが利用できます。sendmail プログラムは、ローカルの /etc/mail/aliases ファイルの代わりに NIS 別名マップを使用して、メールアドレスを決定できます。詳しくは、 nsswitch.conf(4) のマニュアルページを参照してください。

NIS 別名 マップの別名は、以下のようになります。

aliasname: value,value,value... 

ここで aliasname は、ユーザーがメールを送信するときに使用する名前であり、value は有効な電子メールアドレスです。

NIS 別名マップには、すべてのメールクライアント用のエントリを含めてください。一般にこれらのエントリを変更できるのは、NIS マスターのスーパーユーザーだけです。このタイプの別名は、頻繁に変更される別名としては適していないかもしれませんが、次の構文例のように、別名が他の別名ファイルを指している場合は便利です。

aliasname: aliasname@host 

ここで aliasname はユーザーがメールを送信するときに使用する名前であり、host は /etc/mail/alias ファイルを含むサーバー用のホスト名です。

NIS+ mail_aliases テーブル

NIS+ mail_aliases テーブルには名前が含まれていて、それによってローカルドメインにおけるシステムや個人が登録されています。sendmail プログラムは、ローカルの /etc/mail/aliases ファイルの代わりに NIS+ mail_aliases テーブルを使用して、メールアドレスを決定できます。詳しくは、 aliasadm(1M) と nsswitch.conf(4) のマニュアルページを参照してください。

NIS+ mail_aliases テーブルの別名は以下のようになります。

alias: 			expansion					[ options		# " comments"]

表 3-5 に 4 つの列を記載します。

NIS+ mail_aliases テーブルには、すべてのメールクライアントのエントリを含めてください。NIS+ aliases テーブルでは、aliasadm コマンドで、エントリの表示、作成、変更、および削除ができます。あるいは admintool の Database Manager を使用して、NIS+ メール別名を管理できます。

新規の NIS+ 別名テーブルを作成する場合は、エントリを作成する前にテーブルを初期設定する必要があります。テーブルが存在するときは、初期設定は不要です。NIS+ mail_aliases テーブルの作成に関しては、「NIS+ mail_aliases テーブルの個々のエントリを表示する」を参照してください。

aliasadm コマンドを使用するには、別名テーブルを所有する NIS+ グループのメンバーか、テーブルを作成したユーザーでなければなりません。

.forward ファイル

ユーザーは、システム管理者の手を借りることなくプログラムのカスタムセットにメールを一時的にリダイレクトまたは送信するために、ホームディレクトリに、sendmail が使用する .forward ファイルを作成できます。メールの問題、特に所定のアドレスに配信されないメールに関する問題の解決の際、ユーザーのホームディレクトリに .forward ファイルがあるかどうかを常にチェックしてください。

ユーザーによくある間違いは、host1 上のホームディレクトリの .forward ファイルに、user@host2 にメールを転送する設定を入れてしまうことです。メールが host2 に送られると、sendmail は NIS や NIS+ 別名で user を検索し、user@host1 にメッセージを送り返すので、ループが発生し、メールは返送されてしまいます。

root および bin アカウントは、.forward ファイルを所有できません。.forward ファイルを作成すると、セキュリティ上の問題が生じます。必要な場合には、代わりに別名ファイルを使用してメールを転送してください。

メールの配信中に .forward ファイルを調べるためには、このファイルを、ファイルの所有者によってのみ書き込み可能な状態にしておく必要があります。これにより、他のユーザーによるファイルへのアクセスを防ぎます。また、ホームディレクトリのパスは、root だけが所有し、書き込める状態にしておく必要があります。特に、.forward ファイルが /export/home/terry 内にある場合には、/export と /export/home は root だけが所有し、書き込める状態にしておかなければなりません。また実際のホームディレクトリに書き込めるのは、そのユーザーだけである必要があります。.forward ファイルにはこの他にも制約があります。このファイルはシンボリックリンクにすることはできず、また複数のハードリンクも実行できません。

標準の .forward ファイルに加えて、.forward.hostname ファイルを作成し、特定のホストに送信されたメールを転送できます。たとえば、ユーザーの別名を sandy@phoenix.eng.acme.com から sandy@eng.acme.com に変更した場合、sandy のホームディレクトリ内に .forward.phoenix ファイルがあると便利です。

% cat .forward.phoenix
sandy@eng.acme.com
"|/usr/bin/vacation sandy"
% cat .vacation.msg
From: sandy@eng.acme.com (via the vacation program)
Subject: my alias has changed
 
My alias has changed to sandy@eng.acme.com.
Please use this alias in the future.
The mail that I just received from you
has been forwarded to my new address.
 
Sandy 

こうすることにより、メールを適切な場所に転送すると同時に、別名の変更を送信者に通知できます。vacation プログラムではメッセージファイルは 1 つしか使用できないため、この場合 1 回につき 1 つのメーッセージしか実行できないことに注意してください。ただし、メッセージがホスト固有のものではない場合には、1 つの vacation メッセージファイルを、複数のホストの .forward ファイルで使用できます。

転送メカニズムの拡張機能にはこの他に、.forward+detail ファイルがあります。detail は、オペレータ文字以外の文字を自由に並べることができます。オペレータ文字とは、.:%&!^[]+ です。このようなファイルを使用すると、第三者によって自分の電子メールアドレスが使用されたかどうかを判別することが可能になります。たとえば、あるユーザーが、誰かに電子メールアドレス sandy+test1@eng.acme.com を使用するように指示した場合、ユーザーは、この別名に配信されるメールを、アドレスに送信されるメールの中から識別できます。デフォルトにより、sandy+test1@eng.acme.com の別名に送信されたメールはすべて、この別名と .forward+detail ファイルと突き合わせて検査されます。ここで一致しない場合は、そのメールは最終的に sandy@eng.acme.com に配信されますが、ユーザーは、これらのメールの To: ヘッダー内の変更箇所を調べることができます。