IIJ技術陣「spamからメールを守れ（管理者編）」

2005年2月28日
小林直 ユーザ編はこちら＞＞

　最近では、サーバとクライアントの処理能力を比較するとほとんど差がなくなってきたり、最大100MbpsのFTTHが安価に手に入るようになった。そのため、適切に設定されていないサーバは、悪意ある1台のクライアントにより、処理能力を使いきられてしまう可能性がある。

　このような事態を防ぐためには、タイムアウト値を調整したりリソースを制限したりといった対策が必要だ。そこで今回は、以下の点について解説する。

1. タイムアウト値の調整
2. リソースの制限

　このコラムで解説している機能はすべてsendmailに付属している「m4マクロ」による設定生成ツールで使用できる。それぞれ説明する変数名は、m4マクロで用いる名称で記述。数値の変更のみで、ルールの追加を必要としない機能もあるため、この場合のみcfファイルにおける変数名も併記する。なお、詳細を知りたい場合は、sendmailソース展開ディレクトリ以下のcf/READMEを読むとよいだろう。

　sendmailでは設定ファイルで多くのタイムアウト値が変更できるが、これらはsendmailがサーバ（ほかのホストから接続を受ける）として動作する場合と、クライアント（ほかのホストへ接続を発行する）として動作する場合で用いる変数名が異なる。初期値は制限が緩いため、無駄なリソースを占有されないように適切に設定してほしい。

　以下にサーバとして動作させる場合に変更を推奨する変数名とその値を示す。各変数名の詳細については以下に述べる。

　なお推奨値は、RFC 2821に該当する項目がある場合は、その最小値を考慮して記載している。この値より小さい値も設定できるが、ほかのMTAとの相互運用性を保つため極力RFCの制約には従うべきだ。

• confTO_COMMAND（Timeout.command）
  クライアントからSMTPコマンドを受信するまでの待ち時間。何かしらの入力を受信すればこのタイマーは初期化される。この値は、セッション全体の待ち時間ではないことに注意したい。この条件で制限時間を超えた場合は接続を切断するため、クライアントへエラーメッセージは送信されない。
  
  
• confTO_DATABLOCK（Timeout.datablock）
  クライアントからDATAコマンドが発行されると、サーバはメール本文の受信を開始する。この値はクライアントからの送信が途切れた場合にサーバが待つ時間となる。この条件で制限時間を超過した場合以下のメッセージをサーバから受け取る。
  451 4.4.1 timeout waiting for input during message collect
  
  
• confTO_IDENT（Timeout.ident）
  RFC 1413で定められている「Identification Protocol」（ident）を用いたリレー元ユーザの確認における待ち時間である。しかし、今となってはほとんど使用されていない。また、問い合わせ先がTCPポート113への接続をフィルタしている場合は、無駄な待ち時間が発生するため無効にする方がよい。
  
  
• confTO_RESOLVER_RETRANS（Timeout.resolver.retrans）
  DNSサーバへの問い合わせにおける待ち時間である。設定した時間を超過すると、再度DNSサーバに問い合わせを行う。問い合わせるDNSサーバがネットワーク的に遠い場所にある場合は、この値を短くしすぎると再送が多発するため注意が必要である。名前解決のための問い合わせがボトルネックになる場合は、同一サーバ上でキャッシュ用のDNSサーバを稼働させそれを利用させるのも良いだろう。
  
  
• confTO_RESOLVER_RETRY（Timeout.resolver.retry）
  DNSサーバへの問い合わせにおけるリトライの回数。confTO_RESOLVER_RETRANSで設定した時間以内に回答が得られない場合、この値の回数だけリトライを行う。相手側のDNSサーバが適切に設定されておらずSERVFAILとなってしまう問い合わせはキャッシュされないため、過剰な再送は参照しているDNSサーバの負荷になる点にも注意したい。