SMTP（Simple Mail Transfer Protocol）～後編：インターネット・プロトコル詳説（6）

» 2001年05月18日 00時00分公開

　前回に続き、今回は主にSMTPの拡張版であるESMTPについて説明することにしよう。

ESMTP〜拡張SMTP

　SMTPが7ビットのASCIIコードしか用いていないのは前回述べたとおりだ。しかし、MIMEの回で述べたように、それでは都合の悪い場合も多々ある。そこで、これを8ビットでも利用できるようにしようとの動きが出てきた。これがESMTP（Extended SMTP）だ。ESMTPは、SMTPの機能をそのまま包含しつつ、8ビット対応だけでなく、幾つかの拡張を同時に行っている。仕様はRFC1869およびRFC1652などで定義されている。主なものを紹介しよう。

グリーティング

　通常のSMTPではHELOコマンドでグリーティングを行うが、ESMTPではEHLOコマンドを用いる。これは接続先MTAへ自分がESMTPに対応していることを知らせるためだ。

図1　ESMTPネゴシエーションの例

　接続先MTAもESMTPに対応している場合には正常終了（250リプライコード）し、ESMTPの拡張機能で使用できるコマンドの一覧を表示する。つまり、接続元MTAはこの中からコマンドを選択しなくてはならない。

8ビットMIME

　8BITMIMEキーワードは、DATAコマンドに引き続くメール・データの送信において8ビットコードを受け入れ可能にするキーワードだ。単独のコマンドではなく、MAIL

FROMコマンドの引数として、例えば次のように使用される。

≪MAIL FROM: <taro@example.com> BODY=8BITMIME≫

SIZEキーワード

　SIZEキーワードは、メール・データ全体のサイズ制限を行う。例えば、メールサーバへの負荷や相手へのエチケット上、管理者がメール1つ当たりの上限サイズを制限したい場合などに有効だ。

　利用のされ方は2通りある。1つは接続先MTAがEHLOコマンドに引き続いて利用可能コマンドの一覧を表示する際に、SIZE値を提示する場合だ。ここでは、接続先MTAが接続元MTAに対して受け入れ可能な上限サイズを、あらかじめ知らせることができる。単位はバイトである。

図2　SIZEキーワードの利用例

　また、接続元MTAからMAIL FROMコマンドの引数として、これから送るデータのサイズを提示することもできる。この場合、接続元MTAがサイズによって受け取りを拒否することができる。

≪MAIL FROM:<taro@example.com> SIZE=500000≫

ETRNコマンド

　SMTPでは基本的に、接続元MTAから接続先MTAへのメール送信が主な動作であることは説明したとおりだ。ところが、この一方的な動作だけでは不便な局面もある。例えば、ダイヤルアップ接続でISP（接続業者）のMTAと接続されているローカルのMTAを考えてみよう。

　常時接続ではないので、ローカル側ユーザーからのメールはローカルMTAにキューイングされ、定期的にダイヤルアップして、ISPのMTAへ送信される運用が考えられる。しかし、外部から来るメールは、このままではローカル側へ送信する術がない。多くのISPは、わざわざローカルMTAへダイヤルアップなどしてくれないからだ。

　そこでSMTPでは、TURNというコマンドが用意されていた。この例でいえば、送受信の方向を切り替えて、ISPのMTAからローカルMTAへキューイングされているメールを送信するコマンドだ。これを使えば、ローカルMTAからダイヤルアップした際に、メールを取り込むことができる。

　TURNコマンドではセキュリティに対して配慮していなかったので、ノード名で相手を確認できるようにしたのが、ETRNコマンドである。

図3　ダイヤルアップにおけるメールの送信

ToとCc、Bccはどう違う？

　To、Cc、Bccの意味としての違いは、すでに連載の第3回にてMIMEに関連して述べた。では、SMTPではそれぞれどのように扱われるのだろうか？結論からいうと、実は違いはまったくない。SMTPではまったく同一に扱われるのだ。

