SMTP PIPELINING

ネットワーク

.NET Frameworkに潜む脆弱性「SMTPコマンド・インジェクション」とその対処法 - ＠IT

この記事の主題は、SMTP におけるインジェクションの話なのだが、その前段階の話が気になった。

SMTP で送ろうとしている内容を、予めテキストファイルに保存しておいて、Netcat で流しこむ話。まぁ、別に Netcat を使わなくても、Teraterm や putty で smtp ポートへつないで、コピー＆ペーストしても同じ事は出来るが、こうすると、サーバ側からのレスポンスを無視して、一方的に送信内容を押し付けることになる。

例えると、相手の返事を聞かずに、一方的に話をして電話を切るようなもので、要件が伝わる保証はない。

ただ、SMTP のひとつひとつのコマンドに対する応答を待つと、スループットが稼げないので、RFC 2920 で SMTP PIPELINING というのが用意されている。

RFC 2920 - SMTP Service Extension for Command Pipelining

これは、拡張 SMTP の範疇なので、最初の「HELO」の代わりに「EHLO」を使い、「EHLO」に対するサーバ側のレスポンスで、PIPELINING に対応している事を確認してから流しこむのが、正しいやり方になる。

なので、先の記事は、

  • 「HELO」で始めているので、SMTP サーバがパイプライン処理をしなくても OK
  • たとえ対応しているサーバでも、「EHLO」とそのレスポンスを確認するまでは、パイプラインで流し込めるか否かは判断出来ないので、バッチ処理に「HELO」/「EHLO」を含める事は出来ない。

ので、Windows Server 2003 R2 の SMTP サービスが、このようなバッチ処理で上手くいかないのを責めることは出来ない。むしろ、「sendmail はずいぶん、親切に頑張ってるなぁ」という事になる。

「DATA」の最中にピリオドだけの行がメッセージの終了を表すので、エスケープする必要がある、主題の方は良いのだが、これを真似して、SMTP PIPELINING を無視して一気に流しこむ人が出てこないか、とっても心配。

ついでに、SMTP の RFC として、821 を紹介しているのは、「おい、何時の時代だよ」という感じ。2001 年に 2821 に置き換えられているし、2008 年に 5321 に置き換えられているんだけど...。

http://tools.ietf.org/html/rfc2821
RFC 5321 - Simple Mail Transfer Protocol