TCP/IP の初期
70 年代後半から 80 年代前半にかけて、ARPANET が後にインターネットとして知られるネットワークとして発達し始めた頃、E メールは混乱的ではあったものの、非常にポピュラーなアプリケーションでした。ポピュラーであった理由は、世界中の人々が意見交換するための手段を革新する通信技術としてすぐに認知されたためであり、混乱的であった理由は、E メールは無数の独自技術によって実装されていたので、相互運用性がなかったためです。すぐに、E メール技術を真に普遍的な意見交換手段とするには何らかのプロトコルが必要であるという認識が生まれました。
SMTP（Simple Mail Transfer Protocol）の開発
SMTP は、メールを転送するための確実で効率的な、かつ普遍的な手段として開発されました。SMTP モデルは、次の２つの要素で構成されます。メール転送エージェント（Mail Transfer Agent、MTA）とユーザーエージェント（User Agent、UA）です。
メール転送エージェントには、次の２つの役割があります。
- 他のメール転送エージェントからのメッセージの送信と受信
- ユーザーエージェントとの対話
ユーザーエージェントには、次の２つの役割があります。
- メール転送エージェントとの対話
- ユーザーフレンドリな環境を提供し、ユーザーから SMTP の実装を隠蔽
このモデルによって、SMTP の作成者は普遍的な実装を実現できるようになりました。データは TCP によって送信されるため、この機能の信頼性も同様に確保できます。
こうして普遍的なメール転送が実現されましたが、完全ではありませんでした。SMTP の仕様では、次の２つの重要な問題を処理できなかったのです。
- 転送可能なデータが７ビットのみ。設計当初、SMTP の現実的な用途は、７ビットである ASCII プレーンテキストの転送のみでした。この結果、すべてのメール転送エージェントがこのデータ形式を転送するように実装されたのです。これは、やがてマルチメディアが出現し、８ビットデータの方が一般的になるに従い、いくつかの問題を生じさせることになります（MIME のトピックを参照）。
- 受信側でメッセージを待ち行列に入れることができない。したがって、メールサーバー、および関連するローカルなメール配信システムがクライアント側に常駐し、常に稼働していなければなりませんでした。当時爆発的に利用が広まっていた小型コンピュータのほとんどには、メール配信システムを常駐させ、常時稼働しておくだけの十分なリソースがありませんでした。複数の接続が長時間維持されると、メールサーバーにも大きな負荷がかかりました。このようなことから、メール受信を処理するための新たなプロトコルを将来的に追加する必要性が生じたのです。
POP（Post Office Protocol）の開発
SMTP は、普遍的で確実な、効率性の高い E メール転送機能の実装に成功しました。しかし、最終的な「メール回収」地点がないため、接続が長引いてしまいます。Post Office Protocol（現在はバージョン３であり、一般に POP3 と呼ばれる）は、メールをキューに入れ、ユーザーエージェントに配信するための共通システムの提供を目的として実装されました。このプロトコルでは、メールサーバー上に「メールドロップ」を作成する必要があります。これは、SMTP によって配信されたメールが置かれ、受信者が回収するまで保管しておく場所です。POP は基本的に、ユーザーエージェントをメールドロップと対話させることで機能します。この対話は、具体的にはログイン、メッセージのダウンロード、およびログアウトという形で行われます。POP の実装は、メール転送システム全体を必ずしも常時接続および常駐させておかなくても良い点で成功でした。SMTP と POP の組み合わせは十分に機能しましたが、これでも完全ではありません。この段階でまだ足りないものは、ASCII 以外のデータを転送する機能と、サーバー上で E メールを操作するための高度な手段です。これらの問題は、MIME（Multipurpose Internet Mail Extensions）および IMAP（Internet Message Application Protocol）の開発によって解決されました。
POP プロトコルに関する詳細は、「POP3 プロトコルの概要」を参照してください。
MIME（Multipurpose Internet Mail Extensions）の開発
７ビットの ASCII テキストしか転送できない機能では極めて制限が大きく、この問題はマルチメディアファイルの登場でより深刻化したため、MIME の開発が必要となりました。ASCII 以外のファイルを送信することは難題でした。このようなファイル形式のほとんどは、通常の状態で８ビットだったためです。メール転送エージェントが７ビットのデータしか転送できないことを思い出してください。MIME では、ASCII 以外のファイルも転送できるように、メッセージの新たな組み立て方法、および８ビットデータをエンコードするためのアルゴリズムを規定しました。
MIME プロトコルに関する詳細は、「MIME の概要」を参照してください。
IMAP（Internet Message Application Protocol）の開発
POP は、現行機能自体は便利ですが、いくつか欠けている機能があります。POP では、サーバー上にある E メールを操作できません。また、複数のコンピュータからメールにアクセスすることもできません。POP の仕様では、いったんダウンロードされたメッセージはメールサーバーから削除され、ローカルコンピュータ上にコピーが１つ残るだけでした。IMAP では、サーバー上の「メールボックス」を使用してメッセージを操作できます。メールボックスは、フォルダやディレクトリに相当する機能です。ユーザーエージェントは、メールボックスを作成、削除、および名前変更でき、E メールを別のメールボックスへ移動、ダウンロード、および削除することができます。IMAP では E メールがメールサーバー上に残されるため、別のコンピュータからのアクセスも可能になります。IMAP は明らかに POP より高度なプロトコルですが、すべてのメールサーバーが IMAP をサポートしているわけではありません。したがって、POP は現在でも広範に使用されています。
IMAP プロトコルに関する詳細は、「IMAP4 プロトコルの概要」を参照してください。
インターネット E メールモデルの現状
現在の E メールモデルは、SMTP、POP、IMAP、MIME（およびその他の数多くの技術）の複合体です。メッセージ送信には SMTP が、受信側メールサーバー上で、ダウンロードを待つメッセージをキューイングするには POP が、受信側メールサーバー上でメッセージを保管し、サーバー側からの操作を可能にするためには IMAP が、ASCII 以外のデータの送信方法を定義するには MIME がそれぞれ使用されています。次の図は、この関係を示します。
