インターネット メッセージ アクセス プロトコル

コンピューターの世界では、インターネットメッセージアクセスプロトコル（IMAP）は、電子メールクライアントがTCP/IP接続を介してメールサーバーから電子メールメッセージを取得するために使用するインターネット標準 プロトコルです。^{[1] IMAPは}RFC 9051で定義されています 。

IMAPは複数のメールクライアントによるメールボックスの完全な管理を可能にすることを目的として設計されているため、クライアントは通常、ユーザーが明示的に削除するまでメッセージをサーバー上に残します。IMAPサーバーは通常、ポート番号143でリッスンします。IMAP over SSL/TLS（IMAPS）にはポート番号993が割り当てられています。^{[2] [3]}

事実上、すべての最近の電子メールクライアントとサーバーはIMAPをサポートしており、これは以前のPOP3（Post Office Protocol）とともに、電子メール取得のための2つの最も一般的な標準プロトコルです。^[4] GmailやOutlook.comなどの多くのウェブメールサービスプロバイダーも、IMAPとPOP3の両方をサポートしています。

インターネットメッセージアクセスプロトコルは、電子メールクライアントがリモートメールサーバー上の電子メールにアクセスできるようにするアプリケーション層のインターネットプロトコルです。現在のバージョンはRFC  9051で定義されています。IMAPサーバーは通常、よく知られているポート143でリッスンしますが、IMAP over SSL/TLS（IMAPS）は993を使用します。^{[2] [3]}

受信メールはメールサーバーに送信され、受信者のメールボックスにメッセージが保存されます。ユーザーは、数あるメール取得プロトコルの1つを使用するメールクライアントでメッセージを取得します。一部のクライアントとサーバーはベンダー固有の独自プロトコルを優先的に使用しますが、^{[5]ほぼすべてのクライアントとサーバーはメールの取得にPOPとIMAPをサポートしており、} Pegasus MailやMozilla Thunderbirdなどの多くのメールクライアントから自由に選択してこれらのサーバーにアクセスでき、クライアントを他のサーバーで使用することもできます。

IMAP を使用する電子メール クライアントは、通常、ユーザーが明示的に削除するまでメッセージをサーバー上に残します。IMAP 操作のこの特性とその他の特性により、複数のクライアントが同じメールボックスを管理できます。ほとんどの電子メール クライアントは、メッセージを取得するために、Post Office Protocol (POP)に加えて IMAP をサポートしています。 ^[6] IMAP はメール ストレージへのアクセスを提供します。クライアントはメッセージのローカル コピーを保存できますが、これらは一時的なキャッシュと見なされます。

IMAP は、広く使用されている POP (メールボックスの内容を単に取得するプロトコル) とは対照的に、リモート アクセス メールボックス プロトコルとして 1986 年に Mark Crispinによって設計されました。

現在のバージョン 4rev2 (IMAP4) に至るまで、以下のように数多くの反復を経てきました。

オリジナルのInterim Mail Access Protocol は、Xerox Lisp MachineクライアントとTOPS-20サーバーとして実装されました。

元の暫定プロトコル仕様やそのソフトウェアのコピーは存在しません。^{[7] [8]}一部のコマンドと応答はIMAP2に類似していましたが、暫定プロトコルにはコマンド/応答のタグ付けがなかったため、その構文は他のすべてのIMAPバージョンと互換性がありませんでした。

暫定プロトコルは、すぐにRFC  1064 (1988 年) で定義され、後にRFC 1176 (1990 年) で更新されたInteractive Mail Access Protocol (IMAP2)に置き換えられまし た。IMAP2 はコマンド/応答のタグ付けを導入し、公開された最初のバージョンでした。

IMAP3 は IMAP の非常に珍しい変種です。^{[9] 1991 年に}RFC 1203として公開されました。これは 、IMAP2 の修正を提案したRFC 1176 に対する反対提案として具体的に書かれました。 ^[10] IMAP3 は市場に受け入れられませんでした。^{[11] [12]} IESGは1993 年に RFC1203「インタラクティブ メール アクセス プロトコル – バージョン 3」を歴史的プロトコルとして再分類しました。IMAP ワーキング グループは、RFC 1203 (IMAP3) ではなく RFC 1176 (IMAP2) を出発点として使用しました。^{[13] [14]}

