最近はメールの流量増加に伴い、サーバに求められる処理能力も大きくなっている。そのため、複数のMXレコードやAレコードを記述することで、クライアントから受け付ける接続を分散させ、各サーバに掛かる負荷の軽減を図っている場合もあるだろう。sendmailは標準では、ほかのサーバと情報を共有する術を持っていないため、複数台のサーバで処理を分散していたとしても各サーバは独立して動くことになる。今回は詳細を省くが、この問題に対する解決としてMilterなどを用いることにより、異なるサーバ間で起動しているsendmailプログラムの情報共有や、標準にない機能の拡張も可能になる。

　今回解説する対策は、すべてサーバごとに独立していることを前提にしている。それぞれのサーバを適切に設定せず、台数のみを増やしてもコストに見合う処理能力は得られないため、構成要素になるサーバごとの対策も実施すべきである。

• nocanonify
  処理すべきメールアドレスのドメインパートがCNAMEである場合、sendmailはDNSサーバに問い合わせて得られた回答を元に正規化する。この設定は、その処理を抑止するものだ。本来、ドメインパートにCNAMEは用いるべきではないが、実際には、多くのケースで使用されている。インターネットへメールを送信するサーバでこの設定を用いるのは好ましくないが、メールを受信するサーバではDNSサーバへの問い合わせ抑制のため設定するのも良いだろう。
  
  たとえば、以下のようなDNSレコードが定義されているとする。
  　foo.example.com IN CNAME bar.example.com
  　bar.example.com IN A xx.yy.zz.xx
  この場合 user@foo.example.com のアドレスは以下のようになる。
  　nocanonify有り user@foo.example.com (変化無し)
  　nocanonify無し user@bar.example.com (CNAMEが展開される)
  
  
• confBAD_RCPT_THROTTLE（BadRcptThrottle）
  発行されたRCPT TOコマンドに設定数以上のエラーとなった場合、応答を遅延させる。これは、ハーベスティングアタックなどユーザの存在確認を目的とした接続に対して、効率良い有効アドレスの収集を阻止するためである。
  
  
• conncontrol
  これはバージョン8.13系より使用できる機能。access_dbを用いて1つのIPアドレスに対して、同時に接続可能な数を制限できる。この制限値を超過した場合、通常はMAIL FROMコマンドを受け取ったのちエラーを返すが、delay_checksと併せて用いることにより接続を受けた時点でエラーを返し、サーバ側からの強制切断も可能になる。
  
  以下に制限を超過したセッションの例を示す。なお、赤い文字で記載しているのはサーバから受け取る文字列で、青い文字はクライアントから受け取る文字列としている。
  
  conncontrol のみ場合
  　220 mx.example.com ESMTP Sendmail
  　HELO relay.example.org
  　250 mx.example.com Hello relay.example.org[x.x.x.x]
  　MAIL FROM: <user@example.org>
  　421 4.3.2 Too many open connections.
  接続は維持される。
  
  delay_checks + conncontrol の場合
  　421 4.3.2 Too many open connections.
  サーバから接続が切断される。

• ratecontrol
  この機能もバージョン8.13系より使用できる。1つのIPアドレスに対して単位時間あたりの接続数を制限できる。単位時間は、confCONNECTION_RATE_WINDOW_SIZE（ConnectionRateWindowSize）で設定する。これ以外は、conncontrolとよく似ており、delay_checksと併せて用いることにより接続を受けた時点でエラーを返し、サーバからの強制切断もできる。
  
  この場合にクライアントが受け取るエラーは以下のようになる。
  　421 4.3.2 Connection rate limit exceeded.
  
  
• confCONNECTION_RATE_THROTTLE (ConnectionRateThrottle)
  これは1秒間に許可する接続回数。sendmailは接続を受けたあとforkを実行し、1クライアントに対して1プロセスを割り当てる実装になっている。そのため、バースト的な接続を受けると短時間で大量のforkが実行され、過負荷の状態になる。この制限はratecontrolやconncontrolとは異なり、sendmailプロセス全体で処理する接続受付数が対象だ。そのため細かな接続受付制限は、ratecontrolやconncontrolで実施し、バースト的な接続に対する備えとしてこの機能を用いると良いだろう。
  
  
• confMAX_MESSAGE_SIZE (MaxMessageSize)
  受け付けるメール本文の大きさが制限できる。この拡張機能に関する記述はRFC 1870に定められている。クライアントからのEHLOコマンドに対する応答として受付可能なバイト数を宣言すると同時に、MAIL FROMコマンドにおけるSIZE変数の宣言を受け付けるようになる。クライアントがこの拡張機能に対応している場合は無駄にメール本文を送信しなくともエラーとして認識できる。運用ポリシーとして制限をかけられない場合は仕方ないが、初期値は制限がないため1Gバイトを越えるような巨大なメールも受け付けてしまうことに注意したい。