Loading article…
コンピューティングにおいて、インターネットメッセージアクセスプロトコル（IMAP）は、電子メールクライアントがTCP/IP接続を介してメールサーバーから電子メールメッセージを取得するために使用するインターネット標準プロトコルです。[ 1 ] IMAPはRFC 9051で定義されています。
IMAP は、複数のメール クライアントによるメールボックスの完全な管理を可能にすることを目的として設計されました。そのため、クライアントは通常、ユーザーが明示的に削除するまでメッセージをサーバー上に残します。IMAP サーバーは通常、ポート番号143 で待機します。SSL /TLS上の IMAP ( IMAPS ) にはポート番号 993 が割り当てられます。[ 2 ] [ 3 ]
現代の電子メールクライアントとサーバーはほぼすべてIMAPをサポートしており、これは以前のPOP3 （Post Office Protocol）とともに、電子メールの受信に最も普及している2つの標準プロトコルです。[ 4 ] GmailやOutlook.comなどの多くのウェブメールサービスプロバイダーもIMAPとPOP3の両方をサポートしています。
インターネットメッセージアクセスプロトコルは、電子メールクライアントがリモートメールサーバー上の電子メールにアクセスできるようにするアプリケーション層のインターネットプロトコルです。現在のバージョンはRFC 9051で定義されています。IMAPサーバーは通常、よく知られているポート143でリッスンしますが、SSL/TLS上のIMAP（IMAPS）は993を使用します。[ 2 ] [ 3 ]
受信した電子メールメッセージは、受信者のメールボックスにメッセージを保存する電子メールサーバーに送信されます。ユーザーは、複数の電子メール取得プロトコルのいずれかを使用する電子メールクライアントを使用してメッセージを取得します。一部のクライアントとサーバーはベンダー固有の独自のプロトコルを優先的に使用しますが、[ 5 ]ほぼすべてが電子メールの取得にPOPとIMAPをサポートしており、 Pegasus MailやMozilla Thunderbirdなどの多くの電子メールクライアントから自由に選択してこれらのサーバーにアクセスでき、クライアントを他のサーバーで使用できるようになります。
IMAP を使用する電子メール クライアントは、通常、ユーザーが明示的に削除するまでメッセージをサーバー上に残します。このことや IMAP の動作の他の特性により、複数のクライアントが同じメールボックスを管理できます。ほとんどの電子メール クライアントは、メッセージの取得にPost Office Protocol (POP)に加えて IMAP をサポートしています。[ 6 ] IMAP はメール ストレージへのアクセスを提供します。クライアントはメッセージのローカル コピーを保存できますが、これらは一時的なキャッシュとみなされます。
IMAPは、1986年にマーク・クリスピンによって、リモートアクセス用のメールボックスプロトコルとして設計された。これは、メールボックスの内容を取得するだけのプロトコルである、広く使われているPOPとは対照的である。
現在のバージョン4rev2（IMAP4）に至るまでには、以下に詳述するように、いくつかの改良が加えられてきました。
オリジナルの暫定メールアクセスプロトコルは、ゼロックスLispマシンのクライアントとTOPS-20サーバーとして実装された。
オリジナルの暫定プロトコル仕様書やそのソフトウェアのコピーは存在しない。[ 7 ] [ 8 ]一部のコマンドと応答はIMAP2に似ていたものの、暫定プロトコルにはコマンド/応答のタグ付けが欠けていたため、その構文は他のすべてのバージョンのIMAPと互換性がなかった。
暫定プロトコルはすぐに、 RFC 1064（1988年）で定義され、後にRFC 1176 （1990年）で更新されたインタラクティブメールアクセスプロトコル（IMAP2）に置き換えられました。IMAP2はコマンド/レスポンスのタグ付けを導入し、最初に一般に配布されたバージョンでした。
IMAP3 は、IMAP の非常にまれなバリアントです。[ 9 ] 1991 年にRFC 1203として公開されました。これは、IMAP2 の変更を提案したRFC 1176に対する対抗提案として具体的に作成されました。 [ 10 ] IMAP3 は市場で受け入れられることはありませんでした。[ 11 ] [ 12 ] IESGは1993 年に RFC1203「Interactive Mail Access Protocol – Version 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ワーキンググループは、混乱を避けるため、IMAP2bisをIMAP4に改名することを決定した。
POPを使用する場合、クライアントは通常、新しいメッセージをダウンロードするのに必要な時間だけ、短時間だけメールサーバーに接続します。一方、IMAP4を使用する場合、クライアントはユーザーインターフェースがアクティブな間は接続を維持し、必要に応じてメッセージコンテンツをダウンロードします。メッセージ数が多い、またはメッセージサイズが大きいユーザーにとって、このIMAP4の使用パターンは応答時間の短縮につながる可能性があります。
認証が成功すると、POPプロトコルはメールボックスの現在の状態を完全に静的なビューで表示し、セッション中に外部からの状態変化を表示するメカニズムを提供しません（POPクライアントは、更新されたビューを取得するために再接続して再認証する必要があります）。これに対し、IMAPプロトコルは動的なビューを提供し、RFC 2177で説明されているように、新しく到着したメッセージや、同時に接続されている他のクライアントによってメールボックスに加えられた変更など、外部からの状態変化を検出し、コマンド間およびIDLEコマンド実行中に適切な応答を送信する必要があります。RFC 3501のセクション5.2も参照してください。このセクションでは、「複数のエージェントによる同一メールボックスへの同時アクセス」について具体的に言及しています。
通常、インターネットメールはすべてMIME形式で送信されます。MIME形式では、メッセージはツリー構造を持ち、リーフノードは様々な単一パートコンテンツタイプのいずれか、非リーフノードは様々なマルチパートタイプのいずれかになります。IMAP4プロトコルを使用すると、クライアントは個々のMIMEパートを個別に取得したり、個々のパートの一部またはメッセージ全体を取得したりできます。これらのメカニズムにより、クライアントは添付ファイルを取得せずにメッセージのテキスト部分を取得したり、取得中のコンテンツをストリーミングしたりできます。
IMAP4プロトコルで定義されたフラグを使用することで、クライアントはメッセージの状態（例えば、メッセージが既読か、返信されたか、削除されたかなど）を追跡できます。これらのフラグはサーバーに保存されるため、異なる時間に同じメールボックスにアクセスする複数のクライアントが、他のクライアントによって行われた状態変更を検出できます。POPには、クライアントがサーバーにこのような状態情報を保存するメカニズムがないため、1人のユーザーが2つの異なるPOPクライアント（異なる時間に）でメールボックスにアクセスすると、メッセージがアクセスされたかどうかなどの状態情報をクライアント間で同期することはできません。IMAP4プロトコルは、事前定義されたシステムフラグとクライアント定義のキーワードの両方をサポートしています。システムフラグは、メッセージが既読かどうかなどの状態情報を示します。すべてのIMAPサーバーでサポートされているわけではないキーワードを使用すると、メッセージに1つ以上のタグを付けることができ、その意味はクライアントによって異なります。IMAPキーワードは、対応する独自のサーバーによってIMAPフォルダーに変換されることがあるWebベースの電子メールサービスの独自のラベルと混同しないでください。
IMAP4クライアントは、サーバー上でメールボックス（通常はフォルダとしてユーザーに表示される）を作成、名前変更、削除したり、メールボックス間でメッセージをコピーしたりできます。また、複数のメールボックスをサポートすることで、サーバーは共有フォルダやパブリックフォルダへのアクセスを提供できます。アクセス権限の制御には、 IMAP4アクセス制御リスト（ACL）拡張機能（RFC 4314）を使用できます。
IMAP4は、クライアントがサーバーに対し、様々な条件を満たすメッセージを検索するよう要求できる仕組みを提供します。この仕組みにより、クライアントは検索を実行するためにメールボックス内のすべてのメッセージをダウンロードする必要がなくなります。
以前のインターネットプロトコルの経験を反映して、IMAP4は拡張可能な明確なメカニズムを定義しています。基本プロトコルに対する多くのIMAP4拡張機能が提案され、広く使用されています。IMAP2bisには拡張メカニズムがありませんでしたが、POPにはRFC 2449で定義された拡張メカニズムがあります。
IMAP IDLEは、メールサーバーが接続されているクライアントに対し、例えば新しいメールが届いた場合など、メールボックスに変更があったことを通知する手段を提供する。POPにはこれに相当する機能はなく、メールクライアントは定期的にPOPサーバーに接続して新しいメールを確認する必要がある。
IMAPはPOPの多くの欠点を解消するものの、必然的に複雑さが増すという欠点がある。こうした複雑さの多く（例えば、複数のクライアントが同時に同じメールボックスにアクセスする場合など）は、Maildirやデータベースバックエンドといったサーバー側の回避策によって補われている。
IMAP仕様は、厳格さに欠け、その有用性を事実上無効にするような動作を許容しているとして批判されてきた。例えば、仕様では、サーバーに保存される各メッセージには、クライアントがセッション間で既に見たメッセージを識別できるようにするための「一意のID」があると規定されている。しかし、仕様ではこれらのUIDをほとんど制限なく無効化することも許可しており、事実上その目的を損なっている。[ 17 ]
IMAP はメール サーバー上でメールボックス構造 (コンテンツ、フォルダ構造、個々のメッセージの状態など) を維持するのに対し、POP はユーザーのローカル デバイス上で維持します。そのため、IMAP はサーバー側のリソースをはるかに多く必要とし、メールボックスあたりのコストが大幅に高くなります。[ 18 ]サーバーのストレージ、インデックス作成、検索アルゴリズムが適切に実装されていない場合、クライアントは大量のサーバー リソースを消費する可能性があります。
IMAP4 クライアントは、新しいメールの到着を通知されるために、IMAP サーバーとの TCP/IP 接続を維持する必要があります。メールの到着通知はインバンド シグナリングによって行われるため、クライアント側の IMAP プロトコル処理がやや複雑になります。[ 19 ]プライベート提案のpush IMAPは、通知だけでなくメッセージ全体を送信することでプッシュ電子メールを実装するように IMAP を拡張します。しかし、push IMAP は一般には受け入れられておらず、現在の IETF の作業では別の方法でこの問題に対処しています (詳細については、 Lemonade プロファイルを参照してください)。
送信と取得操作を統合する一部の独自プロトコルとは異なり、ベースレベルの IMAP クライアントでメッセージを送信してサーバー側のフォルダにコピーを保存するには、メッセージの内容を 2 回送信する必要があります。1 回は配信のために SMTP に、2 回は送信済みメールフォルダに保存するために IMAP に送信します。これは、IETF Lemonade プロファイルで定義されているモバイル デバイス向けの拡張機能セットによって対処されます。IMAP では URLAUTH ( RFC 4467 ) と CATENATE ( RFC 4469 )、SMTP-SUBMISSION では BURL ( RFC 4468 ) です。これに加えて、Courier Mail Server は、送信メッセージを専用の送信ボックスフォルダにコピーすることで、IMAP を使用して送信する非標準の方法を提供します。[ 20 ]
クライアントとサーバー間の IMAP 接続を暗号化して保護するには、SSL/TLS を利用する TCP ポート 993 の IMAPS を使用できます。[ 2 ] [ 3 ] 2018 年 1 月現在、TLS が推奨されるメカニズムです。[ 21 ]
あるいは、STARTTLS を使用すると、最初に平文で通信した後、ポート 143 に接続する際に接続を暗号化できます。
これは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 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" 「IMAP4rev1 ワーキンググループ会議の概要と議事録」 (("テリー・グレイ" 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 body[header] 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:TerryGray<gray@cac.washington.edu>Subject:IMAP4rev1WGmtgsummaryandminutesTo:imap@cac.washington.eduCc:minutes@CNRI.Reston.VA.US,JohnKlensin<KLENSIN@MIT.EDU>Message-Id:<B27397-0100000@cac.washington.edu>MIME-Version:1.0Content-Type:TEXT/PLAIN;CHARSET=US-ASCII S: S: ) S: a004 OK FETCH 完了 C: a005 ストア 12 +フラグ \削除済み S: * 12 FETCH (FLAGS (\Seen \Deleted)) S: a005 OK +FLAGS 完了 C: a006 ログアウト S: * BYE IMAP4rev1サーバーが接続を終了します S: a006 OK ログアウト完了オリジナルの IMAP (IMAP2 以前) に関する知識は、オリジナルの IMAP 仕様と実装がすべて IMAP2 に置き換えられたため、主に私の頭の中に存在します。