　もう一度SMTPでの転送時の動作を考えてみよう。SMTPではRCPT TOコマンドであて先を示していた。このRCPT TOは「メールの送信先アドレス」の意味しか持っていない。つまり、もともとがたとえToであろうとccだろうと、送信には変わりないわけだ。

　なお、SMTPレベルでは動作に違いはないが、Bccが含まれる場合のみ、MTAはメールメッセージに介入する。そして、メールヘッダの存在するBccフィールドを取り除いてしまう。これは、Bccの意味をメールに維持させるためだ。時折、Bccで届いたメールのヘッダに自分のアドレスが含まれていないとの疑問が出ることがあるが、以上の動作を知っていれば理解できることだろう。

パブリックサービスとしてのSMTP

　ここまでSMTPについて説明してきたが、実はほかのプロトコルでは想定されているのに、もともとのSMTP仕様ではまったく触れられていない機能がある。ユーザーのログイン機能だ。

　一般に、SMTPメールサーバ機能は「パブリックサービス」としての運用が前提となる。これまで説明してきたように、メール・ルーティングでは、MTAとMTAが互いに通信し合うことでメールは送受信される。どのMTAとMTAが接続するかは、まったく分からない。極端な話、世界中のあらゆるMTAと接続する可能性がある。つまり、ユーザーによるログインという概念はそぐわなかったのだ。

　だから、メーラなどをセットアップする際にも、POPのユーザー／パスワードを指定することはあっても、SMTPサーバについては、SMTPサーバ名程度しか指定することはない。こうした開かれたパブリックなサービスを、ユーザーは少しだけ借りるようにメールを送信しているようなものである。

　インターネットが善意でのみ運用されているなら、この方式だけでもまったく問題はない。しかし、現実はそうではない。例えばスパムメールに代表されるように、自身のメールサーバを用いずに、他人や他社のメールサーバへ勝手に接続し、広告メールを大量に送信するやからが徘徊しだすようになったのである。

　問題の根本は、MTAが受信機能とメーラからの転送依頼を受ける機能を兼ねている点にある。そこで、2つの機能を別々のサーバに分割し、受信用では自身のドメインあてメールのみ受け入れるようにし、転送依頼用では新たにログイン機能を付加する方法が考案された^＊1。

　前者は主に、「メールリレー制限」などと呼ばれる方法だ。ただし、SMTPにかかわる方法ではなく、一般にはMTA個々の機能として取り入れられている。あて先アドレスを解析し、自身のドメインやサーバ名を含んでいない場合には、受け取りを拒否すればよい。

　後者では、幾つかの方法^＊2が考えられているが、今後一般化すると考えられるのがSMTP-AUTHと呼ばれる方式だ。

　SMTP-AUTHは、RFC2554で定義されている、ESMTPのオプションの1つだ。AUTHコマンドを用いて、「認証メカニズム」によるログインを可能にする。

　SMTP-AUTHのもとになっているのはRFC2222で規定されているSASL（Simple Authentication and Security Layer）と呼ばれる汎用的な認証メカニズムである。SASLでは、ユーザー名とパスワードをいかに安全にサーバへ渡すかに着目して、KerberosやGSSAPI、S/Keyなど幾つかの認証メカニズムを定義している。これらはクライアントやサーバの実装により選択可能になっており、また別のメカニズムを導入することもできる。

　SMTP-AUTHでは主に、PLAIN、LOGIN、CRAM-MD5、DIGEST-MD5などのメカニズムが一般的だ。メカニズムの種類はIANAが管理しており、こちらのリンク先から最新ドキュメントが入手できる。

PLAIN（RFC2595）

　PLAINは、通常の平文による「[認可ID]<NULL>認証ID<NULL>パスワード」形式のユーザー認証方式である。Base64でエンコードする場合もあり、SSLなどによる暗号化の利用が前提になる。認可ID、認証IDは一般にはユーザー名を使用する。

LOGIN

