-----BEGIN PGP SIGNED MESSAGE----- ====================================================================== JPCERT-ED-2001-0002 JPCERT/CC 技術メモ - sendmail バージョンアップマニュアル 初 版: 1998/01/30 (Ver.01) 発 行 日: 2001/12/27 (Ver.11) 最新情報: http://www.jpcert.or.jp/ed/2001/ed010002.txt ====================================================================== 目 次 I. はじめに II. sendmail.cf とバージョン III. OSベンダによる独自拡張 IV. コンパイル 1) sendmail の配布パッケージを取得する 2) パッケージの展開 3) WIDE 版パッチについて 4) コンパイルの準備 5) コンパイルの開始 V. サービススイッチファイルの設定 VI. sendmail のテスト 1) sendmail.cf にエラーがないことの確認 2) ホスト名が正しく取得できていることの確認 3) ローカルへのメール配信が正常なことを確認 4) メールのリモートへの配信が正常なことを確認 5) ファイルやディレクトリのパーミッションに関する設定および確認 6) システムファイルの内容に関する確認 VII. sendmail のインストール VIII. sendmail の再起動 IX. (付録) PGP署名の検証 X. 参考資料 I. はじめに sendmail [1] [2] [3] のバージョンアップはおもに時代の流れに則した仕 様変更や機能拡張のために行なわれていますが、中には新たに報告されたセキュ リティホールを塞ぐためのバージョンアップも存在します。sendmail の最新 バージョンは 8.12.1 です(2001年11月30日現在)。できるだけ新しいバージョ ンの sendmail を利用されることをお勧めします。sendmail 8.9 からは SPAM 対策に関する機能が強化されています。sendmail 8.12 からは sendmail プロ グラムに set-user-id ビットを立てないような設定もできるようになってい ます。 sendmail R8 のバージョン番号は 8.x.y という形式で表されます。機能拡 張が行われた場合は x が加算され、仕様変更を伴わない minor bug fix (セ キュリティ上の修正を含む) の場合は、基本的に y が加算されていきます。 インストールされている sendmail がどのバージョンであるかは、sendmail の起動時に -d0.1 スイッチを与えることによって知ることができます (sendmail 8.9 以降では sendmail -d0.101 を指定すれば、バージョン情報だ けが表示されます)。 % sendmail -d0.1 -bv Version 8.12.1 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MIME7TO8 MIME8TO7 : % sendmail -d0.101 (sendmail 8.9 以降の場合のみ) Version 8.12.1 セキュリティ上の修正が行なわれたのがどのバージョンであるかを知るには、 sendmail の配布パッケージに含まれる RELEASE_NOTES を参照して下さい。修 正項目の先頭に、SECURITY: と印が付されています (バグフィックスでないセ キュリティ機能の強化を含む)。また CERT Advisory 等の文書から確認するこ ともできるでしょう(例えば [7] [8] [9] など)。 sendmail のセキュリティホールは大きく次の2つに分類されます。 ・アクセス権のない部外者のネットワークからの侵入を許してしまうもの ・ホストにログイン可能な一般ユーザが root 権限を詐取したり、読めな いはずのファイルが読めてしまうもの sendmail R5 については、一般的に用いられているファイアウォールですら 防衛できないセキュリティホールが広く知られています[6]。sendmail 8.8.5 より古いバージョンにはネットワークからの不正な操作を許す余地のあるセキュ リティホールが報告されています[10]。さらに、sendmail 8.12.1 より古いバー ジョンでは、いくつかの OS でローカルユーザがメイルキューに関する情報を 不正に入手できる可能性が指摘されています。 II. sendmail.cf とバージョン 最新の sendmail をインストールする際、sendmail.cf も同時に最新のもの にすべきことは言うまでもありません。sendmail のバージョンアップととも に sendmail.cf にも機能拡張や不具合の修正が施されています。ただ、 sendmail.cf を置き換える作業を行なう余裕がなく、かつ III 章に示すよう な OS ベンダ独自の拡張を利用していない場合は、従来の sendmail.cf をそ のまま使い続けることも可能です。sendmail.cf にもバージョンの区別があり、 sendmail のドキュメントではこれを「バージョンレベル」と呼んでいます。 sendmailは、sendmail.cf のバージョンレベルを調べ、それに相応しいように 動作を切り換えます。新しい sendmail の機能は、新しいバージョンレベルの sendmail.cf を用いることによって柔軟に設定することができますが、古い sendmail.cf を利用する場合は、従来の sendmail と互換性のある動作をする ように不足しているパラメータが補われます。従って、最低限のバージョンアッ プ作業は、sendmail のバイナリファイルを置き換えるだけになります。 sendmail.cf のバージョンレベルは、V で始まる行で定義されます。V で始 まる行が存在しない場合は V1 相当となります。sendmail 8.12.1 で利用可能 な最新の sendmail.cf のバージョンレベルは V10 です。sendmail 8.9 以降 では、古いバージョンレベルの sendmail.cf を利用している場合に warning メッセージが出力され、管理者に注意を促します。以下はバージョンレベル V9 の sendmail.cf を使って sendmail 8.12.1 を起動した場合の出力です。 Warning: .cf file is out of date: sendmail 8.12.1 supports version 10, .cf file is version 9 なお、sendmail 8.10 からは sendmail.cf や aliases など sendmail の設 定に関連するファイルの置き場所として /etc/mail/ が想定されています。OS によっては、標準添付の sendmail が参照するディレクトリとは異なる場合が あるので、注意が必要です。 sendmail 8.12 より以前の sendmail プログラムでは、root 権限で動作す るよう、root を所有者として set-user-id ビットを設定する必要がありまし た。これはデーモンとして動作する場合に tcp/25 番ポートを開いて外部から の接続を待ち受けたり、一般ユーザが利用する MUA から直接起動されてメッ セージを送信待ちキューに書き込んだりする場合のためです。一般に root 権 限で動作するよう set-user-id ビットを設定されたプログラムには、なんら かの脆弱性が発見された場合に root 権限が悪用される危険があります。そこ で sendmail 8.12 からは、MTA として SMTP 接続を待ち受けて処理する機能 と、MUA から起動されてメッセージ送信処理を行ない終了する機能の二つに対 して異なる設定ファイルを利用するようになりました。このような設定で利用 する場合には sendmail プログラムに set-user-id ビットを設定する必要が なくなっています。本技術メモでは sendmail プログラムの更新に関する説明 しか扱っていませんので、詳細に関しては sendmail-8.12.1/sendmail/SECURITY をご参照ください。 III. OSベンダによる独自拡張 sendmail をバージョンアップする際に、特に気をつけなければならないこ とがあります。それは、OS ベンダによって独自拡張されている sendmail を 利用している場合です。ベンダによっては、オリジナルの sendmail が持たな い機能を独自に実装し、sendmail.cf に拡張機能を利用するように記述してい ることがあります。従って、sendmail.cf を変更しないまま、ベンダによって 独自に拡張された sendmail をオリジナルの sendmail の最新版にバージョン アップしてしまうと、それまで利用していた OS 付属の sendmail.cf と整合 性がとれず、うまく動作しない可能性があります。 最新の sendmail の機能を利用することによって、ベンダによる独自拡張と 同様の機能が実現できる場合は、sendmail.cf を最新の sendmail に合わせて 書き換える必要があります。それが困難な場合は、各 OS ベンダが提供するパッ チを入手することで sendmail のバージョンアップを行います。OS ベンダが 提供するセキュリティ関連のパッチに関する情報は、ベンダから直接入手する ことができますが、前述の CERT Advisory などにも掲載されています。 IV. コンパイル 以下では、sendmail.cf は変更せず、sendmail という名前のバイナリファ イルを置き換えることによるバージョンアップ作業について説明します。従っ て、バージョンアップ作業は sendmail のコンパイルから開始することになり ます。なお、sendmail 8.9 以降では SPAM 対策機能が強化されていると言わ れていますが、その機能を効果的に利用するためには、sendmail.cf の変更も 必要です。 コンパイル作業の詳細や OS 毎の注意点などに関しては [4] もご 参照ください。 1) sendmail の配布パッケージを取得する sendmail の最新版は、以下の Anonymous ftp サーバ等から取得可能で す。 ftp://ftp.sendmail.org/pub/sendmail/ 取得するファイルは以下のものです (sendmail 8.12.1 を入手する場合)。 sendmail.8.12.1.tar.gz sendmail.8.12.1.tar.sig sendmail.8.12.1.tar.sig は、配布パッケージが改変されていないこと を確認するための (sendmail.8.12.1.tar に対する) PGP 電子署名です。 PGP プログラムと署名検証用の公開鍵を持っていれば、配布パッケージ が改変されていないことを確認することができます。署名検証手順につ いては 「IX.(付録) PGP署名の検証」を参照してください。 2) パッケージの展開 sendmail のパッケージは tar コマンドによりアーカイブされています ので、次のコマンドを実行してパッケージを展開します。 % gzip -d sendmail.8.12.1.tar.gz (すでに実行済みなら不要) % tar xvf sendmail.8.12.1.tar これにより、sendmail-8.12.1 という名前のディレクトリが作成され、 その中にパッケージが展開されます。実際には sendmail 以外にもいく つかのプログラムのソースコードがそれぞれのディレクトリの下に展開 されます。sendmail 本体のソースコードは sendmail-8.12.1/sendmail/ の下にあります。展開終了後、次のコマンドを実行して移動します。 % cd sendmail-8.12.1/sendmail/ 3) WIDE 版パッチについて 現在配布されている「WIDE 版パッチ」は、主に特殊な配信処理を実現す る機能拡張を行なうためのものであり、一般的なワークステーションに インストールされる sendmail には不要なものです。従って、「WIDE 版 パッチ」は、それによって実現される機能の必要性を十分に理解した上 で利用するようにして下さい。「WIDE 版パッチ」に関する情報は、 http://www.kyoto.wide.ad.jp/mta/sendmail.html を参照してください [5]。 4) コンパイルの準備 コンパイルには、ディレクトリ sendmail-8.12.1/sendmail/ に用意され ている Build というスクリプトを利用します。(Build は sendmail 8.8 までの makesendmail に置き換わるものです。コンパイル作業に関する 詳細な説明は、sendmail ディレクトリにある README ファイルにもあり ますので、一読をお勧めします)。 Build は、コンパイルを行おうとしている OS の種類を判定するととも に、その OS に対応したコンパイル環境を構築し、実際にコンパイルす るところまでを行なうスクリプトです。コンパイル環境は、 sendmail-8.12.1/obj.[OS の種類]/ というディレクトリに用意されます。 また、sendmail に組み込むことが可能なオプショナルなライブラリ (NEWDB や BIND8 など) は自動検出されます。ここでは、次のコマンド を実行して下さい。 % sh Build NEWDB や BIND8 等が /usr/local 以下にインストールされている場合は、 次のようにパスを指定することができますので、環境に応じて指定して ください (相対パスを指定するとうまくいきません)。 % sh Build -I/usr/local/include -L/usr/local/lib sendmail-8.12.1/obj.[OSの種類]/sendmail/ ディレクトリの中に生成さ れる Makefile を調整したい場合は、siteconfig ファイルを用意します。 siteconfig ファイルは、Build から参照され、生成される Makefile に 反映されます。siteconfig ファイルは Build の起動時に、-f siteconfig というオプションを指定することもできますが、 devtools/Site/ ディレクトリの中に site.config.m4 というファイルを 用意しておけば、Makefile 生成時にデフォルトで参照されます。 siteconfig ファイルの書式に関する詳細は、devtools/README や devtools/Site/README を参照してください。ここでは、基本的なものの みを紹介します。 i) コンパイラやコンパイルオプション 利用するコンパイラやコンパイルオプションをデフォルトから変更する必 要がある場合は、以下のような定義を siteconfig ファイルに記述してお くことで、Makefile の内容を調整することが可能です。 define(`confCC', `gcc') define(`confOPTIMIZE', `-O2') define(`confLDOPTS', `-static') また、すでに define されているものに対して追加をしたい場合は、 PREPENDDEF() や APPENDDEF() を利用します。前者は先頭に追加するもの で、後者は末尾に追加するものです。 ii) aliases データベースを扱うデータベースライブラリ 利用するデータベースライブラリに合わせて confMAPDEF を定義します。 ndbm を利用 aliases.dir, aliases.pag といったファイルにデータベースを保 存するライブラリです。従来から広く利用されている OS のほとん どでサポートされています。ただし、4.4BSD をベースとする比較 的新しい OS ではサポートされていないため、代りに後述の db を 利用します。 ndbm を利用する場合、confMAPDEF に -DNDBM を定義します。また、 OS によっては confLIBS に -ldbm を追加する必要があります。 APPENDDEF(`confMAPDEF', `-DNDBM') APPENDDEF(`confLIBS', `-ldbm') db (Berkeley new DB) を利用 aliases.db といったファイルにデータベースを保存するライブラ リです。4.4BSD には標準で用意されています。ndbm に比べて高速 で、1レコード1024 文字までという長さ制限もありません。また、 sendmail 8.9 からは db 2.x に、sendmail 8.10 からは db 3.x にも対応しています。特に db 1.x を使い続ける積極的な理由がな い限り、db 2.x 以降の利用を推奨します。また、8.9.2 以降では、 8.9.1 以前のバージョンで問題となっていた、sendmail のプロセ スがたくさん残ったままになる問題が解決されています。db を利 用する場合、confMAPDEF に -DNEWDB を、LIBS= に -ldb を追加定 義します。 APPENDDEF(`confMAPDEF', `-DNEWDB') APPENDDEF(`confLIBS', `-ldb') これまで利用していた db より新しいバージョンを利用する場合は、 sendmail を置き換えた後、忘れずに newaliases などを実行して データベースファイルを作り直しておきます。new DB に関する情 報は http://www.sleepycat.com/ から入手できます[11]。 NIS (旧称 YP) の参照 NIS 経由で aliases を参照したり、NIS の aliases データベース を生成する NIS マスタサーバで使用する場合に、定義します。 confMAPDEF に -DNIS を指定します。 APPENDDEF(`confMAPDEF', `-DNIS') その他、NISPLUS, HESIOD, LDAPMAP などのデータベースも参照するこ とができます。詳細については、README ファイルを参照してください。 なお、-DNDBM と -DNEWDB を同時に定義して、aliases.{dir,pag} と aliases.db のどちらのファイル形式も利用できるようにしたい場合は、 リンクしようとする new DB のライブラリから、ndbm 互換インタフェー ス部分を削除しておく必要があります。詳細については、sendmail の 配布パッケージに附属の README ファイルを参照してください。 また、ヘッダ (*.h) やライブラリ (lib*.a) が OS の標準パスにイン ストールされていない場合は、confINCDIRS や confLIBDIRS に、それ ぞれ -I/path/include や -L/path/lib を指定しておきます (path の 部分は、環境に合わせて適宜置き換えてください)。 APPENDDEF(`confINCDIRS', `-I/path/include') APPENDDEF(`confLIBDIRS', `-L/path/lib') iii) BIND ライブラリ (DNS の MX レコード参照のために利用) DNS の MX レコードの参照の有無や、BIND ライブラリのバージョンに 応じて設定を調整します。 α) DNS の MX レコードを参照しない sendmail を作る confENVDEF に -DNAMED_BIND=0 を定義します。 APPENDDEF(`confENVDEF', `-DNAMED_BIND=0') β) DNS の MX レコードを参照可能な sendmail を作る インクルードファイルやライブラリの調整を行います。なお、古い バージョンの BIND ライブラリにはセキュリティホールがあるため、 できるだけ新しいバージョンを利用してください。また、bind 4.8 などの古いバージョンでは、セキュリティ以前の問題として、動作 が不安定で届くはずのメールがエラーになる場合があります。BIND に関する情報は http://www.isc.org/products/BIND/ を参照して ください[12]。 a) bind (4.x ベース) を利用するとき bind バージョン 4.x の libresolv.a が用意されている場合は、 confLIBS に -lresolv を定義します。OS によっては、libc.a に含まれているため、定義する必要がない場合があります。 APPENDDEF(`confLIBS', `-lresolv') b) bind 4.9.x を利用する場合 libresolv.a と lib44bsd.a という2つのライブラリが用意され ているので、LIBS= に -lresolv と -l44bsd を定義します。な お、lib44bsd.a は 4.4BSD 依存部分を集めたライブラリである ため、4.4BSD のシステムでは定義する必要はありません。 APPENDDEF(`confLIBS', `-lresolv -l44bsd') c) bind 8.1.x を利用する場合 confLIBS に -lbind を定義します。 APPENDDEF(`confLIBS', `-lbind') また、ヘッダ (*.h) やライブラリ (lib*.a) が OS の標準パスにイン ストールされていない場合は、Build のコマンドラインに -I/path/include や -L/path/lib を指定することができますが、 次のように siteconfig ファイルに定義しておくことも可能です。 APPENDDEF(`confINCDIRS', `-I/usr/local/bind/include') APPENDDEF(`confLIBDIRS', `-L/usr/local/bind/lib') BIND ライブラリのヘッダは、バージョンによって異なります。異なる バージョンのライブラリとヘッダを併用すると、正しく動作しないこと があるので注意が必要です。 なお、APPENDDEF によって定義がマクロの最後に追加されますが、最後 に追加されることが問題となる場合は、代わりに PREPENDDEF を使用す ることで、最初に追加されます。 iv) TCP Wrappers (SMTP の接続制限を細かく行いたい場合) sendmail 8.8 からは、sendmail.cf に check_relay ルールセットを 定義することができるようになりました。check_relay ルールセット を定義すると、デーモン sendmail に SMTP 接続しようとするホスト の IP アドレスや、その IP アドレスを DNS で逆引きして得られるホ スト名によって、選択的に接続を拒否することができます。 同様な機能をより一般的に実現するものとして、TCP Wrappers と呼ば れるパッケージが存在し、このパッケージを sendmail に組み込んで 利用することも可能です。多くの場合、check_relay ルールセットの 機能を用いるだけで十分ですが、TCP Wrappers を組み込んできめ細か く効果的に接続制限を行いたい場合は、libwrap.a および tcpd.h を 用意し、コンパイル時にマクロ TCPWRAPPERS が定義されるよう、 confENVDEF 等に -DTCPWRAPPERS を定義します。また、必要に応じて confINCDIRS や confLIBDIRS も調整します。 TCP Wrappers は次の URL から入手できます。 ftp://ftp.porcupine.org/pub/security/index.html パッケージ名は tcp_wrappers_.tar.gz です ( は最新のバー ジョン番号になります)。 なお、TCP Wrappers を組み込んだ場合、通常はデフォルトで接続拒否 になるため、sendmail に対して基本を接続許可にするには /etc/hosts.allow に sendmail: ALL のような行が必要になるので、 注意が必要です。 5) コンパイルの開始 一旦コンパイル環境が構築された後に再びコンパイルが必要になった場 合は、再び sh Build を実行するか、obj.[OSの種類]/sendmail/ ディレ クトリの中でmake を実行します。 % make sendmail ここでは、sendmail のバイナリファイルだけを生成するように、引数に sendmail を指定しています。同時にマニュアルの整形も行ないたい場合 は、単に make として実行します。ただし OS によっては、nroff がシ ステム標準に用意されていないため、groff を要求してくる場合があり ます。このときは GNU から配布されている groff をインストールして おく必要があります。単に sendmail をコンパイルするだけならば、マ ニュアルの整形は必要ありません。 V. サービススイッチファイルの設定 一部の OS では、標準でサービススイッチファイルがサポートされているこ とがあります。また、sendmail 8.7 からは sendmail 独自のサービススイッ チファイルの仕組みが提供されています。サービススイッチファイルは、 hosts や aliases の検索について、ローカルのファイル、NIS、DNS のいずれ を参照するのか、あるいはそれらのうちの複数を参照する場合にその参照順序 を指定するために利用されます。 サービススイッチファイルは、例えば Solaris では /etc/nsswitch.conf が、DEC では /etc/svc.conf が、sendmail 方式では /etc/mail/service.switch が利用されます。もしファイルが存在する場合は、 設定内容が意図通りになっているかどうかを確認しておきます。OS が標準で サポートしているサービススイッチファイルの設定方法については、それぞれ の OS のマニュアルを参照してください。 VI. sendmail のテスト すでに sendmail が稼働しているシステムで sendmail のバイナリファイル を置き換える場合は、慎重に作業を行なう必要があります。新しくコンパイル した sendmail をインストールする前に、それが正常に動作することを確認す る必要があります。もし、動作確認を行うことなく、安易にインストールして しまうと、予期せぬエラーのためにメールを送受信できなくなる可能性があり ます。 sendmail のテストは以下の手順で行ないます (テストはコンパイルを行なっ たディレクトリで行ないます)。 1) sendmail.cf にエラーがないことの確認 sendmail をテストモードで起動して、sendmail.cf に関してエラーが報 告されないことを確認します。 % ./sendmail -bt エラーが報告された場合は、既存の sendmail.cf を修正するか、新しい sendmail.cf を用意する必要があります。前述のように、OS に標準で添 付されている sendmail.cf を利用している場合には特に注意が必要です。 なお、aliases のデータベースファイルが、aliases のテキストファイル より古かった場合は、aliases の解析の様子が多量に表示されることがあ あります。そのような場合は、まず運用中の sendmail で newaliases (あるいは sendmail -bi) を実行しておくと良いでしょう。 なお、-bt を指定して起動したテストモードにおいて sendmail.cf によ るアドレス解析のテストを行う場合、sendmail 8 以降ではルールセット 3 がデフォルトで適用されなくなっていることに注意して下さい。ルー ルセット 0 によるアドレス解析のテストを行う場合は、必ず > 3,0 user@domain のように入力してテストを行ってください。sendmail.cf によっては、3 を 省略しても同様のテストができてしまうことがありますが、これはたまたま 同じテストができてしまっているだけなのです。 2) ホスト名が正しく取得できていることの確認 デバッグスイッチ -d0.4 を指定して sendmail を起動し、認識されてい るホスト名情報 ($j) が、正しく FQDN (Fully Qualified Domain Name; インターネットのドメイン形式の完全なホスト名) になっているかどう かを確認します。もし、正しく取得できていない場合は、sendmail.cf の Dj で始まる行 (コメントアウトされている場合はコメントアウトを はずして下さい) に、期待されるホスト名を定義して下さい。 % ./sendmail -bt -d0.4 Version 8.12.1 : ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = mail1 (canonical domain name) $j = mail1.sub.university.ac.jp (subdomain name) $m = sub.university.ac.jp (node name) $k = mail1.sub.university.ac.jp ======================================================== : hostname(1) コマンドの出力が mail1 といった FQDN でない名前であり、 FQDN を得るために DNS の参照が必要な場合には、sendmail の起動時に ネームサーバが起動されていなければなりません。もし、FQDN がネーム サーバから取得できなかった場合は、メールの配信が正しく行なえない 可能性があるので、sendmail は動作を中止してしまいます。このような 問題を避けるためには、sendmail.cfの Dj 行で静的に定義しておくとよ いでしょう。 ホスト名に関するもう一つの注意点ですが、例えばメールサーバとして 動作しているホスト mail1.sub.university.ac.jp を、他のホストがダ ウンしている時のバックアップとしても運用する場合を考えます。この ような場合、DNS において次のような MX レコードを定義することにな ります。 host.sub.university.ac.jp. IN MX 10 host.sub.university.ac.jp. IN MX 20 mail1.sub.university.ac.jp. (左辺) (右辺) ごく稀に、ホスト名の命名に関するポリシ等から、MX レコードの右辺に 定義する名前として、メールサーバの正式な FQDN ではなく、メールサー バに対する別名を用いることがあります。例えば次のような場合です。 (注意: 別名として DNS の CNAME で定義されるものを指定することは、 推奨されていません; RFC1912 参照[13]。) host.sub.university.ac.jp. IN MX 10 host.sub.university.ac.jp. IN MX 20 ms.sub.university.ac.jp. (左辺) (右辺) ここで、ms.sub.university.ac.jp は mail1.sub.university.ac.jp の 別名であるとします。このとき mail1 上の sendmail.cf では、MX レコー ドの右辺に記述されているホスト名が、クラス w に定義されている必要 があります。もし、クラス w に定義されていない場合には、正常にバッ クアップとして機能しないばかりか、バックアップメールサーバに送ら れてきたメールをエラーで跳ね返してしまうことになります。 クラス w の定義内容の確認は、テストモードで $=w と入力します (こ の機能は sendmail 8.7 よりサポートされています)。 % ./sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter
> $=w mail1.sub.university mail1.sub.university.ac.jp mail1 mail1.sub localhost [127.0.0.1] [12.34.56.78] 上記の例では、MX の右辺に現れる名前が sendmail.cf の $=w に定義さ れていません。sendmail.cf 側で解決するのであれば、 sendmail.cf 中に 次の行を追記し、クラス w にホスト名を追加するか、 Cw ms.sub.university.ac.jp あるいは /etc/mail/sendmail.cw ファイル中にホスト名を記述します。 後者の場合、sendmail.cf において Fw/etc/mail/sendmail.cw という行 が有効になっていることも確認しておきます。記述した後、もう一度 sendmail をテストモードで起動し $=w を入力して設定を確認します。 もちろん、DNS の設定において MX の右辺に現れる名前を、現在の sendmail.cf の設定で $=w に含まれている FQDN に修正する、という対 処方法もあります。 3) ローカルへのメール配信が正常なことを確認 sendmail を次のように実行して、メールがローカルのメールボックスに 配信されることを確認します。メールボックスを別に用意したメールサー バに集約するように設定している場合は、メールサーバに送られること を確認します。確認は root で行ないます。OS によっては、一般ユーザ のままで確認することも可能ですが、その場合はコマンドラインにおい て、一般ユーザの権限で書き込みが可能なディレクトリをキューディレ クトリとして指定する必要があります (例: -oQ/tmp)。 # ./sendmail -v local-user test . local-user... Connecting to local... local-user... Sent # 配信後に、メールボックスのファイルの所有者やモードに問題がないこ とを確認しておきます (メール受信者が所有し、他人が読めないこと)。 さらに、ローカルユーザを指定する代わりに、local-user@local.host のように他のホストからメールが送られてくる場合に利用されるアドレ スについても、正常にメールボックスに配信されることを確認しておき ます。 4) メールのリモートへの配信が正常なことを確認 次のように sendmail を実行し、メールが正常に別のホストに配信され ることを確認します。いくつかの異なるアドレスに対してテストしてお くと良いでしょう。 % ./sendmail -oQ/tmp -v user@remote.host test . user@remote.host... Connecting to remote.host. via esmtp... 220 remote.host ESMTP Sendmail 8.9.3/8.9.3 ready .... >>> EHLO local.host 250-remote.host Hello local.host [12.34.56.78], pleased to meet you 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-ONEX 250-ETRN 250-XUSR 250 HELP >>> MAIL From: 250 ... Sender ok >>> RCPT To: 250 ... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 LAA12345 Message accepted for delivery user@remote.host... Sent (LAA12345 Message accepted for delivery) Closing connection to remote.host. >>> QUIT 221 remote.host closing connection % 5) ファイルやディレクトリのパーミッションに関する設定および確認 sendmail 8.9 からは、より安全性を高めるため、ファイルやディレクト リに関するチェックが厳しく行われ、原則として world/group writable なファイルやディレクトリを信用しなくなりました。特に、システムディ レクトリについては、sendmail の起動時に以下のようなメッセージが出 力されることがあります。 WARNING: Group writable directory /etc WARNING: Group writable directory /usr/spool/mqueue このようなメッセージが出た場合は、指摘されたディレクトリを world/ group writable でないように変更して下さい。これらのディレクトリは、 本来 world/group writable である必要がないものです。 また、その他のファイルについても、sendmail の実行時に同様の確認が 行われ、パーミッションに問題がある場合には、そのファイルは無視さ れるとともに、エラーが報告されます。ただし、あえて world/group writable に設定する必要がある場合のことを考慮して、チェックの厳し さの度合いを sendmail.cf の DontBlameSendmail オプションの設定に より緩和させることができるようになっています。sendmail 8.9 以前の バージョンから sendmail 8.9 以降のバージョンへの置き換えを行なう 際には、これらの設定について十分確認をしておいてください。 sendmail のインストール前に、-bv オプションを用いて、問題がありそ うなアドレスをチェックしておくことで、DontBlameSendmail の設定に 関するほとんどの問題を事前に確認しておくことができます。 # sendmail -bv list :include: /usr/local/lib/ml/list... Cannot open /usr/local/lib/ml/list: Group writable directory # DontBlameSendmail オプションで指定可能なパラメータの一覧を以下に 示します。複数のパラメータを定義する場合は、複数を ',' で区切るか、 DontBlameSendmail の宣言を複数記述します (パラメータは論理加算さ れていきます)。 例: O DontBlameSendmail=GroupWritableIncludeFileSafe O DontBlameSendmail=IncludeFileInUnsafeDirPath O DontBlameSendmail=IncludeFileInUnsafeDirPathSafe O DontBlameSendmail=GroupWritableDirPathSafe なお、以下において、安全なディレクトリパスとは、world/group writable なディレクトリが、/ ディレクトリまで遡って順に調べた場合 にどこにも存在しないものをいいます。ただし、 GroupWritableDirPathSafe が定義されている場合は、group writable なディレクトリは安全と解釈されます。 AssumeSafeChown 一般ユーザが chown によって、自分が所有するファイルを他のユー ザのものに変更することができる (V 章 6 参照) 場合、(特に world/group writable なディレクトリにおいて) ファイルの所有者 情報を信用することは危険です。特に、NFS を使用している場合には、 クライアント側単独で chown が安全であっても、サーバ側の chown が危険であると、クライアント側の chown も安全ではなくなってし まいます。sendmail では、コンパイル時の OS 毎のコンフィギュレー ションにおいて、chown の安全性があらかじめ確認されているものに ついては、安全なものとして扱うように設定されていますが、安全で ないことが判明している OS や、確認がとれていない OS では、 chown は安全でないものとされ、world/group writable なディレク トリにおける所有者情報は無視されるようになります。もし、chown を安全なものとして扱って欲しい場合には、AssumeSafeChown を定義 します。(この問題については、後述の VI 章 6-(ii) も参照してく ださい。) ClassFileInUnsafeDirPath クラス定義ファイル (sendmail.cf の F で始まる行で指示される) が安全でない (world/group writable な) ディレクトリに存在する ことを許します。 ErrorHeaderInUnsafeDirPath ErrorHeader オプションで指定されるファイルが安全でないディレク トリに存在することを許します。 GroupWritableDirPathSafe 全般に、group writable なディレクトリは安全であると解釈します。 これにより、ディレクトリが group writable であっても、Include- FileInUnsafeDirPathSafe 等で許可されたプログラムは、プログラム の起動を記述したファイルの所有者の権限で実行されるようになりま す。 GroupWritableForwardFileSafe group writable な .forward ファイルの使用を許容します。 GroupWritableIncludeFileSafe group writable な :include: ファイルの使用を許容します。 GroupWritableAliasFile group writable な aliases ファイルを許容します。 HelpFileInUnsafeDirPath HelpFile オプションで指定されるファイルが、安全でないディレク トリに存在することを許します。 WorldWritableAliasFile world writable な aliases ファイルを許容します。 ForwardFileInGroupWritableDirPath .forward ファイルが group writable なディレクトリパスに存在す ることを許します。 IncludeFileInGroupWritableDirPath :include: ファイルが group writable なディレクトリパスに存在す ることを許します。 ForwardFileInUnsafeDirPath .forward ファイルが安全でないディレクトリパスに存在することを 許します。 IncludeFileInUnsafeDirPath :include: ファイルが安全でないディレクトリパスに存在することを 許します。 ForwardFileInUnsafeDirPathSafe 安全でないディレクトリパスに存在する .forward ファイルからのプ ログラムの起動やファイルへの配信を許します (さらに /etc/shells によるチェックも満足する必要があります)。 GroupWritableDirPathSafe が指定されていない場合は、daemon (正 確には DefaultUser に指定されたユーザ) の権限で処理されます。 ForwardFileInUnsafeDirPath だけを指定した場合は、他のアドレス へのメールの転送のみが可能になります。 IncludeFileInUnsafeDirPathSafe 安全でないディレクトリパスに存在する :include: ファイルからの プログラムの起動やファイルへの配信を許します (さらに /etc/shells によるチェックも満足する必要があります)。 GroupWritableDirPathSafe が指定されていない場合は、daemon (正 確には DefaultUser に指定されたユーザ) の権限で処理されます。 IncludeFileInUnsafeDirPath だけを指定した場合は、他のアドレス へのメールの転送のみが可能になります。 MapInUnsafeDirPath マップファイル (aliases や sendmail.cf の K 行で指定される外部 データベースファイル) が安全でないディレクトリパスに存在するこ とを許します。 LinkedAliasFileInWritableDir aliases ファイルへのリンクが安全でないディレクトリパスに存在す ることを許容します。 LinkedClassFileInWritableDir クラスファイル (sendmail.cf の F で始まる行で指示される) への リンクが安全でないディレクトリパスに存在することを許容します。 LinkedForwardFileInWritableDir .forward ファイルへのリンクが安全でないディレクトリパスに存在 することを許容します。 LinkedIncludeFileInWritableDir :include: ファイルへのリンクが安全でないディレクトリパスに存在 することを許容します。 LinkedMapInWritableDir 安全でないディレクトリパスに存在する、マップファイル (aliases や sendmail.cf の K 行で指定される外部データベースファイル) へ のリンクの使用を許します。 LinkedServiceSwitchFileInWritableDir 安全でないディレクトリパスに存在する、サービススイッチファイル へのリンクの使用を許します。 FileDeliveryToHardLink ハードリンクされたファイルへの配信を許します。 FileDeliveryToSymLink シンボリックリンクされたファイルへの配信を許します。 WriteMapToHardLink ハードリンクされたマップファイル (aliases や sendmail.cf の K 行で指定される外部データベースファイル) への書き込みを許します。 WriteMapToSymLink シンボリックリンクされたマップファイル (aliases や sendmail.cf の K 行で指定される外部データベースファイル) への書き込みを許 します。 WriteStatsToHardLink sendmail.cf の StatusFile オプションで指定されるファイルがハー ドリンクされている場合でも、書き込みを許します。 WriteStatsToSymLink sendmail.cf の StatusFile オプションで指定されるファイルがシン ボリックリンクされている場合でも、書き込みを許します。 6) システムファイルの内容に関する確認 sendmail R8 では、メールを受信した際の動作に関する設定の自由度を ローカルユーザごとに調整することが可能です。設定によっては、古い sendmail で正常に扱われていたメールが拒否されてしまうこともありう るので、8.8.x より古いバージョンからのバージョンアップの場合には、 慎重に確認してください。 i) /etc/shells .forward ファイルや :include: で指示されるファイルからプログラ ムを起動しようとする場合 (あるいはファイルに書き込もうとする場 合)、それらのファイルの所有者に対応付けられているログインシェ ルが /etc/shells に定義されている必要があります。もし、全ての ユーザに対して、無条件でプログラムの起動を許可する場合には、 /SENDMAIL/ANY/SHELL/ という文字列を /etc/shells に記述しておき ます。ファイルの所有者が信頼できない場合にも、 /SENDMAIL/ANY/SHELL/ の有無で起動の可否が判定されます。 ii) chown の可能性に関するチェック SYSV 系の一部の OS には、一般ユーザが chown を用いて自分が所有 者であるファイルやディレクトリを他人のものに変更することができ るものがあります (OS によっては、変更の可否を切り替えることも できます)。また、NFS でマウントされているファイルシステムの場 合、クライアント側で chown が不能であっても、サーバ側でchown が可能であれば、同様に chown できてしまうことになります。この ようなファイルシステムを使用している場合は、:include: で指示さ れるファイルが存在するディレクトリが world/group writableであっ たとき、ファイルの所有者情報を信用してその所有者の権限でプログ ラムを実行することは危険です。このようなシステムでは、 /etc/shells に /SENDMAIL/ANY/SHELL/ が登録されていれば、daemon の権限で処理が行なわれ、登録されていなければ、処理が拒否されま す。従って、ファイルが置かれているディレクトリのモードに注意し て下さい。また OS によっては、chown に関する挙動が未調査なため、 sendmail がデフォルトで chown 可能な危険な OS とみなしてしまう ことがあります。 危険でないことが確認できた場合には、IV 章の 5 に示したように、DontBlameSendmail オプションに AssumeSafeChown を定義します。 iii) PID ファイルに関するチェック sendmail R8 は、稼働中のデーモンプロセスのプロセス番号を /var/run/ 等のディレクトリの sendmail.pid ファイルに格納します。 このファイルの内容が一般ユーザによって変更可能になっているとセ キュリティ上問題が発生するため、sendmail は書き込みの際に sendmail.pid ファイルのパーミッションおよび、ディレクトリ (親 を含む) のパーミッションをチェックし、問題があれば書き込みを行 いません。したがって、/var/run のモードを 1777 (所有者のみしか 削除等の操作ができないようにする) にしたり、あらかじめ sendmail.pid ファイルを root からのみ書き込み可能なファイルと して用意しておくとよいでしょう。 ファイルのパーミッション等に関する問題点がつかめない場合は、 -d27.14,44.4 といったデバッグスイッチを指定して sendmail を実行し てみると良いでしょう。多くの場合、実際にメールを送るかわりに -bv スイッチを用いて配信の可否を確認することで、ファイルのモード等に 関する問題の有無を確認することができます。 # ./sendmail -d27.14,44.4 -bv user VII. sendmail のインストール すでに sendmail が稼働しているシステムでは make install を実行するこ とは危険です。元の sendmail に戻す必要が発生した場合のために、これまで 利用していた sendmail を残すようにして手作業で慎重にインストールするこ とをお勧めします。 例えば、sendmail をインストールしている場所が /usr/lib/sendmail であっ たとすると、root 権限で次のように作業します (sendmail をインストールす るディレクトリは、OS 毎に異なるので、環境に合わせて読み替えてください)。 # cp -p ./sendmail /usr/lib/sendmail.new # chown root /usr/lib/sendmail.new # chmod 4755 /usr/lib/sendmail.new (root 権限で起動されることになるので、SGID kmem は必要ありません) # mv /usr/lib/sendmail /usr/lib/sendmail.old # mv /usr/lib/sendmail.new /usr/lib/sendmail (以下の操作は、シンボリックリンクを利用しているため、すでに一度行わ れていれば不要です。シンボリックリンクにしておくことで、今後の sendmail のバージョンアップの際に以下の操作は不要になります。) # rm /usr/bin/mailq # ln -s /usr/lib/sendmail /usr/bin/mailq # rm /usr/bin/newaliases # ln -s /usr/lib/sendmail /usr/bin/newaliases なお、sendmail が mqueue ディレクトリにおいて配信未完了のメールを保 存しておくファイル (qf ファイル) の形式は、sendmail のバージョンによっ て異なることがあります。sendmail 8.9 での qf のバージョンは 2 です。古 いバージョンの qf ファイルは、新しいバージョンの sendmail で扱うことが 可能ですが、一旦新しいバージョンの sendmail で処理された qf ファイルは、 新しい形式に変換されてしまいます。もし何らかの問題が生じて、利用する sendmail を古いバージョンに戻す必要がある場合は、qf ファイルの形式に互 換性がないことに注意して下さい。 古い sendmail は sendmail.old という名前で残してありますから、古い sendmail に戻す必要が生じた場合は、次の手順で元に戻し、必要に応じて後 述の再起動を行います。 # mv /usr/lib/sendmail /usr/lib/sendmail.bad # mv /usr/lib/sendmail.old /usr/lib/sendmail VIII. sendmail の再起動 sendmail のバイナリファイルのインストール後、デーモンとして動作して いる sendmail を再起動します。もちろん、外部から送られてくるメールを受 信する必要のないホストでは、受信用のデーモン sendmail を起動する必要は ありません。ただし、sendmail を用いてリモートにメールを発信するホスト では、配信未完了で mqueue に保存されたメールを定期的に処理するため、デー モンを起動しておく必要があります。 # ps ax | grep sendmail 143 ... 0:42 sendmail: accepting connections on port 25 3424 ... 0:00 sendmail: MAA04321 ns.jpcert.or.jp: client greeting 10364 ... 0:00 grep sendmail # kill 143 # /usr/lib/sendmail -bd -q1h (SYSV 系の OS の場合、ps コマンドに指定する引数は -ef とします。ps の 出力で、accepting connections となっているものが、daemon として動作し ている親プロセスです。OS によっては、sendmail -bd -q1h のように、起動 時の指定がそのままレポートされる場合もあります。それ以外のメールを処理 中の sendmail プロセスは、特に問題がなければそのままにしておきます。) sendmail 起動時の -bd スイッチは、メールを受信するデーモンとして動作 することを指定します。-q1h は、1時間の処理間隔で、配信未完了のメールを 処理することを指定します。 なお、sendmail をデーモンとして起動するときは、フルパスを指定して起 動します。sendmail R8 では、フルパスを指定して起動すると、kill -HUP に より SIGHUP を送ることで、sendmail 自身が再起動処理を行ないます。フル パスを指定せずに起動した場合は、SIGHUP を受信した場合の処理が正しく行 われません (フルパスで起動されなかった場合は syslog にその旨のメッセー ジが記録されます)。 また、/etc/rc などにある、システムブート時に sendmail を起動するため の設定についても、フルパスを指定して起動していることを確認しておきます。 置き換えと再起動が完了したら、問題の発生を迅速に察知するため、次のよう にして sendmail が syslog に出力する配信記録をしばらくの間監視しておく と良いでしょう (ログが出力されるファイルの名前や場所は、設定によって異 なるので、/etc/syslog.conf などを参照して確認します)。 % tail -f /var/log/syslog IX. (付録) PGP署名の検証 sendmail では配布パッケージが第三者によって改変されていないことを確 認できるようにするため、PGP による署名を行なっています。署名を検証する ためには sendmail の配布パッケージ自身とその署名ファイル、そして署名者 の公開鍵を入手する必要があります。sendmail バージョン 8.12.1 の署名検 証に使う鍵 "Sendmail Signing Key/2001 " は次の URL から公開されています。 ftp://ftp.sendmail.org/pub/sendmail/PGPKEYS 厳密には、sendmail の配布パッケージ、その署名ファイル、そして署名者の 公開鍵、これら三つのファイルは全て別々のサイトから集めてくることが望ま れます。悪意を持った第三者によるソースコードの改竄を正しく検知するため です。上記公開鍵のフィンガープリントは Key fingerprint = 59 AF DC 3E A2 7D 29 56 89 FA 25 70 90 0D 7E C1 となります。以下に、pgp5.0 と GnuPG でフィンガープリントを出力する例を 示します。 % pgpk -ll 'Sendmail Signing Key/2001' Type Bits KeyID Created Expires Algorithm Use pub 1024 0xCC374F2D 2000-12-14 ---------- RSA Sign & Encrypt f16 Fingerprint16 = 59 AF DC 3E A2 7D 29 56 89 FA 25 70 90 0D 7E C1 uid Sendmail Signing Key/2001 sig 0xCC374F2D 2000-12-14 Sendmail Signing Key/2001 : : % gpg --finger 'Sendmail Signing Key/2001' gpg: Warning: using insecure memory! pub 1024R/CC374F2D 2000-12-14 Sendmail Signing Key/2001 Key fingerprint = 59 AF DC 3E A2 7D 29 56 89 FA 25 70 90 0D 7E C1 % pgp 5.0 を使って署名を検証する例を以下に示します。 % ls sendmail.8.12.1.tar.gz sendmail.8.12.1.tar.sig % gzip -d sendmail.8.12.1.tar.gz % ls sendmail.8.12.1.tar sendmail.8.12.1.tar.sig % pgpv sendmail.8.12.1.tar.sig Cannot open configuration file /irt/home/yozo/.pgp/pgp.cfg This signature applies to another message File to check signature against [sendmail.8.12.1.tar]: Good signature made 2001-10-01 15:13 GMT by key: 1024 bits, Key ID CC374F2D, Created 2000-12-14 "Sendmail Signing Key/2001 " WARNING: The signing key is not trusted to belong to: Sendmail Signing Key/2001 % 以下は GnuPG を使って署名を検証する例です。 % gzip -dc sendmail.8.12.1.tar.gz | gpg --verify sendmail.8.12.1.tar.sig - gpg: Signature made Tue Oct 2 00:13:16 2001 JST using RSA key ID CC374F2D gpg: Good signature from "Sendmail Signing Key/2001 " Could not find a valid trust path to the key. Let's see whether we can assign some missing owner trust values. No path leading to one of our keys found. gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. gpg: Fingerprint: 59 AF DC 3E A2 7D 29 56 89 FA 25 70 90 0D 7E C1 % どちらの場合も「Good signature」と表示されていれば問題ありません。 PGP プログラムは例えば ftp://ftp.ring.gr.jp/pub/pgp/ などから入手でき ます。また、gzip は GNU プロジェクトから配布されているファイル圧縮展開 プログラムです。こちらも ftp://ftp.ring.gr.jp/pub/GNU/gzip/ などから入 手できます。 X. 参考資料 [1] sendmail, 2nd Edition Bryan Costales and Eric Allman, O'Reilly & Associates, January 1997 ISBN 1-56592-222-0 [2] sendmail システム管理 Bryan Costales, Eric Allman 著 中村 素典 監訳、鈴木 克彦 訳、オライリー・ジャパン、1997 [3] Sendmail Home Page http://www.sendmail.org/ [4] Compiling Sendmail http://www.sendmail.org/compiling.html [5] Information about the Sendmail http://www.kyoto.wide.ad.jp/mta/sendmail.html [6] CERT Advisory CA-1995-08 Sendmail v.5 Vulnerability http://www.cert.org/advisories/CA-1995-08.html [7] CERT Advisory CA-1996-20 Sendmail Vulnerabilities http://www.cert.org/advisories/CA-1996-20.html [8] CERT Advisory CA-1996-24 Sendmail Daemon Mode vulnerability http://www.cert.org/advisories/CA-1996-24.html [9] CERT Advisory CA-1996-25 Sendmail Group Permissions Vulnerability http://www.cert.org/advisories/CA-1996-25.html [10] CERT Advisory CA-1997-05 MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4 http://www.cert.org/advisories/CA-1997-05.html [11] The Sleepycat Software Home Page http://www.sleepycat.com/ [12] Internet Software consortium - BIND http://www.isc.org/products/BIND/ [13] RFC1912: Common DNS Operational and Configuration Errors http://www.ietf.org/rfc/rfc1912.txt ====================================================================== ご多忙の中、この文書を作成するため、多くの貴重なお時間を割いてご協力頂 いた 中村 素典 氏に心より感謝申し上げます。 JPCERT/CC スタッフ一同 ====================================================================== <JPCERT/CC からのお知らせとお願い> 本文書で解説した不正アクセスも含め、インターネット上で引き起こされる さまざまな不正アクセスに関する情報がありましたら、info@jpcert.or.jp ま でご提供くださいますようお願いします。JPCERT/CC の所定の様式 http://www.jpcert.or.jp/form/ にご記載のうえ、関連するログファイルのメッセージとともに、 info@jpcert.or.jp までお送りください。 JPCERT/CC に頂いた報告は、報告者の了解なしに、そのまま他組織等に開示 することはありません。JPCERT/CC の組織概要につきましては、 http://www.jpcert.or.jp/ をご参照ください。 JPCERT/CC では、不正アクセスに関する情報を迅速にご提供するために、 メーリングリストを開設しています。登録の方法等、詳しくは、 http://www.jpcert.or.jp/announce.html をご参照ください。 - ---------- 注: JPCERT/CC の活動は、特定の個人や組織の利益を保障することを目的と したものではありません。個別の問題に関するお問い合わせ等に対して必ずお 答えできるとは限らないことをあらかじめご了承ください。また、本件に関す るものも含め、JPCERT/CC へのお問い合わせ等が増加することが予想されるた め、お答えできる場合でもご回答が遅れる可能性があることを何卒ご承知おき ください。 注: この文書は、不正アクセスに対する一般的な情報提供を目的とするもの であり、特定の個人や組織に対する、個別のコンサルティングを目的としたも のではありません。また JPCERT/CC は、この文書に記載された情報の内容が 正確であることに努めておりますが、正確性を含め一切の品質についてこれを 保証するものではありません。この文書に記載された情報に基づいて、貴方あ るいは貴組織がとられる行動 / あるいはとられなかった行動によって引き起 こされる結果に対して、JPCERT/CC は何ら保障を与えるものではありません。 - ---------- 1998-2001 (c) JPCERT/CC この文書を転載する際には、全文を転載してください。情報は更新されてい る可能性がありますので、最新情報については http://www.jpcert.or.jp/ed/ を参照してください。やむを得ない理由で全文を転載できない場合は、必ず原 典としてこの URL および JPCERT/CC の連絡先を記すようにしてください。 JPCERT/CC の PGP 公開鍵は以下の URL から入手できます。 http://www.jpcert.or.jp/jpcert.asc - ---------- 改訂履歴 2001/12/27 参照 URL および文面の更新 WIDE 版パッチに関する記述を修正 set-user-id に関する記述を追加 2000/08/25 参照 URL の更新 1999/10/01 VII 章 - mailstats に関する間違いの記述を削除した。 (mailstats は sendmail とは独立のプログラムである) 改訂履歴の年の間違いを修正した。 1999/03/09 I 章 - インストールされている sendmail のバージョン番 号を調べる方法を追加した。 IV 章 - タイプミスを修正した。 1999/03/04 I 章 - 最新バージョンを 8.9.3 に変更した。 IV 章 - タイプミスを修正した。 1999/01/26 I 章 - 最新バージョンを 8.9.2 に変更した。 IV 章 - db 2.x に関する記述を追加した。 MIME Buffer Overflow 対策に関する記述を追加した。 VI 章 - アドレス解析テストを行う際の注意事項を追加した。 DontBlameSendmail オプション使用時のチェック方 法に関する記述を追加した。 1998/07/24 目次を追加した。 I 章 - 最新バージョンを 8.9.1 に変更した。 IV 章 - siteconfig を使う方法を追加した。 1998/06/08 IV 章 - タイプミスを修正した。 1998/05/22 I 章 - 最新バージョンを 8.9.0 に変更した。 IV 章 - TCP Wrapper に関する記述を追加した。 VI 章 - sendmail 8.9 のための説明を追加した。 1998/02/13 IV 章 - PGP の URL を修正した。 VII 章 - mqueue ディレクトリに関する記述を変更した。 古い sendmail に戻す方法に「再起動」を追加した。 VIII 章 - 稼働中の sendmail プロセスの発見方法に関する記 述を追加した。 1998/01/30 First Version. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBPCqHmIx1ay4slNTtAQEmxAQAiIvk6Lv75Y7Pt73exITtHe42Piz1a+ZP sSnMdahVVupfclTv2A+e6RCp0Wmq6q8TKovKwI4BNTWIbuvo8df0enTxI5JaUT8j zDGCh5nlqWCXboT1btCIpqktcHms7sbCdS5EEzs6wYyqkOX8p91w4hw+2kZjfg3p CldvH8njORk= =BrC7 -----END PGP SIGNATURE-----