sendmail プログラムは、メール転送エージェントです。前の章で説明したように、このプログラムは、構成ファイルを使用して、別名処理、転送、ネットワークゲートウェイへの自動ルーティング、柔軟な構成を提供します。Solaris OS では、ほとんどのサイトで使用できる標準構成ファイルが付属しています。第 12 章メールサービス (概要)では、メールサービスのコンポーネントと典型的なメールサービスの構成を紹介しています。第 13 章メールサービス (手順) では、電子メールシステムをセットアップして管理する方法について説明しています。この章では、次のトピックについて説明します。
上記の章で説明されていない内容については、次のマニュアルページを参照してください。
ここでは、次の項目について sendmail の Solaris 版と一般的な Berkeley バージョンを比較します。
Solaris 10 以降のリリースで sendmail のコンパイルに使用されるフラグは、次のとおりです。構成にほかのフラグが必要な場合は、そのソースをダウンロードし、バイナリにコンパイルし直してください。このプロセスについては、http://www.sendmail.org を参照してください。
表 14–1 一般的な sendmail フラグ
フラグ |
説明 |
---|---|
SOLARIS=21000 |
Solaris 10 のサポート。 |
MILTER |
メールフィルタ API のサポート。sendmail の version 8.13 では、このフラグはデフォルトで有効になっています。「MILTER (sendmail のメールフィルタ API)」を参照してください。 |
NETINET6 |
IPv6 のサポート。このフラグは、conf.h から Makefile に移動されました。 |
表 14–2 マップとデータベースの種類
フラグ |
説明 |
---|---|
NDBM |
ndbm データベースのサポート |
NEWDB |
Berkeley DB データベースのサポート |
USERDB |
ユーザーデータベースのサポート |
NIS |
nis データベースのサポート |
NISPLUS |
nisplus データベースのサポート |
LDAPMAP |
LDAP のマップのサポート |
MAP_REGEX |
正規表現のマップのサポート |
表 14–3 Solaris のフラグ
フラグ |
説明 |
---|---|
SUN_EXTENSIONS |
sun_compat.o に含まれる Sun の拡張をサポートします。 |
SUN_INIT_DOMAIN |
下位互換性を確保するために、NIS ドメイン名をサポートしてローカルホスト名を完全指定します。詳細は、http://www.sendmail.org のベンダー固有の情報を参照してください。 |
SUN_SIMPLIFIED_LDAP |
Sun 固有の簡略化された LDAP API をサポートします。詳細は、http://www.sendmail.org のベンダー固有の情報を参照してください。 |
VENDOR_DEFAULT=VENDOR_SUN |
Sun をデフォルトのベンダーに選択します。 |
次の表に、Solaris 10 に添付されるバージョンの sendmail のコンパイルに使用されない一般的なフラグを示します。
表 14–4 sendmail の Solaris 版に使用されない一般的なフラグ
フラグ |
説明 |
---|---|
SASL |
Simple Authentication and Security Layer (RFC 2554) |
STARTTLS |
Transaction Level Security (RFC 2487) |
sendmail のコンパイルに使用するフラグのリストを参照するには、次のコマンドを使用します。
% /usr/lib/sendmail -bt -d0.10 < /dev/null |
上記のコマンドでは、Sun 固有のフラグは表示されません。
MILTER (sendmail のメールフィルタ API ) によって、サードパーティー製のプログラムが、メタ情報と本文にフィルタをかけるために処理されるときに、メールメッセージにアクセスできるようになります。フィルタを作成する必要や、作成したフィルタを使用するように sendmailを構成する必要はありません。この API は、sendmail の version 8.13 ではデフォルトで有効になっています。
詳細は、次を参照してください。
Solaris リリースには、sendmail.org による汎用リリースで提供されているコマンドの同義語がすべて組み込まれているわけではありません。次の表は、すべてのコマンドの別名を示したリストです。この表には、コマンドが Solaris リリースに組み込まれているかどうか、および sendmail を使って同じ動作を生成する方法も示しています。
表 14–5 代替 sendmail コマンド
代替名 |
Solaris への組み込み |
sendmail を使用したオプション |
---|---|---|
hoststat |
いいえ |
sendmail -bh |
mailq |
はい |
sendmail -bp |
newaliases |
はい |
sendmail -bi |
purgestat |
いいえ |
sendmail -bH |
smtpd |
いいえ |
sendmail -bd |
Solaris 10 以降のリリースに含まれている sendmail のバージョンには、sendmail.cf ファイルのバージョンを定義するための構成オプションが含まれます。現在のバージョンの sendmail でも以前のバージョンの構成ファイルを使用できます。バージョンレベルには 0 から 10 の値を設定できます。また、ベンダーの定義もできます。Berkeley または Sun をベンダーとして選択できます。ベンダーを定義しないでバージョンレベルだけを設定した場合は、Sun がデフォルトとして使用されます。次の表に有効なオプションを示します。
表 14–6 構成ファイルのバージョン値
フィールド |
説明 |
---|---|
V7/Sun |
sendmail の version 8.8 で使用された設定。 |
V8/Sun |
sendmail の version 8.9 で使用された設定。この設定は、Solaris 8 に含まれていました。 |
V9/Sun |
sendmail の version 8.10 と 8.11 で使用された設定。 |
V10/Sun |
sendmail の version 8.12 と 8.13 で使用される設定。version 8.12 は、Solaris 9 のデフォルトです。Solaris 10 以降のリリースでは、version 8.13 がデフォルトです。 |
V1/Sun は使用しないでください。詳細は、http://www.sendmail.org/vendor/sun/differences.html#4 を参照してください。
作業手順については、第 13 章メールサービス (手順)の 「sendmail 構成を変更する」を参照してください。
ここでは、メールシステムのソフトウェアとハードウェアの構成要素について説明します。
各メールサービスには、少なくとも次のいずれかのソフトウェアコンポーネントが含まれます。
ここでは、次のソフトウェアコンポーネントについても説明します。
「メールユーザーエージェント」は、ユーザーとメール転送エージェント間のインタフェースとして機能するプログラムです。sendmail プログラムは、メール転送エージェントです。Solaris オペレーティングシステムは、次のメールユーザーエージェントを提供します。
/usr/bin/mail
/usr/bin/mailx
/usr/dt/bin/dtmail
「メール転送エージェント」は、メールメッセージのルーティングとメールアドレスの解釈を行います。このエージェントは、「メールトランスポートエージェント」とも呼ばれます。Solaris オペレーティングシステムの転送エージェントは sendmail です。転送エージェントは次の機能を実行します。
メールユーザーエージェントからメッセージを受信する
宛先アドレスを認識する
適切な配信エージェントを選択してメールを配信する
ほかのメール転送エージェントからのメールを受信する
「ローカル配信エージェント」は、メールの配信プロトコルを実行するプログラムです。Solaris オペレーティングシステムには、次のローカル配信エージェントが提供されています。
UUCP ローカル配信エージェント (uux を使ってメールを配信する)
ローカル配信エージェント (標準の Solaris リリースでは mail.local)
「sendmail の version 8.12 からの変更点」 では、次の関連項目について説明します。
「メールプログラム」は、sendmail 固有の用語です。「メールプログラム」は sendmail によって使用され、カスタマイズされたローカル配信エージェントまたはカスタマイズされたメール転送エージェントの特定のインスタンスを特定します。sendmail.cf ファイルに少なくとも 1 つのメールプログラムを指定する必要があります。作業手順については、第 13 章メールサービス (手順)の 「sendmail 構成を変更する」を参照してください。ここでは、2 種類のメールプログラムについて説明します。
メールプログラムの詳細は、http://www.sendmail.org/m4/readme.html または /etc/mail/cf/README を参照してください。
SMTP はインターネットで使用される標準のメールプロトコルです。このプロトコルが、メールプログラムを定義します。
smtp は、ほかのサーバーへの標準 SMTP 転送機能を提供します。
esmtp は、ほかのサーバーへの拡張 SMTP 転送機能を提供します。
smtp8 は、8 ビットデータを MIME に変更することなく、ほかのサーバーに SMTP 転送機能を提供します。
dsmtp は、F=% メールプログラムフラグを使ってオンデマンド配信機能を提供します。「sendmail の version 8.12 からの MAILER() の宣言についての変更点」と 「sendmail の version 8.12 から追加された配信エージェントのフラグ」を参照してください。
UUCP の使用は、できるだけ避けてください。説明については、http://www.sendmail.org/m4/uucp_mailers.html を参照するか、/etc/mail/cf/README で USING UUCP MAILERS という文字列を検索してください。
UUCP が、メールプログラムを定義します。
$=U クラスの名前が uucp-old に送られます。suucp は、このメールプログラムの以前の名前です。uucp-old メールプログラムはヘッダーでは感嘆符を用いるアドレスを使用します。
$=Y クラスの名前が uucp-new に送られます。受信側の UUCP メールプログラムが単一の転送で複数の受信者を管理できる場合は、このメールプログラムを使用します。suucp は、このメールプログラムの以前の名前です。uucp-new メールプログラムはヘッダーで感嘆符を用いるアドレスも使用します。
構成に MAILER(smtp) も指定されている場合は、さらに次の 2 つのメールプログラムが定義されます。
このメールプログラムは、ドメインスタイルアドレスを使用し、基本的に SMTP のリライトルールを適用します。
$=Z クラスの名前が uucp-uudom に送られます。uucp-uudom と uucp-dom は、ドメインスタイルアドレスという同じヘッダーアドレス書式を使用します。
smtp メールプログラムは UUCP メールプログラムを変更するので、.mc ファイルの MAILER(uucp) の前に必ず MAILER(smtp) を記述します。
「メールアドレス」には、受信者の名前と、メールメッセージが配信されるシステムが含まれます。ネームサービスを使用しない小さなメールシステムを管理する場合、メールのアドレス指定は簡単です。つまり、ログイン名がユーザーを一意に識別します。メールボックスを含む複数のシステムで構成されるメールシステム、または 1 つ以上のドメインで構成されるメールシステムを管理する場合は複雑になります。UUCP またはその他のメールシステムによってネットワーク外部のサーバーに接続する場合は、さらに複雑になります。次の節で、メールアドレスの各部とその複雑さを説明しています。
電子メールのアドレス指定には、ドメインが使用されます。「ドメイン」は、ネットワークアドレスの命名のためのディレクトリ構造です。ドメインは 1 つ以上の「サブドメイン」を持つことができます。アドレスのドメインとサブドメインは、ファイルシステムの階層と比較できます。サブディレクトリが上位のディレクトリに含まれるように、メールアドレスの各サブドメインもその右のドメインに含まれると考えられます。
表 14–7 最上位のドメイン
ドメイン |
説明 |
---|---|
com |
企業 |
edu |
教育機関用 |
gov |
米国の政府機関 |
mil |
米国の軍事機関 |
net |
ネットワーク組織 |
org |
その他の非営利組織 |
ドメインには大文字と小文字の区別がありません。アドレスのドメイン部分には、大文字、小文字、またはその両方を混合したものを、問題なく使用できます。
ネームサービスドメイン名とメールドメイン名を操作するときは、次のことに注意します。
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)
受信側のメールプログラムでアドレスのローカル部分を解釈する必要があります。メールプログラムの詳細は、「メールプログラムと sendmail」を参照してください。
アドレスの @ 記号より右の部分は、ローカルアドレスが位置するドメインレベルを示します。各サブドメインはドットで区切られます。アドレスのドメイン部分は、組織、物理的な場所、または地域を表すことができます。さらに、ドメイン情報の順序は階層的で、ローカルなサブドメインほど @ 記号に近くなります。
メールアドレスは、経路に依存しないアドレス指定ができます。経路に依存しないアドレス指定では、電子メールメッセージの発信者は、受信者の名前と最終の宛先を指定する必要があります。インターネットなどの高速ネットワークでは、経路に依存しないアドレスを使用します。経路に依存しないアドレスは次のような書式になります。
user@host.domain |
UUCP 接続の経路に依存しないアドレスは次のような書式になります。
host.domain!user |
コンピュータのドメイン階層命名方式が普及したため、経路に依存しないアドレスがより一般的になってきました。実際、次に示すように、もっとも一般的な経路に依存しないアドレスはホスト名を省略し、電子メールメッセージの最終宛先の識別をドメインネームサービスに任せています。
user@domain |
経路に依存しないアドレスは、まず @ 記号を検索して読み取られます。次に、ドメイン階層が右 (最上位) から左 (@ 記号の右側にあるもっとも固有な部分) へと読み取られます。
「メールボックス」は、電子メールメッセージの最終的な宛先となるファイルです。メールボックス名には、ユーザー名または postmaster などの特定の機能の名前を指定できます。メールボックスは、ユーザーのローカルシステムかリモートのメールサーバーのいずれかの /var/mail/username ファイルにあります。ただし、いずれの場合でも、メールボックスはメールが配信されるシステム上にあります。
ユーザーエージェントがメールスプールからメールを取り出し、ローカルメールボックスに容易に格納できるように、メールは常にローカルファイルシステムに配信される必要があります。ユーザーのメールボックスの宛先として、NFS でマウントされたファイルシステムを使用しないでください。特にリモートサーバーから /var/mail ファイルシステムをマウントしているメールクライアントには、直接メールを送信しないでください。この場合ユーザー宛てのメールは、クライアントのホスト名ではなく、メールサーバーにアドレス指定する必要があります。NFS でマウントされたファイルシステムは、メールの配信と処理に問題を起こすことがあります。
/etc/mail/aliases ファイルと NIS や NIS+ といったネームサービスを利用すると、電子メールアドレスの別名を作成できます。したがって、ユーザーは、個々のユーザーのメールボックスの正確なローカル名を知る必要はありません。
次の表に、特殊な目的のメールボックスに対する共通の命名規則をいくつか示します。
表 14–8 メールボックス名の書式についての規則
sendmail version 8 より、所有者の別名が存在する場合、グループの別名に送信されるメールの封筒の送信者は、所有者の別名から展開されるアドレスに変更されました。この変更によって、メールエラーは、送信者に返送されるのではなく、別名の所有者に送信されるようになりました。この変更によって、別名に送信されたメールは、別名の所有者から送信されたように見えます。次の別名の書式は、この変更に関連したいくつかの問題に対応します。
mygroup: :include:/pathname/mygroup.list owner-mygroup: mygroup-request mygroup-request: sandys, ignatz |
この例では、mygroup の別名が、このグループの実際のメール別名です。owner-mygroup の別名は、エラーメッセージを受信します。mygroup-request の別名は、管理の要求に使用してください。この構造は、mygroup の別名に送信されたメールでは、封筒の送信者が mygroup-request に変更されることを意味します。
「別名 (alias) 」とは、もう 1 つの別の名前を指します。電子メールでは、メールボックスの場所を割り当てたり、メールリストを定義したりするために別名を使用できます。作業マップについては、第 13 章メールサービス (手順)の 「メール別名ファイルの管理 (作業マップ)」を参照してください。この章の 「メール別名ファイル」も参照してください。
大きなサイトでは通常、メール別名は、メールボックスの場所を定義します。メール別名を提供することは、複数の部屋を占有する大きな会社の個人のアドレスに部屋番号を含めるようなものです。部屋番号を提供しない場合は、メールは中央アドレスに配信されます。部屋番号がなければ、ビルの内部のどこにメールを配信するかを特定するために余分な労力が必要になります。そして、誤りが発生する可能性も増加します。たとえば、同じ建物に 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 を追加します。または、ネームサービスのホストファイルに mailhost を同じように追加することもできます。作業手順については、「メールホストを設定する方法」の 第 13 章メールサービス (手順)を参照してください。
メールホストの候補は、ネットワークからグローバルなインターネットネットワークへのルーターとして構成されたシステムです。詳細は、第 15 章Solaris PPP 4.0 (概要)、第 24 章UUCP (概要)、および『Solaris のシステム管理 (IP サービス)』の「IPv4 ルーターの構成」を参照してください。ローカルネットワークのどのシステムにもモデムがない場合は、システムの 1 つをメールホストに指定します。
サイトの中には、タイムシェアリング構成でネットワークに接続されていないスタンドアロンのマシンを使用するものがあります。具体的に言うと、スタンドアロンのマシンが、シリアルポートに接続された端末として機能する場合です。このような構成では、スタンドアロンのシステムをシングルシステムネットワークのメールホストに指定することで、電子メールを設定できます。「ハードウェアコンポーネントの概要」の 第 12 章メールサービス (概要)に、典型的な電子メール構成を示す図があります。
「メールボックス」は、特定のユーザーの電子メールを含む単一のファイルです。メールは、ローカルマシンまたはリモートサーバーのユーザーのメールボックスが存在するシステムに配信されます。「メールサーバー」は、/var/mail ディレクトリにユーザーのメールボックスを保持しているいずれかのシステムになります。作業手順については、「メールサーバーを設定する方法」の 第 13 章メールサービス (手順)を参照してください。
メールサーバーはクライアントからすべてのメールをルーティングします。クライアントがメールを送信すると、メールサーバーは配信のためにそのメールをキューに入れます。メールがキューに入れられたら、ユーザーはこれらのメールメッセージを失わずに、クライアントをリブートしたり、電源を切ったりすることができます。受信者がクライアントからメールを受け取ると、メッセージの From 行のパスには、メールサーバー名が含まれます。受信者が応答すると、その応答はユーザーのメールボックスに送られます。メールサーバーとして適しているのは、ユーザーにホームディレクトリを提供するシステムか、定期的にバックアップされるシステムです。
メールサーバーがユーザーのローカルシステムでない場合、構成内で NFS ソフト ウェアを使用するユーザーは、root アクセスがあれば、/etc/vfstab ファイルを使用することによって、/var/mail ディレクトリをマウントできます。それ以外の場合は、オートマウンタを使用できます。NFS サポートが利用できない場合、ユーザーはサーバーにログインしてメールを読み込めます。
ネットワーク上のユーザーが、オーディオファイル、DTP システムからのファイルなどほかの形式のファイルを送信する場合は、メールボックスのメールサーバーには、さらに多くの領域を割り当てる必要があります。
全メールボックス用に 1 台のメールサーバーを設定すると、バックアップ作業が簡単になります。メールが多くのシステムに分散しているとバックアップ作業が困難になる場合があります。1 台のサーバーに多くのメールボックスを保存する場合の短所は、サーバーに障害が発生した場合に多くのユーザーが影響を受けることです。ただし、十分なバックアップ機能を提供すれば、1 台のサーバーを採用する価値があります。
「メールクライアント」は、メールサーバー上にメールボックスを持っている、メールサービスのユーザーです。メールクライアントにはさらに、/etc/mail/aliases ファイルで、メールボックスの位置を示すメール別名が設定されています。作業手順については、「メールクライアントを設定する方法」の 第 13 章メールサービス (手順)を参照してください。
「メールゲートウェイ」は、異なる通信プロトコルを実行するネットワーク間の接続を処理したり、同じプロトコルを使用する異なるネットワーク間の通信を処理するマシンです。たとえば、メールゲートウェイでは、SNA (Systems Network Architecture) プロトコルセットを実行するネットワークに、TCP/IP ネットワークを接続する場合もあります。
設定のもっとも簡単なメールゲートウェイは、同じプロトコルかメールプログラムを使用する 2 つのネットワークを接続するものです。このシステムでは、sendmail がドメインで受信者を見つけられないアドレスのあるメールを処理します。メールゲートウェイがある場合、sendmail はメールゲートウェイを使用して、ドメイン外でメールの送受信を行います。
2 つのネットワーク間には、次の図に示すように内容の異なるメールプログラムを使ってメールゲートウェイを設定できます。この構成をサポートするには、メールゲートウェイシステムで sendmail.cf ファイルをカスタマイズする必要がありますが、これは困難で時間のかかる作業になる場合もあります。
インターネットに接続できるマシンがある場合は、そのマシンをメールゲートウェイとして構成できます。メールゲートウェイを構成するときは、まずサイトのセキュリティー要件を慎重に考慮する必要があります。社内ネットワークをほかのネットワークと接続するには、ファイアウォールゲートウェイを構築し、それをメールゲートウェイとして設定しなければならない場合があります。作業手順については、「メールゲートウェイを設定する方法」の 第 13 章メールサービス (手順)を参照してください。
メールサービスには、相互に対応する数多くのプログラムやデーモンが含まれています。ここでは、電子メールの管理に関連するファイル、プログラム、用語、および概念について説明します。
Solaris 10 以降のリリースでは、vacation ユーティリティーが機能強化され、自動生成された応答をどの着信メッセージが受けるかをユーザーが指定できるようになりました。この拡張機能により、ユーザーは、知らない人と機密情報や連絡先を共有せずにすみます。スパマーや知らない人からのメッセージは、応答を受け取りません。
この拡張機能は、着信電子メールの送信者のアドレスを .vacation.filter ファイル内のドメインまたは電子メールアドレスのリストと付き合わせることによって機能します。このファイルは、ユーザーによって作成され、ユーザーのホームディレクトリにあります。ドメインまたは電子メールアドレスで一致するものがあると、応答が送られます。一致するものがなければ、応答は送られません。
.vacation.filter には、次のようなエントリが含まれます。
company.com mydomain.com onefriend@hisisp.com anotherfriend@herisp.com |
各行には、1 つのドメインまたは 1 つの電子メールアドレスが含まれます。1 つのエントリを 1 行に入力する必要があります。送信者の電子メールアドレスが電子メールアドレスエントリと一致するには、大文字と小文字の違いを除いて、完全に一致している必要があります。送信者のアドレスの文字が小文字であるか大文字であるかは無視されます。送信者の電子メールアドレスがドメインエントリと一致するには、一覧表示されているドメインに送信者のアドレスが含まれている必要があります。たとえば、somebody@dept.company.com と someone@company.com の両方が、company.com のドメインエントリと一致します。
詳細は、vacation(1) のマニュアルページを参照してください。
次の表にメールサービスに使用する /usr/bin ディレクトリの内容を示します。
名前 |
種類 |
説明 |
---|---|---|
ファイル |
NIS+ 別名マップを処理するプログラム。 |
|
ファイル |
ユーザーエージェント。 |
|
ファイル |
メールを SunOS 4.1 メールボックスフォーマットに格納するフィルタ。 |
|
ファイル |
メールキューの内容を一覧表示するプログラム。 |
|
ファイル |
/etc/mail/statistics ファイルに格納されたメール統計情報の読み込みに使用するプログラム (存在する場合のみ)。 |
|
ファイル |
ユーザーエージェント。 |
|
ファイル |
アドレスの検証とデバッグのためメールプログラムに接続するプログラム。 |
|
ファイル |
別名データベースを「ソースに展開」するコマンド。praliases(1) のマニュアルページにあるソース展開の情報を参照してください。 |
|
シンボリックリンク |
/usr/bin/mail へのシンボリックリンク。メール送信だけに使用されるコマンド。 |
|
ファイル |
メールへの自動応答を設定するコマンド。 |
次の表に、/etc/mail ディレクトリの内容を示します。
名前 |
種類 |
説明 |
---|---|---|
ファイル |
mailx ユーザーエージェントのデフォルトの設定値。 |
|
ファイル |
メール転送情報。 |
|
ファイル |
newaliases の実行によって作成されるデフォルトのバイナリ形式のメール転送情報。 |
|
ファイル |
newaliases の実行によって作成されるバイナリ形式のメール転送情報。まだ使用できますが、Solaris 9 よりデフォルトでは使用できません。 |
|
ファイル |
newaliases の実行によって作成されるバイナリ形式のメール転送情報。まだ使用できますが、Solaris 9 よりデフォルトでは使用できません。 |
|
ファイル |
mailx ユーザーエージェントのデフォルトの設定値。 |
|
シンボリックリンク |
メインシステム用の構成ファイルのこの例から sendmail.cf へのシンボリックリンクが、下位互換性を確保するために提供されます。このファイルは、sendmail の version 8.13 では必要ありません。 |
|
ファイル |
リレーを許容するすべてのドメインのリスト。デフォルトでは、ローカルドメインだけが使用できます。 |
|
ファイル |
メールルーティング用の構成ファイル。 |
|
ファイル |
メール配信プログラム (MSP) のための新しい構成ファイル。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。 |
|
ファイル |
メールホスト用の別名の数が多すぎるときに作成可能なオプションファイル。 |
|
ファイル |
SMTP HELP コマンドで使用するヘルプファイル。 |
|
ファイル |
リスニングデーモンの PID を一覧表示し、現在は /var/run にあるファイル。 |
|
ファイル |
sendmail 統計ファイル。このファイルが存在すると、sendmail は各メールプログラムのトラフィック量をログに記録します。このファイルは以前 sendmail.st と呼ばれていました。 |
|
シンボリックリンク |
サブシステム用の構成ファイルのこの例から sendmail.cf へのシンボリックリンクが、下位互換性を確保するために提供されます。このファイルは、sendmail の version 8.13 では必要ありません。 |
|
ファイル |
特定のメール操作を実行するための信頼を与えられたユーザーを一覧表示するファイル (各行 1 ユーザー)。デフォルトでは、root だけがこのファイルに入っています。信頼されていないユーザーが特定のメール操作を実行すると、X-Authentication-Warning: header being added to a message という警告が生成されます。 |
/etc/mail ディレクトリには、sendmail.cf ファイルを構築するために必要なすべてのファイルを含む cf というサブディレクトリがあります。表 14–9 に cf ディレクトリの内容を示します。
Solaris 10 以降のリリースでは、読み取り専用の /usr ファイルシステムをサポートするために、/usr/lib/mail ディレクトリの内容が /etc/mail/cf ディレクトリに移動されました。ただし、例外があります。シェルスクリプト /usr/lib/mail/sh/check-hostname および /usr/lib/mail/sh/check-permissions は、/usr/sbin ディレクトリに置かれるようになりました。「メールサービスに使用するその他のファイル」を参照してください。下位互換性を確保するために、シンボリックリンクが各ファイルの新しい位置を示します。
表 14–9 メールサービスに利用する /etc/mail/cf ディレクトリの内容
名前 |
種類 |
説明 |
---|---|---|
ファイル |
構成ファイルを説明します。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.cf にリンクされます。このファイルはメインの構成ファイルとして使用されます。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.mc にリンクされます。このファイルは、メインの構成ファイルを作成するためのファイルでした。 |
|
ファイル |
新しい構成ファイルを作成する場合の規則を提供します。 |
|
ファイル |
メッセージを送信するためのメール配信プログラム (MSP) のための構成ファイルです。 |
|
ファイル |
submit.cf ファイルの構築に使用されるファイルです。このファイルは、メール配信プログラム (MSP) のための m4 マクロを定義します。 |
|
ファイル |
sendmail のためのメインの構成ファイルです。 |
|
ファイル |
sendmail.cf ファイルの生成に使用される m4 マクロが含まれています。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.cf にリンクされます。別のホストから /var/mail を NFS マウントするホストのための構成ファイルとして使用されます。 |
|
シンボリックリンク |
Solaris 10 リリース以降、このファイル名は cf/sendmail.mc にリンクされます。このファイルには、subsidiary.cf ファイルの生成に使用された m4 マクロが含まれています。 |
|
ディレクトリ |
サイトに依存するサブドメインの説明を提供します。 |
|
ファイル |
Berkeley Software Distribution からの汎用ドメインファイルです。 |
|
ファイル |
sendmail 関数を以前の Solaris 版の sendmail のようにする変更を伴うドメインファイルです。ただし、リレーは完全に無効に設定されるので、ホスト名のない送信者アドレスは拒否され、解決されないドメインは拒否されます。 |
|
ファイル |
sendmail 関数を以前の Solaris 版の sendmail のようにする変更を伴うデフォルトのドメインファイルです。 |
|
ディレクトリ |
特定のホスト用の特別な機能の定義を含みます。機能の詳細な説明は README を参照してください。 |
|
ディレクトリ |
サイトに依存しないインクルードファイルを含みます。 |
|
ディレクトリ |
local、smtp、uucp などのメールプログラムの定義を含みます。 |
|
ファイル |
廃止: Solaris 10 リリース以降、このファイル名は cf/sendmail.mc に変更されました。 |
|
ディレクトリ |
各種のオペレーティングシステム環境を説明します。 |
|
ファイル |
デフォルトのローカルメールプログラムを mail.local に定義します。 |
|
ファイル |
デフォルトのローカルメールプログラムを mail.local に定義します。 |
|
ファイル |
ローカルメールプログラムを mail に定義します。 |
|
ファイル |
ローカルメールプログラムを LMTP モードで mail.local に定義し、IPv6 を有効にし、sendmail.pid ファイルのディレクトリとして /var/run を指定します。 |
|
ファイル |
廃止: Solaris 10 リリース以降、このファイル名は cf/sendmail.mc に変更されました。 |
次の表にメールサービスに使用する /usr/lib ディレクトリの内容を示します。
表 14–10 /usr/lib ディレクトリの内容
名前 |
種類 |
説明 |
---|---|---|
mail.local |
ファイル |
メールボックスにメールを配信するメールプログラム。 |
sendmail |
ファイル |
メール転送エージェントとしても知られるルーティングプログラム。 |
smrsh |
ファイル |
sendmail の |program 構文を使用して /var/adm/sm.bin ディレクトリにあるプログラムに対して sendmail を実行できるプログラムを制限するシェルプログラム (sendmail に限定されたシェル)。/var/adm/sm.bin に含める内容については、smrsh(1M) のマニュアルページを参照してください。有効にするには、この m4 コマンドと FEATURE(`smrsh') を mc ファイルに含めます。 |
|
シンボリックリンク |
シンボリックリンクは /etc/mail/cf ディレクトリを示します。詳細は、「/etc/mail/cf ディレクトリの内容」を参照してください。 |
メールサービスは、その他のいくつかのファイルおよびディレクトリを使用します。これらを表 14–11 に示します。
表 14–11 メールサービスに使用するその他のファイル
名前 |
種類 |
説明 |
---|---|---|
/etc/default/sendmail |
ファイル |
sendmail の起動スクリプトの環境変数を一覧表示します。 |
/etc/shells |
ファイル |
有効なログインシェルを一覧表示します。 |
/etc/mail/cf/sh |
ディレクトリ |
m4 構築プロセスと移行補助に使用するシェルスクリプトを含みます。 |
ファイル |
:include: 別名と .forward ファイルのアクセス権、および正確なアクセス権に必要なこれらの親ディレクトリのパスを確認します。 |
|
ファイル |
sendmail が完全指定のホスト名を判別できることを確認します。 |
|
ファイル |
sendmail のデータベースマップの単一のレコードに対してクエリーを実行して編集します。 |
|
ファイル |
メール通知デーモン。 |
|
ファイル |
入力されたマップのバイナリ形式を構築します。 |
|
シンボリックリンク |
/usr/lib/sendmail へのシンボリックリンク。別名データベースのバイナリ形式を作成するために使用します。以前は /usr/bin にありました。 |
|
ファイル |
sendmail が使用するエラーメッセージログをとるデーモン。 |
|
ファイル |
クライアント側リモートメールキューを起動するための Perl スクリプト。 |
|
ファイル |
CDE メールユーザーエージェント。 |
|
ファイル |
配信されたメールのメールボックス。 |
|
ディレクトリ |
クライアントデーモンによって配信されるメールの記憶領域。 |
|
ディレクトリ |
マスターデーモンによって配信されるメールの記憶領域。 |
|
ファイル |
リスニングデーモンの PID を表示するファイル。 |
メールサービスは次のプログラムで構成され、図 14–2 のように作用します。
次に、メールプログラムの相互作用について説明します。
ユーザーは、mailx などのプログラムを使ってメッセージを送信します。詳細は、mailx(1) のマニュアルページを参照してください。
メッセージは、そのメッセージを生成したプログラムによって収集され、sendmail デーモンに渡されます。
sendmail デーモンがメッセージのアドレスを識別可能な各部に分割して解析します。sendmail デーモンは、/etc/mail/sendmail.cf という構成ファイルの情報を使ってネットワーク名の構文、別名、転送情報、およびネットワークトポロジを決定します。sendmail はこの情報を使用して、メッセージが受信者に到達する経路を決定します。
sendmail デーモンはメッセージを適切なシステムに渡します。
ローカルシステムの /usr/lib/mail.local プログラムは、メッセージの受信者の /var/mail/username ディレクトリのメールボックスにメールを配信します。
受信者は、メールが届いたことが通知されるので、mail、mailx などのプログラムを使用してメールを受け取ります。
sendmail は、TCP/IP や UUCP などの異なる通信プロトコルを使用できます。
sendmail は、SMTP サーバー、メッセージキュー、メーリングリストを実装します。
sendmail は、次の命名規則に準拠したパターンマッチングシステムを使って名前の解釈を制御します。
ドメインベースの命名規則。ドメインの手法は、物理的なネーミングと論理的なネーミングの問題を分離します。詳細は、「メールアドレス」を参照してください。
ほかのネットワークのホストからローカルに見えるネットワーク名を提供するなどの即席のテクニック。
任意 (以前) の命名構文。
異種の命名スキーム。
Solaris オペレーティングシステムでは、sendmail プログラムをメールルーターとして使用します。次に、機能の一部を示します。
sendmail は、mail.local や procmail などのローカル配信エージェントとの間で、電子メールメッセージの受信や配信を行う役割を果たします。
sendmail はメール転送エージェントであり、mailx や Mozilla Mail などのユーザーエージェントからメッセージを受け取り、そのメッセージをインターネット経由でその宛先までルーティングします。
sendmail は、次の要領でユーザーが送信する電子メールメッセージを制御します。
受信者のアドレスを確認します。
適切な配信プログラムを選択します。
アドレスを配信エージェントが処理できるフォーマットに書き換えます。
必要に応じて、メールヘッダーをフォーマットし直します。
最後に転送されたメッセージをメール配信プログラムに渡します。
sendmail の詳細は、次のトピックを参照してください。
sendmail プログラムでは、メールルーティングに必要な 3 つのメカニズムをサポートしています。適切なメカニズムは、変更の種類によって決まります。
サーバーの変更
ドメイン全体の変更
単独のユーザーの変更
さらに、選択する再ルーティングメカニズムによって必要な管理レベルが異なります。次のオプションを考慮してください。
再ルーティングメカニズムの 1 つは「別名」です。
別名を使用すれば、使用するファイルの種類に基づいて、サーバー全体またはネームサービス全体をベースにしてアドレス名をマップできます。
次に、ネームサービスの別名の長所と短所を示します。
ネームサービス別名ファイルを使用すれば、メール再ルーティングの変更を単一のソースで管理できます。ただし、ネームサービスの別名指定では、再ルーティングの変更を伝達する際に遅延が起こります。
通常、ネームサービスの管理は、特定のシステム管理者グループに制限されます。一般ユーザーは、このファイルを管理しません。
次に、サーバー別名ファイルを使用する際の長所と短所を示します。
サーバー別名ファイルを使用すれば、指定されたサーバーの root になることができる任意のユーザーが再ルーティングを管理できます。
サーバー別名指定は、再ルーティングの変更を伝達する際の遅延はほとんどありません。
変更はローカルサーバーだけに影響します。ほとんどのメールが単一のサーバーに送信される場合は、影響が少なくなります。ただし、この変更を多くのメールサーバーに伝達する必要がある場合は、ネームサービスの別名指定を使用します。
一般ユーザーは、この変更を管理しません。
詳細は、この章の 「メール別名ファイル」を参照してください。作業マップについては、第 13 章メールサービス (手順)の 「メール別名ファイルの管理 (作業マップ)」を参照してください。
次のメカニズムは、「転送」です。
このメカニズムでは、ユーザーがメールの再ルーティングを管理できます。ローカルユーザーは、受信メールを次の対象に再ルーティングできます。
別のメールボックス
別のメールプログラム
別のメールホスト
このメカニズムは、.forward ファイルによってサポートされます。.forward ファイルの詳細は、この章の 「.forward ファイル」を参照してください。作業マップについては、「.forward ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
最後のメカニズムは、「取り込み」です。
このメカニズムでは、root アクセス権を持たないユーザーも別名リストを保守できます。このメカニズムを提供するには、root ユーザーは、サーバー上の別名ファイル内に適切なエントリを作成する必要があります。このエントリが作成されると、ユーザーは必要に応じてメールをルーティングし直すことができるようになります。取り込みの詳細は、この章の 「/etc/mail/aliases ファイル」を参照してください。作業マップについては、第 13 章メールサービス (手順)の 「メール別名ファイルの管理 (作業マップ)」を参照してください。
/usr/bin/mailx のようなメールを読み取るプログラムは、プログラム自身の別名を持つことができ、それらはメッセージが sendmail に達する前に展開されます。sendmail の別名は、ローカルファイル、NIS、NIS+ など、さまざまなネームサービスソースからのものでもかまいません。検索順序は nsswitch.conf ファイルによって決定されます。nsswitch.conf(4) のマニュアルページを参照してください。
sendmail プログラムには、次のような機能があります。
sendmail は、信頼性の高いプログラムです。すべてのメッセージを正しく配信するように設計されています。どのようなメッセージも完全に失われることはありません。
sendmail は、既存のソフトウェアを配信に随時使用します。たとえば、ユーザーは、メール生成プログラムおよびメール送信プログラムと対話します。メール送信が依頼されると、メール生成プログラムは sendmail を呼び出し、sendmail は適切なメールプログラムにメッセージを送信します。発信者の一部はネットワークサーバーであったり、またメールプログラムの一部はネットワーククライアントであるため、sendmail は、インターネットメールゲートウェイとしても使用できます。このプロセスの詳細は、「メールプログラム間の相互作用」を参照してください。
sendmail は、複数のネットワークなど、複雑な環境を処理するように構成できます。sendmail は、アドレスとその構文の内容を確認し、どのメールプログラムを使用するかを判断します。
sendmail は、構成情報をコードにコンパイルする代わりに、構成ファイルを使ってメール構成を制御します。
ユーザーは独自のメーリングリストを管理できます。さらに各ユーザーは、ドメイン全体で有効な別名ファイル (通常、NIS または NIS+ によって管理されるドメイン全体の別名の中にある) を修正することなく自分自身の転送メカニズムを指定できます。
各ユーザーは、受信メールを処理するカスタムメールプログラムを指定できます。カスタムメールプログラムは、次のようなメッセージを返すこともできます。 「私は休暇中です」。詳細は、vacation(1) のマニュアルページを参照してください。
sendmail は、1 つのホストでアドレスを処理し、ネットワークトラフィックを削減します。
「構成ファイル」は、sendmail がその機能を実行する方法を制御します。構成ファイルにより、配信エージェント、アドレスの変換の規則、およびメールヘッダーのフォーマットが選択されます。sendmail プログラムは、/etc/mail/sendmail.cf ファイルの情報を使用して、その機能を実行します。
Solaris オペレーティングシステムには、/etc/mail ディレクトリに次の 2 つのデフォルト構成ファイルがあります。
デーモンモードの代わりにメール配信プログラムモードで sendmailを実行するために使用する submit.cf 構成ファイル。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。
メールクライアント、メールサーバー、メールホスト、メールゲートウェイを設定するときは、次を考慮してください。
メールホストやメールゲートウェイを設定するには、メール設定に必要な中継メールプログラムおよび中継ホストのパラメータを設定します。作業手順については、「メールサービスの設定 (作業マップ)」の 「sendmail 構成を変更する」または 第 13 章メールサービス (手順)を参照してください。sendmail version 8.13 では、main.cf ファイルは必要ありません。
次に、サイトの要求に応じて変更が可能な構成パラメータをいくつか説明します。
次の情報を指定する時間値。
読み取りのタイムアウト。
メッセージが送信者に返送されるまで、配信されずにキューに置かれる時間。「sendmail の version 8.12 から追加されたキューの機能」を参照してください。作業マップについては、「キューディレクトリの管理 (作業マップ)」を参照してください。
メール配信の速度を指定する配信 (delivery) モード。
ビジー期間中の効率を高めるためのロード制限。これらのパラメータは、sendmail が、長いメッセージ、多くの受信者へのメッセージ、および長時間ダウンしているサイトへのメッセージを配信しないようにします。
別名を保守するには、次のファイル、マップ、またはテーブルを使用します。
別名を保守する方法は、だれが使用し、だれが変更するかによって決まります。別名のタイプにはそれぞれ固有の形式要件があります。
関連する作業については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
.mailrc ファイルのリストに入っている別名には、ファイルを所有するユーザーしかアクセスできません。この制限により、ユーザーは自分で制御し、所有者だけが使用できる別名を作成できます。.mailrc ファイルの別名の形式は、次のとおりです。
alias aliasname value value value ... |
aliasname は、ユーザーがメールの送信時に使用する名前であり、value は有効な電子メールアドレスです。
ユーザーが scott に個人的な別名を作成し、それがネームサービスの scott の電子メールアドレスと一致しない場合、エラーが発生します。そのユーザーが作成したメールにユーザーが返信しようとするときに、メールが間違ったユーザーに転送されることになります。これを回避するには、別の別名命名方式を使用する以外にありません。
/etc/mail/aliases ファイルで作成したいずれの別名も、その別名の名前と、ファイルを含んでいるシステムのホスト名を知っているユーザーならだれでも使用できます。ローカルの /etc/mail/aliases ファイルの配布リストの形式は、次のとおりです。
aliasname: value,value,value ... |
aliasname は、ユーザーがこの別名にメールを送信するときに使用する名前で、value は有効な電子メールアドレスになります。
使用するネットワークがネームサービスを実行していない場合は、各システムの /etc/mail/aliases ファイルにすべてのメールクライアントのエントリを入れておく必要があります。各システムのファイルを編集するか、1 つのシステムのファイルを編集してからそのファイルをほかのシステムに個々にコピーします。
/etc/mail/aliases ファイルの別名は、テキスト形式で保存されます。/etc/mail/aliases ファイルを編集するときには、newaliases プログラムを実行する必要があります。このプログラムは、データベースをコンパイルし直し、sendmail プログラムが別名をバイナリ形式で使用できるようにします。作業手順については、「ローカルメール別名ファイルを設定する方法」の 第 13 章メールサービス (手順)を参照してください。それ以外の場合、Solaris 管理コンソールの「メーリングリスト」機能を使ってローカルの /etc ファイルに保存されているメール別名を管理できます。
現在のホスト名やホスト名なしなどのローカル名のみに別名を作成できます。たとえば、システム saturn にメールボックスのあるユーザー ignatz の別名エントリには、/etc/mail/aliases ファイルの次のエントリが入ります。
ignatz: ignatz@saturn |
各メールサーバーに管理アカウントを作成する必要があります。管理アカウントを作成するには、メールサーバーのメールボックスを root に割り当て、root のエントリを /etc/mail/aliases ファイルに追加します。たとえば、システム saturn がメールボックスサーバーの場合は、エントリ root: sysadmin@saturn を /etc/mail/aliases ファイルに追加します。
通常は、root ユーザーだけがこのファイルを編集できます。ただし、Solaris 管理コンソールを使用する場合は、sysadmin グループであるグループ 14 のすべてのユーザーが、ローカルファイルを変更できます。または、次のエントリを作成します。
aliasname: :include:/path/aliasfile |
aliasname は、ユーザーがメールを送信するときに使用する名前であり、/path/aliasfile は別名リストを含むファイルへのフルパスになります。別名ファイルには、各行に 1 つの電子メールエントリを入れ、その他の表記は付けないでください。
user1@host1 user2@host2 |
/etc/mail/aliases に追加のメールファイルを定義して、ログやバックアップコピーの管理もできます。次のエントリでは、aliasname に送信されるすべてのメールを filename 内に格納します。
aliasname: /home/backup/filename |
また、ほかのプロセスにメールを回送することもできます。次の例のように入力すると、メールメッセージのコピーが filename 内に格納され、コピーがプリントされます。
aliasname: "|tee -a /home/backup/filename |lp" |
作業マップについては、第 13 章メールサービス (手順)の 「メール別名ファイルの管理 (作業マップ)」を参照してください。
ローカルドメインのすべてのユーザーは、NIS aliases マップのエントリを使用できます。sendmail プログラムは、ローカルの /etc/mail/aliases ファイルの代わりに NIS aliases マップを使って送信アドレスを決定できるからです。詳細は、nsswitch.conf(4) のマニュアルページを参照してください。
NIS aliases マップの別名は、次のようになります。
aliasname: value,value,value ... |
aliasname は、ユーザーがメールの送信時に使用する名前であり、value は有効な電子メールアドレスです。
NIS aliases マップには、すべてのメールクライアント用のエントリを含めてください。一般にこれらのエントリを変更できるのは、NIS マスターの root ユーザーだけです。この種の別名は頻繁に変更される場合には適していません。次の構文例のように、ほかの別名ファイルをポイントする場合には役立ちます。
aliasname: aliasname@host |
aliasname はユーザーがメールを送信するときに使用する名前であり、host は /etc/mail/alias ファイルを含むサーバー用のホスト名です。
作業手順については、「NIS mail.aliases マップを設定する方法」の 第 13 章メールサービス (手順)を参照してください。
NIS+ mail_aliases テーブルには、名前が含まれており、それによってローカルドメインにおけるシステムや個人が登録されています。sendmail プログラムは、ローカルの /etc/mail/aliases ファイルの代わりに NIS+ mail_aliases テーブルを使用して、メールアドレスを決定できます。詳細は、aliasadm(1M) と nsswitch.conf(4) のマニュアルページを参照してください。
NIS+ mail_aliases テーブルの別名は次のようになります。
alias: expansion # ["options" # "comments"] |
表 14–12 に、NIS+ mail_aliases テーブルの 4 つの列を示します。
表 14–12 NIS+ mail_aliases テーブルの列
列 |
説明 |
---|---|
別名 |
別名の名前 |
expansion |
sendmail /etc/mail/aliases ファイルに表示される別名の値または別名のリスト |
options |
今後の使用のために予約された列 |
comments |
個々の別名のコメントのための列 |
NIS+ mail_aliases テーブルには、すべてのメールクライアントのエントリを含めてください。NIS+ aliases テーブルでは、aliasadm コマンドで、エントリの表示、作成、変更、および削除ができます。aliasadm コマンドを使用するには、aliases テーブルを所有する NIS+ グループのメンバーでなければなりません。作業手順については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。Solaris 管理コンソールを使用して NIS+ メール別名を管理することもできます。
新規の NIS+ aliases テーブルを作成する場合は、エントリを作成する前にテーブルを初期設定する必要があります。テーブルが存在するときは、初期設定は不要です。
ホームディレクトリに .forward ファイルを作成すると、sendmail およびその他のプログラムは、メールのリダイレクトや送信にこのファイルを使用できます。次の節を参照してください。
作業マップについては、「.forward ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
次に、容易に回避または修復できる状況を示します。
メールが宛先のアドレスに配信されない場合は、ユーザーの .forward ファイルをチェックしてください。ユーザーは、ホームディレクトリ host1 に .forward ファイルを配置して、user@host2 にメールを転送するようにしたのかもしれません。host2 にメールが着信すると、sendmail は NIS または NIS+ 別名に user があるかどうかを確認し、メッセージを user@host1 に返送します。このルーティングによってループが発生し、バウンスメールの増加を引き起こしています。
セキュリティーの問題を予防するために、root または bin アカウントに .forward ファイルを決して置かないでください。必要な場合は、代わりに aliases ファイルを使ってメールを転送してください。
メール配信で .forward ファイルを有効に使用するために、アクセス権などの次の設定が正しく適用されていることを確認してください。
.forward ファイルへの書き込みは、ファイルの所有者に制限されます。この制限によって、ほかのユーザーがセキュリティーに反することを防止します。
ホームディレクトリの親パスは root だけが所有し、root だけが書き込めるようにする必要があります。たとえば、.forward ファイルが /export/home/terry にある場合、/export および /export/home は root が所有し、root だけが書き込めるようにします。
また実際のホームディレクトリに書き込めるのは、そのユーザーだけであるべきです。
.forward ファイルをシンボリックリンクにすることはできません。また、複数のハードリンクを持つこともできません。
.forward.hostname ファイルを作成すれば、特定のホストに送信されるメールをリダイレクトできます。たとえば、ユーザーの別名が sandy@phoenix.example.com から sandy@example.com に変更された場合は、sandy のホームディレクトリに .forward.phoenix ファイルを置きます。
% cat .forward.phoenix sandy@example.com "|/usr/bin/vacation sandy" % cat .vacation.msg From: sandy@example.com (via the vacation program) Subject: my alias has changed My alias has changed to sandy@example.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 つのメッセージしか転送できません。ただし、メッセージが特定のホストに限定されない場合、.forward ファイルで複数のホストに同じ休暇メッセージファイルを使用できます。
転送メカニズムの拡張機能にはこの他に、.forward+detail ファイルがあります。detail 文字列には、演算子文字を除く任意の文字を使用できます。演算子文字は、.:%&!^[]+ です。この種のファイルを使用すれば、ほかのユーザーが電子メールアドレスを無断で使用しているかどうかを確認できます。たとえば、あるユーザーが、だれかに電子メールアドレス sandy+test1@example.com を使用するように指示した場合、ユーザーは、この別名に配信されるメールを、アドレスに送信されるメールの中から識別できます。デフォルトにより、sandy+test1@example.com の別名に送信されたメールはすべて、この別名と .forward+detail ファイルと突き合わせて検査されます。ここで一致しない場合は、そのメールは最終的に sandy@example.com に配信されますが、ユーザーは、これらのメールの To: メールヘッダー内の変更箇所を調べることができます。
このファイルは、sendmail のための初期設定用オプションを保存し、ホストをアップグレードしたときにオプションが除去されないようにするために使用します。次の変数を使用することができます。
クライアントデーモンで使用する追加オプションを選択します。クライアントデーモンは、クライアントだけのキュー (/var/spool/clientmqueue) の内容を確認し、クライアントキューランナーとして動作します。構文の検査は行われないため、この変数を変更するときは間違えないように注意してください。
CLIENTQUEUEINTERVAL には、QUEUEINTERVAL オプションと同様に、メールキューの実行間隔を設定します。ただし、CLIENTQUEUEINTERVAL オプションは、マスターデーモンではなくクライアントデーモンの機能を制御します。一般に、マスターデーモンはすべてのメッセージを SMTP ポートに配信できます。ただし、メッセージ負荷が高すぎる場合、またはマスターデーモンが実行されていない場合、メッセージはクライアントだけのキューである /var/spool/clientmqueue に入ります。次に、クライアントだけのキューをチェックするクライアントデーモンがクライアントキューを処理します。
SMTP クライアントとサーバーが、定期的なキューの実行を待たずに即座に対話を実行できるようにします。サーバーは、指定されたホストに送信されるキューを即座に配信できます。詳細は、etrn(1M) のマニュアルページを参照してください。
sendmail を起動するためのモードを選択します。-bd オプションを使用するか、未定義のままにしておきます。
マスターデーモンで使用される追加オプションを選択します。構文の検査は行われないため、この変数を変更するときは間違えないように注意してください。
マスターデーモンのメールキューの実行間隔を設定します。# は正の整数とし、そのあとに秒の場合は s、分の場合は m、時の場合は h、日の場合は d、週の場合は w を付けます。この構文は sendmail の起動前に確認されます。この間隔が負の場合、またはエントリの最後の文字が不適当な場合、この間隔は無視され、sendmail は 15 分のキュー間隔で起動します。
キューを実行するたびに新しいキューランナーを作成する代わりに、各実行の間に休止する単一の永続的なキューランナーを使用できるようにします。このオプションに設定可能な値は p だけです。p 以外に設定すると、このオプションは無効になります。
配信時にメールメッセージがたどる経路は、クライアントシステムの設定とメールドメインのトポロジによって異なります。メールホストやメールドメインの各追加レベルでは、別名のもう 1 つの解釈を追加できますが、ルーティングプロセスは基本的にほとんどのホストで同じになります。
クライアントシステムは、メールをローカルに受信できるようにセットアップできます。メールをローカルで受信することは、ローカルモードでの sendmail の実行として知られています。すべてのメールサーバーと一部のクライアントでは、ローカルモードがデフォルトです。ローカルモードのメールサーバーまたはクライアントでは、メッセージは次の要領でルーティングされます。
次の例では、sendmail.cf ファイルに設定されたデフォルトの規則を使用することを前提にしています。
可能な場合はメール別名を展開し、ローカルのルーティングプロセスを再起動します。
ネームサービスでメール別名を確認し、見つかった場合に新しい値と置換することで、メールアドレスが展開されます。次にこの新しい別名が再度確認されます。
メールがローカルの場合、/usr/lib/mail.local に配信されます。
メールはローカルのメールボックスに配信されます。
メールアドレスがこのメールドメインにホストを含んでいると、そのホストにメールを配信します。
アドレスがこのドメインにホストを含んでいない場合、メールホストにメールを転送します。
メールホストはメールサーバーと同じルーティングプロセスを使用します。ただし、メールホストはホスト名に加えて、ドメイン名が宛先になっているメールも受信できます。
ここでは、 sendmail とネームサービスに適用されるドメイン名について説明します。さらに、ネームサービスを有効に利用するための規則、および sendmail とネームサービスの相互作用について説明します。詳細は、次のトピックを参照してください。
関連する作業については、「sendmail で DNS を使用する方法」の 「メール別名ファイルの管理 (作業マップ)」または 第 13 章メールサービス (手順)を参照してください。
標準の sendmail.cf ファイルは、メールドメインを使ってメールを直接配信するか、あるいはメールホストを経由して配信するかを決定します。ドメイン内メールは直接 SMTP 接続経由で配信され、ドメイン間メールはメールホストに送られます。
セキュリティーの高いネットワークでは、ほんの少数の選ばれたホストだけが、外部宛てのパケットを生成する権限を与えられています。ホストがメールドメインの外部のリモートホストの IP アドレスを持っている場合も、SMTP 接続の確立は保証されません。標準の sendmail.cf では次のことを仮定しています。
現在のホストは、パケットを直接メールドメイン外のホストに送信する権限がない。
メールホストは、パケットを外部ホストに直接送信できる認可されたホストにメールを転送できる。実際には、メールホストが認可されたホストになることがある。
このように仮定すると、ドメイン間メールの配信または転送はメールホスト側の責任です。
sendmail は各種の要件をネームサービスに課します。これらの要件の理解を深めるために、この節では、まずメールドメインからネームサービスドメインへの関係について説明します。その次に個々の要件について説明します。次を参照してください。
NIS+(1)、nisaddent(1M)、および nsswitch.conf(4) のマニュアルページ
メールドメイン名はネームサービスドメイン名の接尾辞の 1 つでなければなりません。たとえば、ネームサービスのドメイン名が「A.B.C.D」ならば、メールドメイン名は次のうちのいずれかです。
A.B.C.D
B.C.D
C.D
D
メールドメイン名は、最初の確立時には、多くの場合、ネームサービスドメインと同じになります。ネームサービスドメインは、ネットワークが大きくなるにつれて、ネームサービスをより管理しやすくするために、より小さいドメインに分割することが可能です。他方、メールドメインは、多くの場合、一貫した別名を提供するために分割されないまま残ります。
ここでは、sendmail がネームサービスに必要とする要件について説明します。
ネームサービスにおけるホストテーブルまたはマップは、次の 3 種類の gethostbyname() による問い合わせをサポートするように設定しなければなりません。
mailhost – いくつかのネームサービスの構成では、自動的にこの要件を満たします。
完全なホスト名 (たとえば、smith.admin.acme.com) – 多くのネームサービスの構成がこの要件を満たします。
短いホスト名 (たとえば、smith) – sendmail は、外部メールを転送するためにメールホストに接続する必要があります。メールアドレスが現在のメールドメイン内であるかどうかを判定するために、gethostbyname() が完全なホスト名で呼び出されます。エントリが見つかると、アドレスは内部にあるとみなされます。
NIS、NIS+、および DNS は、短いホスト名を引数にする gethostbyname() をサポートします。したがって、この要件は自動的に満たされます。
ネームサービス内に有効な sendmail サービスを確立するために、ホストネームサービスに追加された次の 2 つの規則に従う必要があります。
完全なホスト名と短いホスト名の引数を持った gethostbyname() は、同一の結果を生成する必要があります。たとえば、両関数がメールドメイン admin.acme.com から呼び出された場合、gethostbyname (smith.admin.acme.com) と gethostbyname (smith) が同じ結果になるようにします。
共通のメールドメイン下のすべてのネームサービスドメインに対しては、短いホスト名による gethostbyname() で同じ結果を生じるようにします。たとえば、ebb.admin.acme.com ドメインおよび esg.admin.acme.com ドメインから smith.admin.acme.com メールドメインを呼び出した場合、どちらの場合も gethostbyname(smith) は同じ結果を返す必要があります。ネームサービスドメインはこの要件に各種ネームサービス用の特別な連携を与えているので、メールドメイン名は、通常ネームサービスドメインより短いです。
gethostbyname() 関数については、gethostbyname(3NSL) のマニュアルページを参照してください。
次に、sendmail と NIS との相互作用について説明し、ガイドラインを示します。
メールドメイン名 – NIS をプライマリネームサービスとして設定している場合に、sendmail は、自動的に NIS ドメイン名の最初の構成要素を取り除いた結果をメールドメイン名として使用します。たとえば、ebs.admin.acme.com は、admin.acme.com となります。
メールホスト名 – 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 ドメインでは無効になることがあります。
作業手順については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
次に、sendmail と NIS および DNS との相互作用について説明し、ガイドラインを示します。
メールドメイン名 – NIS をプライマリネームサービスとして設定している場合に、sendmail は、自動的に NIS ドメイン名の最初の構成要素を取り除いた結果をメールドメイン名として使用します。たとえば、ebs.admin.acme.com は、admin.acme.com となります。
メールホスト名 – DNS の転送機能がオンになっていれば、NIS で解決できない照会は DNS に転送されるため、NIS ホストマップに mailhost エントリは必要ありません。
完全なホスト名 – NIS が完全なホスト名を認識できなくても、DNS が認識します。NIS と DNS の通常の設定手順を踏んでいる場合には、完全なホスト名の要件は満たされます。
ホストの完全名および短縮名のマッチング – NIS のホストテーブルにおけるすべてのホストエントリに対して、DNS にも対応するホストエントリが必要です。
1 つのメールドメイン内の複数の NIS ドメイン – 共通のメールドメインの NIS のホストマップ中のホストのエントリは同じである必要があります。たとえば、ebs.admin.acme.com ドメインのホストマップは、esg.admin.acme.com のホストマップと同じものにします。異なる場合には、ある NIS ドメインで有効なアドレスがほかの NIS ドメインでは無効になることがあります。
作業手順については、「sendmail で DNS を使用する方法」の 「メール別名ファイルの管理 (作業マップ)」と 第 13 章メールサービス (手順)を参照してください。
次に、sendmail と NIS+ との相互作用について説明し、ガイドラインを示します。
メールドメイン名 – プライマリネームサービスとして NIS+ を設定していれば、sendmail は NIS+ の sendmailvars テーブルからメールドメインを確認できます。この NIS+ テーブルには、キー列と値列が 1 つずつあります。メールドメインを設定するには、 1 つのエントリをこのテーブルに追加する必要があります。このエントリは、キー列に文字列 maildomain が、値列には自分のメールドメイン名が設定されている必要があります。たとえば、admin.acme.com です。NIS+ では、sendmailvars テーブルにどのような文字列でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomain エントリを sendmailvars テーブルに追加できます。次の例では、メールドメインが NIS+ ドメインの接尾辞になっています。
nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain> |
メールホスト名 – NIS+ ホストテーブルには、mailhost エントリが必要です。
完全なホスト名 – NIS+ は完全なホスト名を「理解」します。通常の NIS+ の設定手順を行えば、この完全なホスト名の要件は満たされます。
ホストの完全名および短縮名のマッチング – この要件を満たすには、ホストテーブルでエントリをコピーします。または、ユーザーネームサービスのドメイン中の全ホストのエントリを、メールドメインレベルのマスターホストテーブルに入力します。
1 つのメールドメイン内の複数の NIS ドメイン – この要件を満たすには、すべてのホストテーブルのエントリをコピーします。または、ユーザーネームサービスのドメイン中の全ホストのエントリを、メールドメインレベルのマスターホストテーブルに入力します。事実上、論理的または物理的に複数のホストテーブルを 1 つのホストテーブルにマージすることになります。したがって、メールドメインを共有する複数のネームサービスドメインで同じホスト名を使用することはできません。
作業手順については、「メール別名ファイルの管理 (作業マップ)」の 第 13 章メールサービス (手順)を参照してください。
次に、sendmail と NIS+ および DNS との相互作用について説明し、ガイドラインを示します。
メールドメイン名 – プライマリネームサービスとして NIS+ を設定していれば、sendmail は NIS+ の sendmailvars テーブルからメールドメインを確認できます。この NIS+ テーブルには、キー列と値列が 1 つずつあります。メールドメインを設定するには、 1 つのエントリをこのテーブルに追加する必要があります。このエントリは、キー列に文字列 maildomain が、値列には自分のメールドメイン名が設定されている必要があります。たとえば、admin.acme.com です。NIS+ では、sendmailvars テーブルにどのような文字列でも設定できますが、メールシステムが正常に機能するように接尾辞の規則が適用されます。nistbladm を使用して、maildomain エントリを sendmailvars テーブルに追加できます。次の例では、メールドメインが NIS+ ドメインの接尾辞になっています。
nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain> |
メールホスト名 – ネットワークがホストデータベースのソースとして NIS+ と DNS の両方を使用しているときは、mailhost エントリを NIS+ あるいは DNS ホストテーブルのいずれかに置くことができます。NIS+ と DNS の両方をホストデータベースのソースとして /etc/nsswitch.conf ファイルに含めるようにしてください。
完全なホスト名 – NIS+ と DNS はどちらも、完全なホスト名を「理解」します。通常の NIS+ と DNS の設定手順を踏めば、この項目の要件は満たされます。
ホストの完全名および短縮名のマッチング – NIS+ ホストテーブルの全ホストエントリに対して、対応するホストエントリが DNS に必要です。
1 つのメールドメイン内の複数の NIS ドメイン – この要件を満たすには、すべてのホストテーブルのエントリをコピーします。または、ユーザーネームサービスのドメイン中の全ホストのエントリを、メールドメインレベルのマスターホストテーブルに入力します。
作業手順については、「メール別名ファイルの管理 (作業マップ)」の 「sendmail で DNS を使用する方法」と 第 13 章メールサービス (手順)を参照してください。
sendmail のこの新しいバージョンには多くの新機能が用意されていますが、FallBackSmartHost オプションがもっとも重要な追加機能です。このオプションにより、main.cf ファイルおよび subsidiary.cf ファイルを使用する必要がなくなります。main.cf ファイルは、MX レコードをサポートする環境で使用されていました。subsidiary.cf ファイルは、完全に動作する DNS がない環境で使用されていました。そのような環境では、スマートホストが MX レコードの代わりに使用されていました。FallBackSmartHost オプションは、統一された構成を提供します。このオプションは、すべての環境でもっとも優先順位の低い MX レコードのように動作します。このオプションは、有効である場合、メールが確実にクライアントに配信されるように、失敗した MX レコードのバックアップ (フェイルオーバー) として担う接続が保たれた (スマート) ホストを提供します。
version 8.13 の詳細については、次の各節を参照してください。
さらに、Solaris 10 1/06 以降のリリースでは、TLS (Transport Layer Security) を使用して SMTP を実行できます。次に説明します。
SMTP サーバーとそのクライアント間の通信は通常、どちらの側でも制御されたり信頼されたりしません。このようにセキュリティーが存在しないことにより、第三者は、サーバーとクライアントの間の通信を監視し、変更することさえ可能です。Solaris 10 1/06 以降のリリースでは、SMTP は sendmail の version 8.13 で Transport Layer Security (TLS) を使用して、この問題を解決できます。これにより SMTP サーバーおよびクライアントに対するサービスが拡張され、次の機能が実現されます。
インターネットでの機密性の高い認証された通信
盗聴や攻撃からの保護
TLS の実装は Secure Sockets Layer (SSL) プロトコルに基づいています。
STARTTLS は、TLS を使用して、セキュリティー保護された SMTP 接続を開始する SMTP キーワードです。このセキュリティー保護された接続は、2 台のサーバーの間、またはサーバーとクライアントの間で行われます。セキュリティー保護された接続は、次のように定義されます。
発信元電子メールアドレスと宛先電子メールアドレスが暗号化される。
電子メールメッセージの内容が暗号化される。
クライアントが STARTTLS コマンドを発行すると、サーバーは次のいずれかを使用して応答します。
220 Ready to start TLS
501 Syntax error (no parameters allowed)
454 TLS not available due to temporary reason
220 応答では、クライアントが TLS ネゴシエーションを開始する必要があります。501 応答は、クライアントが STARTTLS コマンドを正しく発行しなかったことを示します。STARTTLS はパラメータなしで発行されます。454 応答では、クライアントがルールセットの値を適用して、接続を受け入れるか維持するかどうかを決定する必要があります。
インターネットの SMTP インフラストラクチャーを維持するため、公的に使用されるサーバーは TLS ネゴシエーションを要求してはならないことに注意してください。ただし、私的に使用されるサーバーは、クライアントが TLS ネゴシエーションを実行するよう要求しても構いません。このような場合、サーバーは次のような応答を返します。
530 Must issue a STARTTLS command first |
530 応答は、 STARTTLS コマンドを発行して接続を確立するようクライアントに指示します。
認証とプライバシーのレベルが不十分である場合、サーバーまたはクライアントは接続を拒否できます。また、多くの SMTP 接続はセキュリティー保護されていないため、サーバーとクライアントはセキュリティー保護されていない接続を維持する場合があります。接続を維持するか拒否するかどうかは、サーバーとクライアントの構成により決まります。
TLS を使用して SMTP を実行するためのサポートは、デフォルトでは有効になっていません。TLS が有効になるのは、SMTP クライアントが STARTTLS コマンドを発行した場合です。SMTP クライアントがこのコマンドを発行する前に、sendmail が TLS を使用できるようにする証明書を設定する必要があります。「TLS を使用するよう SMTP を構成する」を参照してください。この手順には、新しい構成ファイルのオプションの定義と、sendmail.cf ファイルの再構築が含まれることに注意してください。
次の表で、TLS を使用して SMTP を実行するために使用される構成ファイルのオプションを説明します。これらのオプションを宣言する場合は、次の構文のどれかを使用します。
O OptionName=argument # 構成ファイル用
-O OptionName=argument # コマンド行用
define(`m4Name',argument) # m4 構成用
オプション |
説明 |
---|---|
CACertFile |
m4 名 : confCACERT 引数 : filename デフォルト値 : 未定義 1 つの CA 証明書を含むファイルを指定します。 |
CACertPath |
m4 名 : confCACERT_PATH 引数 : path デフォルト値 : 未定義 複数の CA の証明書が含まれるディレクトリへのパスを指定します。 |
ClientCertFile |
m4 名 : confCLIENT_CERT 引数 : filename デフォルト値 : 未定義 クライアントの証明書が含まれるファイルを指定します。sendmail がクライアントとして動作する場合にこの証明書が使用されることに注意してください。 |
ClientKeyFile |
m4 名 : confCLIENT_KEY 引数 : filename デフォルト値 : 未定義 クライアントの証明書に属する秘密鍵が含まれるファイルを指定します。 |
CRLFile |
m4 名 : confCRL 引数 : filename デフォルト値 : 未定義 X.509v3 認証に使用される、証明書の失効ステータスが含まれるファイルを指定します。 |
DHParameters |
m4 名 : confDH_PARAMETERS 引数 : filename デフォルト値 : 未定義 Diffie-Hellman (DH) パラメータが含まれるファイルを指定します。 |
RandFile |
m4 名 : confRAND_FILE 引数 : file:filename または egd:UNIX socket デフォルト値 : 未定義 file: 接頭辞を使用してランダムデータが含まれるファイルを指定するか、egd: 接頭辞を使用して UNIX ソケットを指定します。Solaris OS は乱数生成デバイスをサポートしているため、このオプションを指定する必要はありません。random(7D) のマニュアルページを参照してください。 |
ServerCertFile |
m4 名 : confSERVER_CERT 引数 : filename デフォルト値 : 未定義 サーバーの証明書が含まれるファイルを指定します。sendmail がサーバーとして動作する場合にこの証明書が使用されます。 |
Timeout.starttls |
m4 名 : confTO_STARTTLS 引数 : amount of time デフォルト値 : 1h STARTTLS コマンドに対する応答を SMTP クライアントが待機する時間を設定します。 |
TLSSrvOptions |
m4 名 : confTLS_SRV_OPTIONS 引数 : V デフォルト値 : 未定義 サーバーがクライアントから証明書を要求するかどうかを決定します。このオプションが V に設定されている場合、クライアント検証は行われません。 |
sendmail で SMTP による TLS の使用をサポートできるようにするには、次のオプションを定義してください。
CACertPath
CACertFile
ServerCertFile
ClientKeyFile
そのほかのオプションは必須ではありません。
次の表で、STARTTLS コマンドにより使用されるマクロを説明します。
表 14–14 TLS を使用して SMTP を実行するためのマクロ
次の表で、TLS を使用する SMTP 接続を、受け入れるか、継続するか、拒否するかを決定するルールセットを説明します。
表 14–15 TLS を使用して SMTP を実行するためのルールセット
ルールセット |
説明 |
---|---|
tls_server |
クライアントとして動作する場合、sendmail はこのルールセットを使用して、サーバーが現在 TLS によってサポートされているかどうかを判別します。 |
tls_client |
サーバーとして動作する場合、sendmail はこのルールセットを使用して、クライアントが現在 TLS によってサポートされているかどうかを判別します。 |
tls_rcpt |
このルールセットは、受取人の MTA の検証を必要とします。この受取人の制限により、DNS スプーフィングなどの攻撃が不可能になります。 |
TLS_connection |
このルールセットは、アクセスマップの RHS により指定された要件を、現在の TLS 接続の実際のパラメータに照合して確認します。 |
try_tls |
sendmail はこのルールセットを使用して、別の MTA への接続時に STARTTLS を使用できるかを判別します。MTA が適切に STARTTLS を実装できない場合、STARTTLS は使用されません。 |
詳細は、http://www.sendmail.org/m4/starttls.html を参照してください。
インターネットで動作するメールプログラムを定義する標準メールプロトコルとしては、SMTP はエンドツーエンドのメカニズムではありません。このプロトコルの制限により、SMTP を介した TLS のセキュリティーにはメールユーザーエージェントは含まれていません。メールユーザーエージェントは、ユーザーと (sendmail などの) メール転送エージェントの間のインタフェースとして動作します。
また、メールは複数のサーバーを経由してルーティングされる場合があります。SMTP のセキュリティーを完全にするには、SMTP 接続のチェーン全体に TLS のサポートが必要です。
最終的には、サーバーの各ペア、またはクライアントとサーバーのペアの間でネゴシエーションされる認証と機密性のレベルを考慮すべきです。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「認証サービス」を参照してください。
次の表に、sendmail の version 8.13 で追加されたコマンド行オプションを示します。コマンド行のほかのオプションについては、sendmail(1M) のマニュアルページを参照してください。
表 14–16 sendmail の version 8.13 で使用可能になったコマンド行オプション
オプション |
説明 |
---|---|
-D logfile |
この情報を標準出力に含めるのではなく、指定された logfile にデバッグ出力を送信します。 |
-q[!]Qsubstr |
隔離 reason の部分文字列である substr を持つ隔離されたジョブの処理を指定します。-Q reason オプションの説明を参照。!が追加された場合、このオプションは、この substr を持たない隔離されたジョブを処理します。 |
-Qreason |
この reason を持つ通常のキュー項目を隔離します。reason が指定されていない場合、隔離されるキュー項目が隔離されません。このオプションは、-q[!]Qsubstr オプションと連動します。substr は、reason の一部 (部分文字列) です。 |
次の表に、追加または改訂された構成ファイルオプションを示します。これらのオプションを宣言する場合は、次の構文のどれかを使用します。
O OptionName=argument # for the configuration file -O OptionName=argument # for the command line define(`m4Name',argument) # for m4 configuration |
オプション |
説明 |
---|---|
ConnectionRateWindowSize |
m4 名 : confCONNECTION_RATE_WINDOW_SIZE 引数 : number デフォルト値 : 60 受信接続を維持する秒数を設定します。 |
FallBackSmartHost |
m4 名 : confFALLBACK_SMARTHOST 引数 : hostname このオプションは、メールが確実にクライアントに配信されるように、失敗した MX レコードのバックアップ (フェイルオーバー) として担う接続が保たれたホストを提供します。 |
InputMailFilters |
m4 名 : confINPUT_MAIL_FILTERS 引数 : filename sendmail デーモンの入力メールフィルタを示します。 |
PidFile |
m4 名 : confPID_FILE 引数 : filename デフォルト値 : /var/run/sendmail.pid 今までのリリースのように、ファイルを開く前に、そのファイル名がマクロで展開されます。さらに、version 8.13 では、sendmail の終了時にファイルへのリンクが削除されます (unlinked)。 |
QueueSortOrder |
m4 名 : confQUEUE_SORT_ORDER 追加された引数 : none version 8.13 では、ソート順序を指定しない場合に none を使用します。 |
RejectLogInterval |
m4 名 : confREJECT_LOG_INTERVAL 引数 : period-of-time デフォルト値 : 3h (3 時間) 指定した period-of-time に対してデーモン接続が拒否された場合、その情報が記録されます。 |
SuperSafe |
m4 名 : confSAFE_QUEUE 短縮名 : s 追加された引数 : postmilter デフォルト値 : true postmilter が設定されている場合、sendmail は、すべての milters がメッセージの受付の信号を送るまで、キューファイルとの同期を延期します。この引数を有効にするには、sendmail が SMTP サーバーとして実行される必要があります。それ以外の場合、postmilter は true 引数を使用しているように動作します。 |
次の表に、追加または改訂された FEATURE() の宣言を示します。この m4 マクロは次の構文を使用します。
FEATURE(`name', `argument') |
FEATURE() の名前 |
説明 |
|
---|---|---|
conncontrol |
access_db ルールセットと連動して、受信 SMTP 接続の数を確認します。詳細は、/etc/mail/cf/README を参照してください。 |
|
greet_pause |
オープンプロキシと SMTP のスラミング保護を可能にする、greet_pause ルールセットを追加します。詳細は、/etc/mail/cf/README を参照してください。 |
|
local_lmtp |
デフォルトの引数は引き続き mail.local であり、今回の Solaris のリリースでの LMTP を使用できるメールプログラムです。ただし、version 8.13 で、LMTP を使用できる別のメールプログラムを使用する場合は、パス名を 2 番目のパラメータとして指定し、2 番目のパラメータに渡される引数を 3 番目のパラメータとして指定します。次に例を示します。
|
|
mtamark |
“TXT RRs による逆引き DNS でのメール転送エージェントのマーキング” (MTAMark) を試験的にサポートします。詳細は、/etc/mail/cf/README を参照してください。 |
|
ratecontrol |
access_db ルールセットと連動して、ホストに対する接続速度を制御します。詳細は、/etc/mail/cf/README を参照してください。 |
|
use_client_ptr |
この FEATURE() が有効になっている場合、ルールセット check_relay は $&{client_ptr} というこの引数で最初の引数を上書きします。 |
TCP ラッパーは、特定のネットワークサービスを要求するホストのアドレスをアクセス制御リスト (ACL) と突き合わせて検査することによるアクセス制御の実装方法を提供します。要求は、状況に応じて、許可されたり拒否されたりします。このアクセス制御メカニズムを提供する以外に、TCP ラッパーは、ネットワークサービスに対するホストの要求を記録します。これは、有用な監視機能です。アクセス制御のもとに置かれるネットワークサービスの例として、rlogind、telnetd、ftpd などがあります。
version 8.12 より、sendmail で TCP ラッパーが使用できるようになりました。この検査によってほかのセキュリティー対策が省略されることはありません。sendmail で TCP ラッパーを有効にすることにより、検査が追加され、ネットワーク要求元の妥当性が検証されてから要求が許可されます。hosts_access(4) のマニュアルページを参照してください。
inetd(1M) および sshd(1M) での TCP ラッパーは、Solaris 9 リリースからサポートされています。
ACL については、『Solaris のシステム管理 (セキュリティサービス)』の「アクセス制御リストによる UFS ファイルの保護」を参照してください。
version 8.12 より、sendmail に新しい構成ファイル /etc/mail/submit.cf が含まれるようになりました。この submit.cf ファイルを使用して、sendmail をデーモンモードではなく、メール配信プログラムモードで実行できます。デーモンモードとは異なり、メール配信プログラムモードでは root 権限は必要ありません。そのため、この新しいパラダイムを使用すると、セキュリティーが向上します。
submit.cf の機能については、次を参照してください。
sendmail は、MSP (メール配信プログラム) モードでは submit.cf を使って実行します。submit.cf は、電子メールを送信したり、ユーザー以外の mailx のようなプログラムによって呼び出したりすることができます。-Ac オプションおよび -Am オプションについては、sendmail(1M) のマニュアルページを参照してください。
submit.cf は、次の操作モードで使用します。
-bm デフォルトの操作モード
-bs 標準入力を使用して SMTP を実行する
-bt アドレスの解決に使用されるテストモード
submit.cf を使用している場合には、sendmail は SMTP デーモンとして動作しません。
submit.cf を使用している場合には、sendmail はクライアント専用のメールキューである /var/spool/clientmqueue を使用します。このキューにより、sendmail デーモンに配信されなかったメッセージが保持されます。クライアント専用キューにあるメッセージは、クライアントの「デーモン」によって配信されます。実際には、このデーモンが、クライアントキューを実行します。
デフォルトでは、sendmail は submit.cf を使用して、定期的に MSP キュー (クライアント専用キュー) である /var/spool/clientmqueue を実行します。
/usr/lib/sendmail -Ac -q15m |
次の事項に注意してください。
Solaris 9 より、submit.cf は自動的にインストールされます。
Solaris 9 以降をインストールする前に、submit.cf について計画および準備をする必要はありません。
構成ファイルを指定しないかぎり、sendmail は、必要に応じて、submit.cf を自動的に使用します。基本的に、sendmail は各タスクについて、submit.cf と sendmail.cf のどちらを使用するのが適切かを判断します。
submit.cf を変更することはできません。
構成ファイル sendmail.cf は、デーモンモードで使用します。このファイルを使用すると、sendmail は、メール転送エージェント (MTA) として動作します。sendmail は、root によって起動されます。
/usr/lib/sendmail -L sm-mta -bd -q1h |
sendmail.cf 特有のほかの機能については、次を参照してください。
デフォルトでは、sendmail.cf がメールキュー /var/spool/mqueue を実行します。
submit.cf が追加されたため、次の機能が変更されました。
sendmail の version 8.12 より、root だけがメールキューを実行できます。この変更の詳細は、mailq(1) のマニュアルページを参照してください。新しい作業手順については、「キューディレクトリの管理 (作業マップ)」を参照してください。
メール配信プログラムモードは、root 権限がなくても実行されるので、sendmail が特定のファイル (.forward ファイルなど) にアクセスできないことがあります。したがって、sendmail に -bv オプションを追加すると、ユーザーが誤解するような出力を発生させる可能性があります。回避策はありません。
8.12 より前のバージョンの sendmail では、sendmail をデーモンモードで実行しない場合は、受信メールの配信を防止することしかできませんでした。version 8.12 より、デフォルトの構成で、sendmail デーモンを実行しない場合、送信メールの配信もまた防止することができます。クライアントキューランナー (メール配信プログラム) を設定して、ローカル SMTP ポートのデーモンにメールを送信できるようにする必要があります。クライアントキューランナーが SMTP のセッションをローカルホストで開こうとした場合で、デーモンが SMTP ポートで待機していないときには、メールはキューにとどまります。デフォルトの構成では、デーモンが実行されます。そのため、デフォルト構成を使用する場合には、この問題は発生しません。ただし、デーモンを無効にした場合の解決方法については、 「sendmail.cf の代替構成を使ってメール配信を管理する方法」を参照してください。
次の表では、 sendmail の追加されたコマンド行オプションまたは推奨されないコマンド行オプションについて説明します。コマンド行のほかのオプションについては、sendmail(1M) のマニュアルページを参照してください。
表 14–19 sendmail の version 8.12 から追加されたまたは推奨されないコマンド行オプション
オプション |
説明 |
---|---|
オペレーションモードが初期メール配信を示していない場合でも、構成ファイル submit.cf を使用します。submit.cf についての詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。 |
|
オペレーションモードが初期メール配信を示している場合でも、構成ファイル sendmail.cf を使用します。詳細は、「sendmail の version 8.12 からの submit.cf 構成ファイル」を参照してください。 |
|
各キューのエントリ数を出力します。 |
|
コマンド行から送信されたメッセージが、初期送信のためでなく、中継のためであることを示します。アドレスが絶対パスではない場合は、メッセージは拒否されます。正規化は実行されません。ftp://ftp.sendmail.org で sendmail とともに配布しているリリースノートで説明しているように、将来のリリースでは、不適切な形式のメッセージが拒否される可能性があります。 |
|
指定された syslog メッセージに使用する識別子を タグ (tag) に設定します。 |
|
受信者にこの部分文字列 (substring) を含むジョブだけを処理します。オプションに ! を追加すると、受信者にこの部分文字列 (substring) を含まないジョブだけを処理します。 |
|
キュー ID にこの部分文字列 (substring) を含むジョブだけを処理します。オプションに ! を追加すると、キュー ID にこの部分文字列 (substring) を含まないジョブだけを処理します。 |
|
送信者にこの部分文字列 (substring) を含むジョブだけを処理します。オプションに ! を追加すると、送信者にこの部分文字列 (substring) を含まないジョブだけを処理します。 |
|
キューにあるメッセージをシステムコール fork を使用しないで一度処理し、フォアグラウンドでプロセスを実行します。fork(2) のマニュアルページを参照してください。 |
|
name で指定するキューグループにあるメッセージだけを処理します。 |
|
各キュー用にフォークされた子プロセスを使用して、キューに保存されているメッセージを指定した間隔で処理します。次にキューが実行されるまでの間、その子プロセスはスリープしています。この新しいオプションは -qtime に似ています。qtime は、定期的に子をフォークしてキューを処理します。 |
|
ftp://ftp.sendmail.org で sendmail とともに配付しているリリースノートで説明しているように、このオプションは version 8.12 以降では使用できません。メールユーザーエージェントでは、引数 -G を使用することをお勧めします。 |
次の表では、PidFile オプションおよび ProcessTitlePrefix オプションにおけるマクロ処理の追加引数について説明します。これらのオプションについては、sendmail(1M) のマニュアルページを参照してください。
表 14–20 PidFile オプションおよび ProcessTitlePrefix オプションの引数
マクロ |
説明 |
---|---|
${daemon_addr} |
0.0.0.0 などのデーモンアドレスを提供します。 |
${daemon_family} |
inet や inet6 などのデーモンファミリーを提供します。 |
${daemon_info} |
SMTP+queueing@00: 30:00 などのデーモン情報を提供します。 |
${daemon_name} |
MSA などのデーモン名を提供します。 |
${daemon_port} |
25 などのデーモンポートを提供します。 |
${queue_interval} |
キューを実行する間隔を提供します (00:30:00 など)。 |
次の表では、sendmail プログラムで使用するための追加マクロについて説明しています。マクロの値は、内部で割り当てられています。詳細は、sendmail(1M) のマニュアルページを参照してください。
表 14–21 sendmail に追加定義されたマクロ
マクロ |
説明 |
---|---|
${addr_type} |
現在のアドレスを、エンベロープの送信側または受信者アドレスと認定します。 |
${client_resolve} |
${client_name} の解釈処理コールの結果、 つまり OK、FAIL、FORGED、または TEMP を保持します。 |
${deliveryMode} |
DeliveryMode オプションの値ではなく、sendmail が使用している現在のデリバリモードを指定します。 |
${dsn_notify}、${dsn_envid}、${dsn_ret} |
対応する DSN パラメータ値を保持します。 |
${if_addr} |
インタフェースがループバックネット上にない場合に、受信接続用インタフェースのアドレスを提供します。このマクロは、特に仮想ホスティングに便利です。 |
${if_addr_out}、${if_name_out}、${if_family_out} |
${if_addr} の再利用を避けます。次の値を、それぞれ保持します。 送信接続用インタフェースのアドレス 送信接続用インタフェースのホスト名 送信接続用インタフェースのファミリ |
${if_name} |
受信接続用のインタフェースのホスト名を提供します。これは、特に仮想ホスティングに便利です。 |
${load_avg} |
実行キューにあるジョブの現在の平均数を確認して報告します。 |
${msg_size} |
ESMTP ダイアログにあるメッセージサイズの値 (SIZE=parameter) を保持してから、メッセージを収集します。その後、sendmail によって計算されたメッセージサイズを保持したマクロを check_compat で使用します。check_compat については、表 14–25 を参照してください。 |
${nrcpts} |
妥当性検査を行なった受信者の数を保持します。 |
${ntries} |
配信を試みた回数を保持します。 |
${rcpt_mailer}、${rcpt_host}、${rcpt_addr}、${mail_mailer}、${mail_host}、および ${mail_addr} |
引数 RCPT および MAIL を構文解析した結果を保持します。つまり、メール配信エージェント ($#mailer)、ホスト ($@host)、およびユーザー ($:addr) から解釈処理された RHS (Right-Hand Side) トリプレットを保持します。 |
この節では、構成ファイル sendmail を構築するのに使用する追加マクロについて説明した表を示します。
表 14–22 構成ファイル sendmail を構築するのに使用する追加マクロ
マクロ |
説明 |
---|---|
LOCAL_MAILER_EOL |
ローカルメールプログラムの行末を示すデフォルト文字列を置きかえます。 |
LOCAL_MAILER_FLAGS |
デフォルトで Return-Path: ヘッダーを追加します。 |
MAIL_SETTINGS_DIR |
メール設定ディレクトリのパスを格納します (末尾のスラッシュを含む)。 |
MODIFY_MAILER_FLAGS |
*_MAILER_FLAGS を拡張します。このマクロは、フラグを設定、追加、または削除します。 |
RELAY_MAILER_FLAGS |
中継メールプログラムの追加フラグを定義します。 |
次のマクロを使用して、受け入れ可能なコマンドを最大数設定し、sendmail による配信の遅れを防止することができます。これらの MAX マクロは、コンパイル時に設定できます。次の表にある最大値は、現在のデフォルト値でもあります。
表 14–23 追加された MAX マクロ
マクロ |
最大値 |
各マクロが検査するコマンド |
---|---|---|
25 |
未知のコマンド |
|
20 |
NOOP、VERB、ONEX、XUSR |
|
3 |
HELO、EHLO |
|
6 |
VRFY、EXPN |
|
8 |
ETRN |
マクロによる確認を無効にするには、マクロの値を 0 に設定します。
この節では、sendmail において追加または改訂された m4 構成マクロの表を示します。これらのマクロを宣言するには、次の構文を使用します。
symbolic-name(`value') |
新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
表 14–24 sendmail において追加または改訂された m4 構成マクロ
m4 マクロ |
説明 |
---|---|
FEATURE() |
詳細は、「sendmail の version 8.12 からの FEATURE() の宣言についての変更点」を参照してください。 |
このマクロは、クラス w ($=w) にエントリを追加します。 |
|
マスカレードできないホストやサブドメインを定義する新しいマクロ。 |
|
このマクロは user@[host] のように、括弧で囲まれたアドレスに使用できます。 |
|
これらのマクロを使用する場合は、$=R に $={VirtHost} を含めます。$=R は、中継が許可された一連のホスト名です。 |
FEATURE() の宣言についての変更点については、次の表を参照してください。
FEATURE の新しい名前および改訂された名前を使用するには、次の構文を使用します。
FEATURE(`name', `argument') |
新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
表 14–25 追加または改訂された FEATURE() の宣言
FEATURE() の名前 |
説明 |
---|---|
引数 : 次の段落の例を参照してください。 この新しい FEATURE() によって、送信者アドレスと受信者アドレスからなるアクセスマップ内でキーを検索できます。この FEATURE() は、文字列 <@> で区切ります。たとえば、sender@ sdomain<@>recipient @rdomain のようにします。 |
|
引数 : friend にすると、スパムメールの friend テストを実行できます。また、hater にすると、スパムメールの hater テストを実行できます。 すべての検査作業を遅らせる新しい FEATURE()。FEATURE(`delay_checks') を使用すると、クライアントが接続する場合、またはクライアントが MAIL コマンドを発行する場合に、ルールセット check_mail および check_relay は呼び出されません。代わりに、これらのルールセットはルールセット check_rcpt によって呼び出されます。詳細については、/etc/mail/cf/README ファイルを参照してください。 |
|
引数 : この FEATURE() は、最大次の 2 つの引数を受け入れます。
DNS 参照の戻り値を検査する回数を複数にできる新しい FEATURE()。この FEATURE() を使用して、参照が一時的に失敗した場合の動作を指定できます。 |
|
引数 : ドメイン名。 dnsbl の強化バージョンの新しい FEATURE() 。この FEATURE を使用して、DNS 参照の戻り値を検査できます。詳細は、/etc/mail/cf/README を参照してください。 |
|
引数 : なし。 genericstable を $=G のサブドメインに適用するのにも使用できる新しい FEATURE()。 |
|
引数 : 詳細は、http://www.sendmail.org の「リリースノート」を参照してください。 LDAP アドレスルーティングを実装する新しい FEATURE()。 |
|
引数 : LMTP (Local Mail Transfer Protocol) を使用できるメールプログラムのパス名。デフォルトは mail.local であり、今回の Solaris リリースでは LMTP を使用できます。 ローカルメールプログラムの DSN (delivery status notification) 診断コードのタイプを SMTP の正しい値に設定する FEATURE()。 |
|
引数 : なし。 ローカルメールプログラムをマスカレードしないようにするために使用する新しい FEATURE()。 |
|
引数 : なし。 アクセスマップの .domain を参照するのに使用する新しい FEATURE()。 |
|
引数 : canonify_hosts またはなし。 FEATURE() には次の機能が含まれます。 CANONIFY_DOMAIN または CANONIFY_DOMAIN_FILE で指定した、ドメインのリストを演算子 $[ および $] に渡して正規化することができます。 canonify_hosts がそのパラメータとして指定されている場合には、<user@host> など、ホスト名だけを含むアドレスを正規化できます。 複数のコンポーネントを持つアドレスの末尾にドットを追加できます。 |
|
引数 : なし。 sendmail のデフォルト設定を m4 構成ファイルでオフにする新しい FEATURE()。このファイルは、複数の異なるポート上で待機するために生成されたもので、RFC 2476 に実装されています。 |
|
引数 : reject にすると、! トークンを使用できません。 nospecial にすると、! トークンを使用できます。 ! トークンをアドレスのローカルの部分に使用するかどうかを決定する FEATURE()。 |
|
引数 : なし。 通常の構成ですべてのルールセットを提供する FEATURE()。スパムメール対策チェックを実行します。 |
|
引数 : なし。 sendmail がアドレスをローカル配信エージェントに渡す際に、アドレスの +detail の部分を保存できる新しい FEATURE()。 |
|
引数 : なし。 LUSER_RELAY を使用している場合に、受信者のホスト名を保存できる新しい FEATURE()。 |
|
引数 : なし。 電子メールのアドレス全体または受信者のドメインに基づいたキューグループを選択できる新しい FEATURE()。 |
|
引数 : ドメインは、任意の引数です。 メールの送信側がアクセスマップに RELAY として指定されており、それをヘッダー行 From: でタグ付けされている場合に、リレーを許可する新しい FEATURE()。省略可能な引数 domain を指定すると、メール送信側のドメイン部も検査されます。 |
|
引数 : なし。 $={VirtHost} を適用するのに使用する FEATURE()。$={VirtHost} は、VIRTUSER_DOMAIN または VIRTUSER_DOMAIN_FILE を使って生成できる virtusertable エントリを一致させるための新しいクラス。 また、FEATURE(`virtuser_entire_domain') を使用して、クラス $={VirtHost} をサブドメイン全体に適用することもできます。 |
次の FEATURE () 宣言はサポートされなくなりました。
表 14–26 宣言がサポートされていない FEATURE()
MAILER() を宣言すると、配信エージェントのサポートを指定できます。配信エージェントを宣言するには、次の構文を使用します。
MAILER(`symbolic-name') |
次の変更に注意してください。
この新しいバージョンの sendmail では、MAILER(`smtp') を宣言すると、メールプログラム dsmtp が追加されます。dsmtp により、メールプログラムのフラグ F=% を使用して、オンデマンドに配信することができます。dsmtp メールプログラムを定義する際には、新しい DSMTP_MAILER_ARGS を使用します。DSMTP_MAILER_ARGS のデフォルトは IPC $h です。
MAILER によって使用されるルールセットの番号は削除されました。MAILER(`uucp') を除いて、MAILER の表示順を自由に設定できます。uucp-dom および uucp-uudom を使用する場合には、MAILER(`smtp') のあとに MAILER(`uucp') を配置する必要があります。
メールプログラムの詳細は、「メールプログラムと sendmail」を参照してください。新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
次の表では、配信エージェントの追加されたフラグについて説明しています。デフォルトでは、これらのフラグは設定されていません。これらの 1 文字のフラグはブール型です。このフラグを設定したりその設定を解除したりするには、次の例のように、フラグを構文ファイルの F= 文に含めるか除外します。
Mlocal, P=/usr/lib/mail.local, F=lsDFMAw5:/|@qSXfmnz9, S=10/30, R=20/40, Mprog, P=/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/, Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990, Msmtp8, P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990, Mrelay, P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040, |
フラグ |
説明 |
---|---|
% |
このフラグを使用するメールプログラムは、ETRN 要求や次のいずれかのキューオプションを使ってキューにあるメッセージを選択しないかぎり、最初の受信者宛にメールを配信したり、キューを実行したりしません。 -qI、-qR、または -qS。 |
1 |
このフラグは、\0 などのヌル文字を送信するメールプログラムの機能を無効にします。 |
2 |
このフラグは、ESMTP の使用を無効にし、代わりに SMTP を使用するように要求します。 |
6 |
このフラグを指定すると、メールプログラムでヘッダーを 7 ビットにすることができます。 |
次の表では、配信エージェントを定義するコマンド M とともに使用できる新しい設定について説明しています。次の構文は、設定を新たに付加する方法、および構成ファイルの既存の設定に新しい引数を付加する方法を示しています。
Magent-name, equate, equate, ... |
次の例には、新しい設定 W= が含まれています。この設定は、すべてのデータが送信されたあとでメールプログラムが戻るまでの最長待ち時間を指定します。
Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, W=2m |
m4 の構成値の定義を変更するには、次の例のような構文を使用します。
define(`SMTP_MAILER_MAXMSGS', `1000') |
この例では、smtp メールプログラムで 1 回の接続で配信されるメッセージ数を 1000 に制限しています。
新しい sendmail.cf ファイルを構築する必要がある場合は、「sendmail 構成を変更する」の 第 13 章メールサービス (手順)を参照してください。
通常、mailer ディレクトリで、この設定の定義を変更するのは、微調整が必要な場合だけです。
本リリースでは、複数のキューディレクトリをサポートしています。複数のキューを使用するには、次の例のように、アスタリスク (*) で終わっている QueueDirectory オプション値を構成ファイルに追加します。
O QueueDirectory=/var/spool/mqueue/q* |
このオプション値 /var/spool/mqueue/q* は、「q」で始まっているすべてのディレクトリ (またはディレクトリへのシンボリックリンク) をキューのディレクトリとして使用します。sendmail の実行中には、キューのディレクトリ構造を変更しないでください。キューを実行すると、デーモン以外のキューの実行時に冗長フラグ (-v) を使用しないかぎり、各キューについての実行プロセスが作成されます。この新しい項目が、無作為にキューに割り当てられます。
この新しいキューのファイルの名前付けシステムで使用する名前は、60 年間一意であることが保証されます。このシステムでは、キュー ID が複雑なファイルシステムのロックを使用しないで割り当てられるため、キューにある項目を簡単にほかのキューに移動することができます。
version 8.12 より、root だけがメールキューを実行できます。この変更の詳細は、mailq(1) のマニュアルページを参照してください。新しい作業手順については、「キューディレクトリの管理 (作業マップ)」を参照してください。
エンベロープの分割に対応するために、キューファイルの名前は 14 文字ではなく、15 文字にします。14 文字までの名前を持つファイルシステムは、サポートされません。
作業手順については、「キューディレクトリの管理 (作業マップ)」を参照してください。
次に、LDAP (Lightweight Directory Access Protocol) を sendmail で使用する際の変更点について説明します。
LDAPROUTE_EQUIVALENT() および LDAPROUTE_EQUIVALENT_FILE() を使用して、同じホスト名を指定することができます。これらのホスト名は、LDAP ルーティング参照のマスカレードドメイン名と置き換えられます。詳細は、/etc/mail/cf/README を参照してください。
ftp://ftp.sendmail.org で sendmail とともに配布しているリリースノートで説明しているように、LDAPX マップの名前は LDAP に変更されました。LDAP には、次の構文を使用します。
Kldap ldap options |
本リリースでは、一度の LDAP 参照に複数の値を返すことができます。次の例のように、返す値を -v オプションを付加したコンマ区切りの文字列に配置します。
Kldap ldap -v"mail,more-mail" |
LDAP マップの宣言で LDAP 属性が指定されていない場合は、一致した属性がすべて返されます。
このバージョンの sendmail は、LDAP 別名ファイルに指定された引用符などで囲まれたキーや値の文字列内のコンマによって、1 つのエントリが複数のエントリに分割されるのを防止します。
このバージョンの sendmail には、LDAP マップ用の新しいオプションがあります。この -Vseparator オプションを使用して、区切り文字を指定できます。そのため、検索を行うと、該当する separator によって区切られた属性と値の両方を返すことが可能です。
%s トークンを使用した LDAP フィルタ指定の構文解析に加えて、新しいトークンである %0 を使用して、キーバッファーを符号化することもできます。%0 トークンは、LDAP の特殊文字に対して、文字どおりの意味を適用します。
次の例では、これらのトークンが「 *」検索でどのように違うかを説明します。
表 14–29 トークンの比較
LDAP のマップ指定 |
同等の指定 |
結果 |
---|---|---|
-k"uid=%s" |
-k"uid=*" |
ユーザー属性を持つ任意のレコードに一致します |
-k"uid=%0" |
-k"uid=\2A" |
「 *」という名前を持つユーザーに一致します |
次の表では、LDAP マップの追加されたフラグについて説明しています。
表 14–30 LDAP マップの追加されたフラグ
フラグ |
説明 |
---|---|
-1 |
一致したレコードが 1 つだけだった場合、そのレコードを返します。複数のレコードが一致して返される場合には、結果として、レコードが検出されなかったことと同じとなります。 |
-r never|always|search|find |
LDAP 別名の参照を解除するオプションを設定します。 |
-Z size |
一致したもののうち、返すレコード数を制限します。 |
前のバージョンに組み込まれていたメールプログラム [TCP] は使用できません。代わりに、新しく組み込まれたメールプログラム P=[IPC] を使用してください。プロセス間通信 ([IPC]) 組み込みメールプログラムで、それをサポートするシステム上の UNIX ドメインソケットへの配信を行えるようになりました。このメールプログラムは、指定したソケットで待機している LMTP 配信エージェントとともに使用できます。次に、メールプログラムの例を示します。
Mexecmail, P=[IPC], F=lsDFMmnqSXzA5@/:|, E=\r\n, S=10, R=20/40, T=DNS/RFC822/X-Unix, A=FILE /var/run/lmtpd |
[IPC] メールプログラムの最初の引数の値が妥当であるか検査されるようになりました。次の表では、最初のメールプログラム引数に設定可能な値について説明しています。
表 14–31 最初のメールプログラム引数に設定可能な値
値 |
説明 |
---|---|
A=FILE |
UNIX ドメインソケットによる配信に使用します。 |
A=TCP |
TCP/IP 接続に使用します。 |
A=IPC |
最初のメールプログラム引数としては使用できません。 |
次の表では、追加されたルールセットとその動作について説明しています。
表 14–32 新しいルールセット
ルールセット |
説明 |
---|---|
ヘッダーから収集した情報を相関させ、欠けているヘッダーを検査します。このルールセットは、マクロストレージマップとともに使用し、すべてのヘッダーが収集されたあと、呼び出されます。 |
|
check_rcpt が RCPT を使用するように、ETRN コマンドを使用します。 |
|
check_rcpt が RCPT を使用するように、EXPN コマンドを使用します。 |
|
check_rcpt が RCPT を使用するように、VRFY コマンドを使用します。 |
次に、ルールセットの追加機能について説明します。
番号が付けられたルールセットには、名前も付けられました。ただし、これらのルールセットに、番号でアクセスすることもできます。
H ヘッダー構成ファイルコマンドを使用して、デフォルトルールセットを指定し、ヘッダーを確認することができます。各ヘッダーに、独自のルールセットが割り当てられていない場合にだけ、このルールセットが呼び出されます。
ルールセット内のコメント、つまり括弧内のテキストは、構成ファイルのバージョンが 9 かそれ以上である場合には削除されません。たとえば、次のルールは、入力 token (1) を照合します。ただし、入力 token は照合しません。
R$+ (1) $@ 1 |
TCP ラッパーまたは check_relay ルールセットが原因でコマンドを拒否する場合でも、sendmail は SMTP RSET コマンドを受け入れます。
OperatorChars オプションを何度も設定すると、警告が送信されます。また、ルールセットを定義したあとで OperatorChars を設定しないでください。
無効なルールセットを宣言すると、行だけでなく、そのルールセットの名前も無視されます。そのルールセットの行は S0 に追加されません。
Solaris 10 以降のリリースでは、読み取り専用の /usr ファイルシステムをサポートするために、/usr/lib/mail ディレクトリの内容が /etc/mail/cf ディレクトリに移動されました。詳細は、「/etc/mail/cf ディレクトリの内容」を参照してください。ただし、シェルスクリプト /usr/lib/mail/sh/check-hostname および /usr/lib/mail/sh/check-permissions は、/usr/sbin ディレクトリに置かれるようになりました。「メールサービスに使用するその他のファイル」を参照してください。下位互換性を確保するために、シンボリックリンクが各ファイルの新しい位置を示します。
/usr/lib/mail/cf/main-v7sun.mc の新しい名前は /etc/mail/cf/cf/main.mc です。
/usr/lib/mail/cf/subsidiary-v7sun.mc の新しい名前は /etc/mail/cf/cf/subsidiary.mc です。
helpfile は /etc/mail/helpfile にあります。古い名前 (/etc/mail/sendmail.hf) には、新しい名前へのシンボリックリンクがあります。
trusted-users ファイルは /etc/mail/trusted-users にあります。アップグレード中に、新しい名前は検出されず、古い名前である /etc/mail/sendmail.ct が検出されると、古い名前から新しい名前へのハードリンクが作成されます。それ以外の場合には、変更されません。デフォルトの内容は、root です。
local-host-names ファイルは /etc/mail/local-host-names にあります。アップグレード中に、新しい名前は検出されず、古い名前である /etc/mail/sendmail.cw が検出されると、古い名前から新しい名前へのハードリンクが作成されます。それ以外の場合には、変更されません。デフォルトの内容は、ゼロ長です。
sendmail の version 8.12 より、アドレスを正しく識別するために、構成に使用する IPv6 アドレスの前に IPv6: タグを付ける必要があります。IPv6 アドレスを識別しない場合は、タグを前に付けません。