以下、RFC1413 からの出典です。
『Identification Protocol は、認証やアクセス制御プロトコルを意図するも のではない。それはたかだか、TCP 接続に関する追加的な監査情報を提供する だけである。最悪の場合、誤解を招く、不正確な、あるいは有害な情報を提供 する可能性がある。
このプロトコロから返された情報を監査以外の目的に使用してはならない。特 に、Identification Protocol の情報を、一時的な手段 (つまり他のチェック 方法を使用しない) であれ補足的な手段であれ、アクセス制御の判断に使用す ると、ホストセキュリティの低下を招く危険性がある。』
ここでもし、sendmail が ident を要求したとき、 その途中の経路上のルーターで ident の 113 ポートへのアクセスを拒否するような packet filtering の設定を 行っている場合、 filtering で発行しているエラーの種類と sendmail の動作しているマシンの インプリメントの組み合わせによっては、 メールの送信が行えなくなる場合がある。(次項参照)
また、実際問題として ident の設定を行っているサーバーはかなり少ないため、 ほとんど使われていない (= 無駄なパケットが発生している) と言える。 そのため、sendmail では ident を使用しない設定を行った方がいいだろう。
sendmail が ident 要求をしないように設定するには、 以下の設定のいずれかを行えばよい。
Orident=0を追加する。 sendmail-8.7.x 以降の V6/Berkeley config file format の場合は、
O Timeout.ident=0を追加するのでもよい。
READ_TIMEOUT='ident=0'を追加する。 sendmail-8.7.x 以降の V6/Berkeley config file format の場合は、 sendmail.def に
TIMEOUT_IDENT='0'を追加するのでもよい。
port unreachable を返す場合は、最近のマシンでは問題ないが、 4.3BSD tahoe のような古い TCP/IP の実装では protocol unreach や port unreach という概念がないため、 あるホストとの通信で port unreach が発生すると、 ICMP host unreachable を返す場合と同様、 そのホストとの TCP connection がすべてエラーになってしまい、 すでに connection が確立されていた sendmail の通信も同時に途絶えてしまう。
また、無応答であると sendmail が timeout を待つので,時間がかかります。
もし、ルーターが TCP RST を返せるようになっていれば、 これを設定することで以上の問題は発生しませんが、 現在のところこの設定を行うこがルーターはほとんどありません。 (少なくてもCisco ではできません。) ただし、Firewall-1 では TCP RST を返しますので、 この設定を行なえばいいでしょう。
以上のように、ident に対して packet filtering を行っていると、 メールの受信に問題をきたす場合があるので、 現状では ident 要求は素通しするのが無難かもしれません。
httpd.conf で
IdentityCheck onとした場合
httpd.conf で
IdentityCheck Onとした場合
httpd.conf で
IdentityCheck onとした場合
Makefile 中で
AUTH = -DALWAYS_RFC931とした場合