MIMEの登場により、IMAP2 は拡張され、MIME 本文構造がサポートされ、IMAP2 にはなかったメールボックス管理機能 (作成、削除、名前変更、メッセージのアップロード) が追加されました。この実験的な改訂版は IMAP2bis と呼ばれ、その仕様はドラフト以外の形式では公開されませんでした。IMAP2bis のインターネット ドラフトは、1993 年 10 月に IETF IMAP ワーキング グループによって公開されました。このドラフトは、未公開の IMAP2bis.TXT ドキュメント、RFC 1176、および RFC 1064 (IMAP2) などの以前の仕様に基づいています。[ 15 ]  IMAP2bis.TXTドラフト に^は、1992年 12 月時点の IMAP2 の拡張の状態が文書化されていました。 ^[16] Pineの初期のバージョンは、IMAP2bis のサポート付きで広く配布されました^[9] (Pine 4.00 以降は IMAP4rev1 をサポートしています)。

1990 年代初頭にIETF内に結成された IMAP ワーキング グループが、IMAP2bis の設計責任を引き継ぎました。IMAP WG は、混乱を避けるために IMAP2bis の名前を IMAP4 に変更することを決定しました。

POP を使用する場合、クライアントは通常、新しいメッセージをダウンロードするのにかかる時間だけ、電子メール サーバーに短時間接続します。IMAP4 を使用する場合、クライアントはユーザー インターフェイスがアクティブである限り接続されたままになり、要求に応じてメッセージの内容をダウンロードします。多数のメッセージや大きなメッセージを持つユーザーの場合、この IMAP4 の使用パターンによって応答時間が短縮される可能性があります。

認証が成功すると、POP プロトコルはメールボックスの現在の状態について完全に静的なビューを提供し、セッション中に外部の状態の変化を表示するメカニズムは提供しません。対照的に、IMAP プロトコルは動的なビューを提供し、新しく到着したメッセージや、同時に接続している他のクライアントによってメールボックスに加えられた変更など、外部の状態の変化を検出し、コマンド間およびIDLEコマンド中に適切な応答を送信する必要があります ( RFC  2177で説明)。また、 RFC  3501 のセクション 5.2 も参照してください。このセクションには、「複数のエージェントによる同じメールボックスへの同時アクセス」が具体的に記載されています。

通常、すべてのインターネット電子メールはMIME形式で送信され、メッセージはツリー構造になります。ツリー構造では、リーフ ノードはさまざまな単一部分コンテンツ タイプのいずれかであり、非リーフ ノードはさまざまなマルチパート タイプのいずれかです。IMAP4 プロトコルを使用すると、クライアントは個々の MIME 部分を個別に取得したり、個々の部分またはメッセージ全体の一部を取得したりできます。これらのメカニズムにより、クライアントは添付ファイルを取得せずにメッセージのテキスト部分を取得したり、取得中のコンテンツを ストリーミングしたりできます。

IMAP4 プロトコルで定義されたフラグを使用することで、クライアントはメッセージの状態を追跡できます。たとえば、メッセージが既読、返信、または削除されたかどうかなどです。これらのフラグはサーバー上に保存されるため、異なるクライアントが異なる時間に同じメールボックスにアクセスすると、他のクライアントによる状態の変更を検出できます。POP には、クライアントがこのような状態情報をサーバー上に保存するメカニズムがないため、1 人のユーザーが 2 つの異なる POP クライアントを使用して (異なる時間に) メールボックスにアクセスした場合、状態情報 (メッセージがアクセスされたかどうかなど) をクライアント間で同期することはできません。IMAP4 プロトコルは、定義済みのシステム フラグとクライアント定義のキーワードの両方をサポートしています。システム フラグは、メッセージが既読かどうかなどの状態情報を示します。キーワードはすべての IMAP サーバーでサポートされているわけではありませんが、メッセージに 1 つ以上のタグを付けることができます。タグの意味はクライアント次第です。IMAP キーワードを、Web ベースの電子メール サービスの独自のラベルと混同しないでください。Webベースの電子メールサービスの独自のラベルは、対応する独自のサーバーによって IMAP フォルダーに変換されることがあります。

