小沢民主のネタ多すぎだろJK…沙耶です。いい加減多すぎて飽きたってーか疲れた。
打たれ弱すぎる。

というわけでなんか別のことを書こう。
何を書こうかなぁ。


メール。電子メール。一般には送ったらすぐに相手につくと思ってる人多数。
嫁さんも例外じゃなかったけど。

さて、メールを送信して相手に着信するまでに、最大どれくらいかかると思いますか？

答え：わかりません


流石投げっぱなしジャーマン的に適当かついい加減プロトコルであるsmtpです。
Simple Mail Transfer Protocol、SMTP。基本的にインターネットの通信はみんな投げっぱなしジャーマンです。トークンリングじゃねぇんだしｗ
これらの基本的な考え方はトライ＆エラーによるもので、やってみてダメならもう一回やってみればいいじゃない！！という至極適当かついい加減な精神によるｹﾝﾁｬﾅﾖﾌﾟﾛﾄｺﾙです。

だいたい一定回数、もしくは一定期間がすぎてもダメだと「もういいやｗｗｗｗ」ってあきらめます。

これがいわゆるタイムアウトやホップオーバーと呼ばれるものですね。
このため、実はメールが相手に届くまでの時間どころか、そもそも相手に届くかどうかも実は誰もわかりません。ついでに責任も持ちません。
重要な話をメールで送ったのに届かないとか怒らないでください。届く保障なんて誰もしていません。
むしろなんでそんな大事な話をメールしたんですか馬鹿って言い返されかねません。

電話しましょうｗｗｗｗｗｗｗ

さて、メールでしたか。あなたがAさんのメアドにメールを送ると、まずメールはあなたのメールソフトから、あなたのメールソフトに登録されているsmtpサーバに送られます。

ちなみに、そもそもですね。

あなたのメールソフトとメールサーバのやり取りは、メールサーバが他のメールサーバとやり取りする方法とまったく同じです。
基本的に、”メールソフトから送られてきたメール”と”どっかのメールサーバが送ってきたメール”をメールサーバは区別しません。ていうかできません。

このときに、メールサーバはどこかしらから送ってきたメールの何を見てるか、というと宛先しか見てません。

Aさんあてに送ったメールの、まずはドメイン部を見ます。
たとえばyoshino_yomogiya@aho.jpあてに、私がsaya@eden.dyndns.tvからメールを送ると、メールはまず沙耶の自宅のメールサーバであるeden.dyndns.tvに受け付けられます。

edenメールサーバは@以降のドメイン部を見ます。

「宛先aho.jpか。」

そしてとんでもない結論を出します。

「俺の管理下にあるドメインじゃないから受取拒否しますねｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」

そして送信者にエラーを。ってこれじゃ届きません。
ただ、この挙動が原則であると理解してください。

逆にですね、正しく設定したなら、メーラーからaho.jpのメールサーバに直接メールをブチ込むことは可能です。
いまはOP25Bなんかで動的IPからそれをやるのは止められることが多いですけどね。

さて、しかしこれじゃどこにもメールが飛んでいきません。

そこで出てくるのがオープンリレー。要はですね、もともとメールサーバってどこあてのメールだろうが誰が発信したメールだろうが受け取って配信してたんです、どこのサーバも。
古き良きインターネット黎明期。そこには悪意を持ってこの新しいメディアをどうこうしようとする悪人はそもそもほとんど存在しておらず、インターネットを流れるトラフィックは参加者一人一人の心がけによって抑制されていたのです。

いまでは信じられないかもしれませんが、画像を載せたWebページは”悪”とすら言われた時代が存在しました。NetScapeは画像表示能力を持っているから悪。MOSAICを使えと。
そんな時代、SPAMメールなんてものはほとんど存在せず、メールサーバはどこあてのメールだろうが受け取り、宛先のサーバに転送していました。

これを、オープンリレーといいます。もっとも、今どきこんなサーバが存在したら存在するだけで”悪”だといわれますけどね。

しかし、自分宛のメールだけ受け取っていてもしようがありません。一部の不適切な自分宛以外のメールは拒否するにしても、一部の正しいメールは自分宛でなくても受取り、転送してあげないと、ユーザーは自分の送りたいアドレスに合わせて接続先となるSMTPサーバを書き換えなければならないというひどく煩雑なことに頭を悩ませることになります。

これを実現するための手法が、ある条件を満たした時に、その接続者からの通信に対してオープンリレーサーバとしてふるまう、というものです。

もっとも代表的かつ古くから使われた手法が、POP before SMTPと呼ばれるもの。

送信にあたるSMTPにはもともとそんなオープンリレー体質でしたので、個人認証と呼べるものは実装されていません。そこで、もともと自分のメールボックスを読み取るための認証システムを内蔵した、POPをその代用として用いればいいではないか、というものです。
Post Office Protocol、POP。POP3と言えばPOP Version 3のことです。もちろんPOP2なんてのもあります。現在はほとんど使いませんが。

POP3による受信動作は、個々人のメールボックスを読むため、ユーザー認証を行います。
このため、このPOP認証を通過したIPアドレスを記録し、そのIPアドレスからのメール送信の通信は、宛先を気にせずに受け取る、というものです。

