|
||||||||||||||||||
 |
||||||||||||||||||
|
||||||||||||||||||
その19「SMTPの機能と問題点」 |
||||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
|
||||||||||||||||||
|
SMTPとは「Simple Mail Transfer Protocol」の略で、電子メールを転送するためのプロトコルです。日本語訳すれば「簡単なメール転送プロトコル」という意味になるわけですが、それでは「簡単でないメール転送プロトコルがあるのか？（強いて言えば“CMTP:Complex Mail Transfer Protocol”でしょうか）」と言えば、直接これに該当するものがあるわけではありません。 ただ歴史的に言えば、インターネットが普及するようになる前から電子メールという概念は存在し、実際に標準化されたものもあります。ITU-Tで標準化されたX.400などは、CMTPの代表例かもしれません。X.400についてよく知りたいという場合、こちらのリンク）をたどるのが良いかもしれませんが、本稿ではこれ以上深入りしないことにします。 さて、そのSMTPの説明である「メールの転送」とは、メールサーバー間でのメールの受け渡し以外にも、メールの発信そのものも指します。つまり、SMTPは電子メールを発信する場合、必ずお世話になるプロトコルです。また、このSMTPにもとづいてメールを転送・配信するソフトウェアをSMTPサーバーと言います。 ■ SMTPが使われる場所
この場合、まずクライアントAの上で動くメールソフトでメールを作成してから、自分の所属しているドメインのメールサーバーAにメールを投げます。ここでクライアントAとメールサーバーAの間で使われるのが、SMTPプロトコルです。 さて、送ったメールはいったんメールサーバーAのメールキューという一時保存エリアに格納され、ここから目的地まで転送されます。この場合、メールサーバーAからメールサーバーCに直接転送できる場合もあれば、1度別のメールサーバー（この場合なら、メールサーバーB）を介して転送される場合もあります。 ここ数年は、ほとんどのプロバイダーやドメインが直接IX（Internet eXchange）に繋がっており、AからCへの直接転送が当たり前なのですが、以前は間接的に接続されていることが珍しくありませんでした。この場合は、A→B→Cといった具合に、複数のメールサーバーを間に介してバケツリレー式にメールが転送されていったわけです。 さて、無事にメールがメールサーバーCに到着すると、メールサーバーCはこれをcさん（c@C.com）用のユーザーメールボックスに格納します。SMTPが介在するのはここまで、つまり届いたメールがユーザーメールボックスに格納されるまでで、届いたメールをクライアントCで読み出す際にはSMTPは使われません。 ちなみにSMTPの2大機能は、転送（Transfer）と配信（Delivery）です。このうち配信というのは、メールサーバーCに届いたメールをユーザーメールボックスに配ってまわる作業で、それ以外はすべて転送としてとらえられます。 転送と配信という機能は、郵便に近いものがあります。クライアントA→メールサーバーAの転送は、言ってみればポストに郵便を投げ込むのと、これが定期的に郵便局によって回収される作業。そして、A→CもしくはA→B→Cという転送は、投函された最寄りの郵便局から、目的地に1番近い郵便局まで配信する作業、そして最後の配信というのは最寄りの郵便局から個別のポストに分配して配達する作業になるわけです。 ■ SMTPの問題点とさまざまな対策 実のところ、当初利用されたSMTPは非常に単純かつ、性善説に基づいたプロトコルでした。先の郵便の例に戻りますが、要するに宛て名が書いてあって、かつ郵便物の大きさに見合った切手が貼ってあれば、その中身がどうかということは通常問われません。それがダイレクトメールか、家族からの便りなのか、ラブレターなのか、はたまた実は脅迫状なのか、という話は郵便局では原則として問いません。これと同じように、SMTPも差出人が誰かは一切問いませんし、プロトコルさえ準拠すれば、差出人がどこのドメインに所属しているかすら問わないというものでした。 性善説で運営が可能だった初期の段階ならば、これでもさして問題はなかったのでしょうが、インターネットが商用で広く利用されるようになって出てきた問題がスパムメール（迷惑メール）です。要するに、不特定多数に対して無節操にメールを送りつけるスパムメールに対し、最初はスパムメールを送り出すサイトを登録して、そこからのメールを受信しないという対策が取られるようになりました。 図2で言えば、スパムメールを送り出すドメインからのメールは、ドメインCで転送を拒否するというやり方です。このままだとドメインCから見れば「スパムが送られてこない」ので幸せなのですが、逆にスパムを送り出す側からすれば、ドメインCにメールが送れないのは困るわけです。 そこで考えられたのが、メールサーバーBを経由するというやりかたです。要するにSMTPの転送を使って、スパムメールをCに送りつけるわけです。こうなると、ドメインCから見る限り、それがスパムメールなのかドメインBからの正規のメールか判断つかないので、スパムメールを受け入れざるを得なくなってしまいます。 もちろん、内容を見ればスパムメールであることは明白なのですが、先の郵便での例えでも述べた通り、SMTPではメールの中身のチェックは一切行ないません。あくまでも宛先のアドレスが正しいかどうか、が判断基準なわけです。 ですから、そもそも中身をチェックする機構を持っていない（*1）わけで、SMTPの側でこれに対処するのは難しいのです。最終的に、これに対しては「勝手にメールリレーを行なわない」という対策をSMTPサーバー側で施す形で対策が施されているのが実情です。 *1：最近はウィルスチェックなどにも絡んで、転送や配信を行なう前に中身をチェックするSMTPソフトも増えてきましたが、この方式が標準化されているというわけではありません。
さて、こうして転送を使ったスパムメール配信ができなくなったので、次なるアイディアとして登場したのが、他のSMTPサーバーを勝手に使うという方式です。要するに自ドメインのメールサーバーからの転送が引っかかるわけですから、はじめから他のメールサーバーを使ってメールを送れば、転送禁止に引っかかることなくスパムを配信できるというわけです。 図3はこれを示したもので、スパム生成クライアントはインターネット経由で他のSMTPサーバーに接続し、ここからメールを発信する形を取るわけです。最初に書いた通り、最初のSMTPではユーザー認証も何もなく、誰でも手軽に発信できる仕組みになっていましたので、これは非常に簡単にできてしまいます。結局、短期的な対策としてSMTPサーバーは自ドメインからの発信（図3の例で言えば、ドメインBのSMTPサーバーは、ドメインB内部のクライアントからの発信）のみを受け付け、そのほかのドメインからは一切発信できない様な制限を付けているのが一般的です。 ただ、このアプローチでは問題も残ります。例えば、普段Bドメインに所属しているクライアントがあるとしましょう。このクライアントがノートPCで、時々は持ち歩くこともあったりして、例えば自宅や出先のホットスポット、あるいはPHSなどでインターネットと接続するなんてことは十分にありえます。こうした外部に出ているとき、「自ドメインのみ発信許可」という方法では、メールが発信できなくなってしまいます。
そこで、SMTPにユーザー認証を付け加えるという形で、正規ユーザーはどんなドメインからアクセスしてきても、メールを発信できるような仕組みが一般的になりつつあります。最も代表的なのはPOP before SMTPと呼ばれる方式で、SMTPを使って送信する前にPOP3を使って（POP3については次回お話します）、いったんユーザー認証を行ない、それからSMTPを使って発信を行なうという方式です。 この方式だと、既存のSMTPの変更なしで実施できるという点で便利なのですが、いかにも取って付けた感は否めませんし、潜在的にはいくつか問題があります（POP3による認証とSMTPによる送信の間を狙われると無力になってしまうなど……）。 こうしたことに対する根本的な解決案として次第に普及しつつあるのが、ESMTP（Extended SMTP：拡張SMTP）に含まれるSMTP-AUTHという仕組みです。ESMTP自体はSMTPをさまざまな面で拡張する仕様で、SMTP-AUTHだけが新機能というわけではありませんが、本稿では割愛します。 SMTP-AUTHですが、要するにメールを送信する前に、それが登録された正規ユーザーかどうかをSMTP自体で認証しようというものです。この認証方式には、ユーザー名/パスワードを平文で送りつけるPLAINとか、これを少し拡張したLOGIN、ユーザー名/パスワードを暗号化したCRAM-MD5とかDIGEST-MD5など、いくつかの種類が存在しています。一番安全と考えられているのはDIGEST-MD5ですが、SMTPサーバーとクライアント側のメーラーの両方で対応する必要があるため、現時点でもそれほど広く普及しているわけではありません。 ただ、こうした方式を持ってしても、SMTPの持ついくつかの欠点は相変わらず残されています。その最たるものが、「発信者を詐称できる」というもので、スパムメールやウイルス、最近だとフィッシング詐欺にはなくてはならない重要なファクターにまでなってしまいました。根本的な解決案としてはSMTPを捨てるしかないわけで、これに絡んでMicrosoftが提唱したSender-IDは、確かに発信者詐称に対する根本的な解決案であることは事実ですが、現時点では有力な代替プロトコルは決まっていないのが実情です。
2004/12/13 11:05
|
 |
|
| Broadband Watch ホームページ |
|
|
|
|
|
|
| Copyright (c) 2004 Impress Corporation, an Impress Group company. All rights reserved. |