IMAP4 クライアントは、サーバー上のメールボックス (通常はフォルダーとしてユーザーに表示されます) を作成、名前変更、削除したり、メールボックス間でメッセージをコピーしたりできます。複数のメールボックスのサポートにより、サーバーは共有フォルダーやパブリック フォルダーへのアクセスを提供することもできます。アクセス権を制御するために、 IMAP4 アクセス制御リスト (ACL) 拡張( RFC  4314) を使用できます。

IMAP4 は、クライアントがサーバーにさまざまな基準を満たすメッセージを検索するように要求するためのメカニズムを提供します。このメカニズムにより、クライアントがこれらの検索を実行するためにメールボックス内のすべてのメッセージをダウンロードする必要がなくなります。

以前のインターネット プロトコルの経験を反映して、IMAP4 は拡張可能な明示的なメカニズムを定義します。基本プロトコルに対する IMAP4 の拡張は数多く提案されており、一般的に使用されています。IMAP2bis には拡張メカニズムはありませんでしたが、POP には現在、RFC  2449 で定義されたメカニズムがあります。

IMAP IDLE は、メール サーバーが接続されたクライアントに、新しいメールが届いたなど、メールボックスに変更があったことを通知する方法を提供します。POP には同等の機能はないため、電子メール クライアントは定期的に POP サーバーに接続して新しいメールを確認する必要があります。

IMAP は POP の多くの欠点を補いますが、本質的に複雑さが増します。この複雑さの多く (複数のクライアントが同時に同じメールボックスにアクセスするなど) は、Maildirやデータベース バックエンドなどのサーバー側の回避策によって補われます。

IMAP 仕様は、厳格さが不十分で、その有用性を事実上否定する動作を許していると批判されてきた。たとえば、仕様では、サーバーに保存されている各メッセージには「一意の ID」があり、クライアントがセッション間で既に見たメッセージを識別できるようにするとされている。しかし、仕様ではこれらの UID をほとんど制限なく無効化することも許可されており、実質的にその目的を果たせていない。^[17]

管理とリソースの観点から見ると、IMAP プロトコルはクラウド コンピューティングの初期の実装と見なすことができます。IMAP の意図と目的は、メールボックス構造 (コンテンツ、フォルダー構造、個々のメッセージの状態など) をメール サーバー上で維持することですが、POP では、これらすべてがユーザーのローカル デバイス上で維持されます。したがって、IMAP ではサーバー側のリソースがはるかに多く必要になり、メールボックスあたりのコストが大幅に高くなります。

サーバー上のメールの保存、インデックス作成、および検索アルゴリズムが慎重に実装されていないと、クライアントが大量のメールボックスを検索するときに大量のサーバー リソースを消費する可能性があります。

IMAP4クライアントは、新着メールの到着を通知するために、IMAPサーバーとのTCP/IP接続を維持する必要があります。メール到着の通知はインバンドシグナリングを通じて行われますが、これがクライアント側のIMAPプロトコル処理の複雑さに多少寄与しています。^[18]プライベートな提案であるプッシュIMAPは、通知だけでなくメッセージ全体を送信することでIMAPを拡張し、プッシュメールを実装します。ただし、プッシュIMAPは一般に受け入れられておらず、現在のIETFの作業では他の方法で問題に対処しています（詳細については、 Lemonade Profileを参照してください）。

送信と取得の操作を組み合わせた独自のプロトコルとは異なり、基本レベルの IMAP クライアントでメッセージを送信してサーバー側のフォルダーにコピーを保存するには、メッセージの内容を 2 回送信する必要があります。1 回目は配信のために SMTP に送信し、2 回目は送信済みメール フォルダーに保存するために IMAP に送信します。これは、IETF Lemonade プロファイルでモバイル デバイス用に定義されている一連の拡張機能によって対処されます。IMAP では URLAUTH ( RFC  4467) と CATENATE ( RFC  4469)、SMTP-SUBMISSION では BURL ( RFC  4468) です。これに加えて、Courier Mail Server は、送信メッセージを専用の送信トレイ フォルダーにコピーすることで、IMAP を使用して送信する非標準の方法を提供します。^[19]