これは、既存のシステムに最小限の変更ですむのが特徴でした。SMTPに最小限の変更を施すだけですみました。
何をやってるかというとですね。

POPの通信ログを適宜チェックして、認証を通過したIPアドレスと時間を記録しているプログラムが動いているだけです。
こいつが、IPアドレスと時間のペアとなる許可リストを作成し、SMTPサーバプログラムの読める形に整形し直し、オープンリレー許可リストとしてSMTPサーバはそのファイルを参考にしているだけです。

一定時間が経過したIPアドレスはそのリストから削除されます。実はこれはものすごい単純な仕組みだったりします。
実際、POP before SMTP用のプログラムは多種ありますが、Perlなどで書かれたものでも、ほんの100行やそこらのプログラムだったりします。

実に場当たり的な対処ですが、長らくこの方式は利用され続けてきました。
その最大の理由は、メールソフト側の対応が全く必要なかったことにあります。メールソフト側の変更は、せいぜい送信前に一回だけ受信ルーチンに飛ぶ、というだけの変更であり、普通に作ってあるメールソフトなら変更はわずか一行で済みます。オプションの表示とかを加えるならもちっと多くなりますけどね。

当然ですが、そもそもSMTPに個人を認証するシステムがないのが問題の原因なのですから、SMTPに認証をつければいいじゃないか、って考えは当初から存在しました。
それが、SMTP-AUTH。

これは非常に強力で、一回のセッションで一回の認証を必要としているので、POP before SMTP特有の弱点である、”一回認証して送り終わったあとにIPアドレスが変わった場合やルータ配下からの通信は他人のPOP認証を利用して送信してしまえる”という、IPアドレスによる個人特定の欠陥を埋めるものでした。

ところが、このSMTP-AUTH、まったく流行りませんでした。つい最近まで、ほとんどこのSMTP-AUTHをメインストリームにしているサーバはなかったといっても過言ではありません。

理由はいろいろありますが、もっとも大きなものは、
・メールソフトがほとんど対応してくれない。
でした。SMTP-AUTHは認証と同時にいくつかの暗号化処理への対応も機能として持っており、割と複雑な処理でした。
認証のメカニズムはPOPなどと共通ではなく、作者はSMTP-AUTHの仕様を調べ、実装し、テストし、という行為をしなければならず、普及は遅遅として進みませんでした。

現在でも、まだ探せばSMTP-AUTHに対応できないメールクライアントはたくさん存在します。

ちなみにOEなんかはSMTP-AUTHへの対応は早かったのですが、いまだにPOP before SMTPに自動対応しないという素敵ソフトです。むしろ送信メールがあると”送受信”ボタンを押したときに送信から処理を開始するため、絶対にPOP before SMTPを阻害することが確定している素敵仕様です。

マジ死ね。

これを大きく変えたのは、最近のOP25Bの普及です。

IPアドレスで個人を特定しにくい（プロバイダはできるが）一般向けの動的IPアドレスサービスでは、ルータ配下などのネカフェなどからの送信に対処できません。
このため、SMTPの通信をそもそもプロバイダから外に出さないようにしてしまいましょう、という動きが広まりました。
CATVや固定IPアドレスサービスなど以外の動的IPアドレスサービスでは、現在ほとんどのプロバイダが25番ポートへのアクセスは自社メールサーバ以外にはつながらないようになっています。

これは、SPAM対策の一環として行われていますが、さて、これで困ったのはレンタルサーバやメールサービス業者です。
まあ別に送信のみをプロバイダ経由でやってくれりゃいいんですが、ユーザーにそんなややこしいことはわかりませんし、そもそも出先のホテルとかのたびに設定を変えるんですかｺﾝﾁｸｼｮｰって話になるので、外部接続のためのアイデアが、SMTP-Submissionです。

これはSMTP-AUTHを仕込んだ状態で別ポートで待ち受け、必ず認証を経由して送信しましょう、というものです。
別に25番ポートが全部SMTP-AUTH必須になればいいじゃないか、って思う次第ですが、そもそもそんな強制力は誰にもないため、SMTPのままのサーバも多々残ってしまうのは明白。
というわけで、除外しちまえ、って暴力的な手法に出たわけです。

次第次第に認証と暗号化の重要性はサーバ側は重要なものとして受け止めて広まりつつあるのですが、やはりまだまだ成長途中。
ちなみにhttpsで有名なSSLですが、これもまた個人認証に使われることがあります。
公開鍵暗号は現在非常に普及している暗号化方式ですし、それ自体はとても強力ではあるのですが、ややこしすぎてそもそも暗号化のなんたるかを理解してるのはいったいどれくらい存在するんでしょうね。

はい、以上適当なSMTPのお話でした。
暗号化はまた今度。DESだのAESだの公開鍵暗号だのって俺も実は完全にわかってないですけどね。
暗号化するときはライブラリを使うのが当たり前ですし、OpenSSLに丸投げするのが原則。
自分で実装してみますとかは研究目的以外ではまずやらないでしょう。

GPL汚染されるのはいやだってはなしになってくると別ですけどねー。WindowsだとMS SSLライブラリがつかえるのかにゃー。
Windowsはよーしらん。