SMTPの変遷

はじめに。

いまや普通に使われている電子メール。元は研究者同士や仲間同士の情報交換に利用するツールだと思われていたのに、今ではビジネスに必須のツールとまでいわれるように成長した。LINEでいい？出直してこい

今回はそんな電子メールのプロトコルであるSMTPの辿った変遷ついて書いていこうかなって思う。

電子メールそのものの起こりやマイナーなことは触れないつもり。

//この記事は個人的な意見・見解を含みます

SMTPってなに？＞＜

名前は聞いたことはあるけどよくわからないって人多いと思う。

SMTP(Simple Mail Transfer Protocol)、読んで字の如くである。

配送プロセスは非常に単純(中身はそうでもないが)で

「オレ、オマエニ、メール、オクル」

「ワカッタ」

という感じで2台間でコネクション張って直接データのやり取り。

課題とかをUSBで受け渡すよね？要はあれをお互いのtcp/25を介してやるだけ。

下位プロトコルなのでDNSで宛先IPがわかれば後はTCPやIPにお任せ。

設計も古く、シンプルゆえに枯れた技術といっていい。

伝送手順や構造はだだ長くなるので割愛、自分で調べて知見を深めるのもいいものだよ。

 

SMTPってやばいんじゃね？

SMTPはその性質上、送信するときに相手と対話的にやり取りをして通信する。

そのやり取りはすべてテキストベースで行う。←ITを少しでもかじってる人には察してほしい

つまりSMTPコマンドとその応答を理解していれば手動でもできる。

例を示すと、

220　ArGoSoft Mail Server Freeware, Version 1.8 (1.8.4.4)

HELO

250 Welcome [127.0.0.1], pleased to meet you

MAIL FROM:hoge@hogehoge.jp

250 Sender "hoge@hogehoge.jp" OK...

RCPT TO:test@usohappyaku.com

こんな感じ、大体わかるよね。

 

実はこのSMTP、なんと元から認証機能がない。つまりITの腕に覚えがある人なら....?

多少の驚きを感じてくれたならうれしい。

急成長してしまったがゆえになりすましやり放題、スパムの温床と化してしまったのである。

 

POP before SMTP

これはまずいと、技術者たちがとりあえずの避難策として編み出したのがPOPbeforeSMTPである。

これは、POP3に組み込まれているユーザIDとパスワードによる認証機能をSMTPそのもののシステムを触らずに利用するしくみである。合体！

メールの送信をする前にPOP3をかませてユーザーが確かに本人であることを確認し、SMTP接続を許可する。こうすることでSMTPに大きな変更を加えることなく、なりすましなどを防げる。

一見すると、割と理にかなっているなあ...と思うかもしれないがそれは大きな間違い

先述したがSMTPはテキストベースでのやり取りを行うので、デフォでパスワードが丸見え状態で送受される。

SMTPとPOP3をそのまま流用している、要は付け焼刃だったので末恐ろしい脆弱性を残したままになったのだ。

SMTP-AUTH(SMTP Authentication)の誕生

当然、認証とは別に暗号化を組み入れようということになる。

POP before SMTPはPOP3通信を行っている送付ノードを認証しているだけで、SMTP自体はなんら変わってない。

「じゃあSMTPに直接認証機構組み込んじゃえばよくね？」

言うは易く行うは難し。しかし実装する。この業界変態ばかりだからね(褒め言葉)

SMTP自体に認証機構を組み込むことで、SMTP通信の正当性を保証する。

完璧なSMTP、これこそ我らが悲願、人類補完計画。

SMTP AuthenticationではPOP3のようにユーザーIDとパスワードによる認証を行うがAUTH PLAIN やAUTH CRAM-MD5 など数種類の認証方法が提供されている。

SMTP AUTHはSMTPの拡張ではなく仕様そのものを改良してるため従来のSMTPに対応したソフトウェアでは通信できない。PS4でPS3のソフトができないのと同じ。

SMTP Authenticationの最初の仕様は、インターネット関連技術の標準化を推進するIETFによりRFC 2554「SMTP Service Extension for Authentication」として1999年に発行され、2007年のRFC 4954によって更新された

これでずいぶんマトモなものに仕上がった、SMTPの進化もここで打ち止めというわけだ。

サーバとクライアントの双方が対応してなければ利用できないため、様々な加入者が利用するインターネットサービスプロバイダ(ISP)などでは旧来の方式から徐々に切り替えが進められて、近年では多くのサービスでSMTP Authenticationによる認証が必須となっている。

 

おまけ...

SMTPの拡張機能にMIMEというものがある。

SMTPの仕様では扱える文字コードはASCIIに限定されている。

これは今でも変わっていない、ずっとASCIIのみ。

そもそも開発グループが英語圏なので致し方ないが、急速に普及したことによって漢字やアラビア語を利用する言語圏では無理が出始めてきた。

こいつはそんなみんな大嫌い文字コード問題を解決してくれる拡張機能だ！

ついでにデータや画像なんかも添付したいというニーズに応えてるんだぜ！

まぁ文字列をBase64でASCIIに変換してるだけだし変換後はデータ量が約1.4倍に増大するけどね。

こいつもSMTPと同じように暗号化を盛り込むことになり、更に拡張した

S/MIMEが誕生した。まさにスーパーサイヤ人の中のスーパーサイヤ人。

そのうちS/MIME-AUTHとかでてくるんじゃないか.......

 

まとめ

どうだっただろうか、SMTPは情報セキュリティ三大要件のお手本の如く機密性、完全性、可用性をことあるごとに更新していったいい例だと思う。

SMTP自体のことやPOP3の詳しい仕様、次世代のPOP3であるIMAPなど、かなり割愛してる部分があるので興味が湧いたら調べてみてほしい。いや、調べろ。

開発に携わるのなら成果物自体の完成度はもちろんだが、セキュリティ面にも是非気を配りたいところ。

サーバーを建ててデータのやり取りをするなら尚更である。実装が簡単な認証、暗号化もあるので利用できるなら利用しよう。

この機会にここら辺にハマってズブズブとネットワークの世界にのめりこんでくれたのならとてもうれしい！

おわり。