クライアントとサーバー間のIMAP接続を暗号的に保護するには、SSL/TLSを利用するTCPポート993のIMAPSを使用できます。^{[2] [3]} 2018年1月現在、TLSが推奨されるメカニズムです。^[20]

あるいは、最初にプレーンテキストで通信した後、ポート 143 に接続するときにSTARTTLS を使用して接続を暗号化することもできます。

これは、RFC 3501 セクション 8 から抜粋した IMAP 接続の例です。

C: <接続を開く>
S: * OK IMAP4rev1 サービス準備完了
C: a001 ログイン mrc シークレット
S: a001 OK ログインが完了しました
C: a002 受信トレイを選択
S: * 18 存在する
S: * フラグ (\回答済み \フラグ付き \削除済み \閲覧済み \下書き)
S: * 2 最近
S: * OK [未表示 17] メッセージ17は最初の未表示メッセージです
S: * OK [UIDVALIDITY 3857529045] UIDは有効です
S: a002 OK [読み取り-書き込み] SELECTが完了しました
C: a003 12 をフルに取得
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 エンベロープ ("1996 年 7 月 17 日水曜日 02:23:25 -0700 (PDT)"
      「IMAP4rev1 WG mtg の概要と議事録」
      (("テリー・グレイ" NIL "グレイ" "cac.washington.edu"))
      (("テリー・グレイ" NIL "グレイ" "cac.washington.edu"))
      (("テリー・グレイ" NIL "グレイ" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "分" "CNRI.Reston.VA.US")
      ("ジョン クレンシン" NIL "クレンシン" "MIT.EDU")) NIL NIL
      "<B27397-0100000@cac.washington.edu>")
      BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
      92））
S: a003 OK FETCHが完了しました
C: a004 12 ボディ[ヘッダー]を取得
S: * 12 FETCH (BODY[HEADER] {342}
S:    
S:    
S:    
S:    
S:    
S:    
S:    
S:   Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)From: Terry Gray <gray@cac.washington.edu>Subject: IMAP4rev1 WG mtg summary and minutesTo: imap@cac.washington.eduCc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>Message-Id: <B27397-0100000@cac.washington.edu>MIME-Version: 1.0Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
サ:
S: )
S: a004 OK FETCHが完了しました
C a005 ストア 12 +フラグ \deleted
S: * 12 FETCH (フラグ (\Seen \Deleted))
S: a005 OK +FLAGSが完了しました
C: a006 ログアウト
S: * BYE IMAP4rev1 サーバーが接続を終了しています
S: a006 OK ログアウトが完了しました

• メールサーバーソフトウェアの一覧
• メールクライアントの比較
• メールサーバーの比較
• IMAP アイドル
• JSON メタアプリケーションプロトコル (JMAP)
• ポストオフィスプロトコル(POP)
• プッシュIMAP
• シンプルメールアクセスプロトコル
• 簡易メール転送プロトコル
• ウェブメール

• クリスピン、マーク(1988–2016)。「IMAP クライアントの作成方法に関する 10 の戒律」。ワシントン大学。2016 年 8 月 29 日のオリジナルからアーカイブ。2018年 11 月 2 日に取得。
• Heinlein, P ; Hartleben, P (2008)。『IMAP の書: Courier と Cyrus によるメール サーバーの構築』No Starch Press。ISBN 978-1-59327-177-0。
• ヒューズ、L (1998)。インターネット電子メールプロトコル、標準、実装。Artech House Publishers。ISBN 0-89006-939-5。
• ジョンソン、K (2000)。インターネット電子メールプロトコル: 開発者ガイド。Addison -Wesley Professional。ISBN 0-201-43288-9。
• Loshin, P (1999)。「必須の電子メール標準: 実用的な RFC とプロトコル」。プログラミングインターネット メール。O'Reilly。ISBN 1-56592-479-7。

無料辞書の Wiktionary でIMAP を調べてください。

• 「IMAP プロトコル メーリング リスト」。^{[永久リンク切れ]}
• RFC  9051 — IMAP バージョン 4、リビジョン 2 の仕様
• RFC  2683 — IMAP 実装の提案 RFC
• RFC  2177 — IMAP4 IDLE コマンド