　 LOGINも同様に平文を用いた認証形式で、現在のところ最も普及している方式だが、実は標準仕様書というものが存在しておらず、各社製品間の互換性もあまり考慮できていないようだ。今後はPLAINなどより標準的なものに収れんしていくものと思われる。

CRAM-MD5（RFC2195）

　CRAMとは、Challenge-Response Authentication Mechanismの意味だ。接続先MTA（サーバ）からあらかじめ示された任意の文字列（Challenge）にクライアントがパスワードを含め、MD5アルゴリズムにより「メッセージダイジェスト」と呼ばれる一種のチェックサム値を取り出し、これをサーバへ送信する。サーバでも同様の検証をして、このメッセージダイジェストが等しければ、クライアントが正しいパスワードを知っている証拠だとして、ログインを許可する。この方法ではパスワード自身がネットワークに流れることがないので、安全性は高くなる。

図4　CRAM-MD5での例

DIGEST-MD5（RFC2831）

　CRAM-MD5の欠点である辞書攻撃や総当たり攻撃に対する対処とともに、Realm（ログイン領域）やURLの指定（これらはHTTPなどへの応用を想定している）や、HMAC（keyed-Hashing for Message Authentication Code）による暗号化をサポートしている。

　まだSMTP-AUTHへ対応したクライアント、サーバ製品ともに少ないが、オープンソースを中心に一部では利用も始まっている。

^＊1ここでは1つの対応例として示している。MTAによっては、1つのMTAで接続元に応じてリレー制限とSMTP-AUTHなどを切り替えるなどの対応も可能のようだ

^＊2そのほか、ISPの運営するMTAでは「POP before SMTP」と呼ばれる方法が現在はポピュラーだ。これはPOPでログインを行った後、一定期間（5分間など）のみ、同一のIPアドレスからのSMTP接続を可能にする方法だ。SMTPサーバとPOPサーバの機能が連動しなくてはならない。クライアントにさして変更もなく簡易に導入できるメリットはあるのだが、IPアドレスの詐称などは技術的にも可能であるし、それほどセキュアだとはとらえられていないので、SMTP-AUTHが普及するまでのつなぎとの理解が一般的だ

（追記：2001年5月18日）

　2001年4月付けで、SMTPおよびインターネットメール・フォーマット（MIMEは含まない）の新しいRFCとなるRFC2821およびRFC2822が公開された。RFC821／RFC822、そのほか関連するRFCは、今後HISTRICな（歴史的にすでに古い）仕様として扱われる。

　RFC2821は、RFC821およびRFC974（DNSによるメールルーティング）、RFC1869（SMTP Extention）などを統合／整理した修正版となっている。これまでのように、各仕様にまたがっていた煩雑さがなくなり、分かりやすくなったと歓迎できるだろう。

　主な変更点は以下の通り。

SOMLコマンドなどあまり使われなかったコマンドが廃止された
EHLOコマンドは必須となった。すなわちESMTP仕様に含まれる8ビットMIMEやSIZEなどの有益な機能のデフォルト使用が推奨されることになったと言える
各コマンドのタイムアウト時間の定義
ゲートウェイなどにおけるReceivedフィールドのフォーマットの明確化
リクエスト（コマンド）とレスポンス行（リプライ）の最大は512文字までとなった。そのほかのテキスト行は1024文字まで
そのほか、ドメイン名の文字数や同時に指定できる送信先数などの最大数も定義された。こうした最大数の明確化は、バッファオーバーラン対策にも有効だ

　SMTPの歴史はまさにTCP/IPをベースにしたインターネットの歴史とぴたりと一致する。シンプルな実装技術こそが身上だったSMTPの後半生は、セキュリティ技術の追加によって複雑化の一途をたどっている。公開のための簡便さと隠ぺいのための複雑さの間で揺れ動くさまは、まさに近年のインターネットの姿を映し出しているといってよい。

　次回はメール受信プロトコルのPOPについてお送りしよう。

「次回」へ

「インターネット・プロトコル詳説」バックナンバー