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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コンピューティングでは、インターネットメッセージアクセスプロトコルIMAP)は、 TCP / IP接続を介してメールサーバーから電子メールメッセージを取得するために電子メールクライアントによって使用されるインターネット標準 プロトコルです。[2] IMAPはRFC9051で定義されています 

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

事実上すべての最新の電子メールクライアントとサーバーはIMAPをサポートしています。これは、以前のPOP3(Post Office Protocol)とともに、電子メール検索で最も普及している2つの標準プロトコルです。[5] GmailOutlook.comなどの多くのWebメールサービスプロバイダーも、IMAPとPOP3の両方をサポートしています。

メールプロトコル

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

受信メールメッセージは、受信者のメールボックスにメッセージを保存するメールサーバーに送信されます。ユーザーは、多数の電子メール取得プロトコルの1つを使用する電子メールクライアントを使用してメッセージを取得します。一部のクライアントとサーバーはベンダー固有の独自のプロトコルを優先的に使用しますが[6] 、ほとんどすべてがPOPとIMAPをサポートして電子メールを取得します。これにより、 PegasusMailMozillaThunderbirdなどの多くの電子メールクライアント間で多くの自由な選択が可能になり、これらのサーバーにアクセスできます。クライアントを他のサーバーで使用できるようにします

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

歴史

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

以下に詳述するように、現在のVERSION 4rev1(IMAP4)の前に何度も繰り返されました。

オリジナルのIMAP

オリジナルの暫定メールアクセスプロトコルは、 XeroxLisp マシンクライアントおよびTOPS-20サーバー として実装されました。

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

IMAP2

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

IMAP3

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

IMAP2bis

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

IMAP4

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

POPに対する利点

接続モードと切断モード

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

複数の同時クライアント

POPプロトコルでは、現在接続されているクライアントがメールボックスに接続されている唯一のクライアントである必要があります。対照的に、IMAPプロトコルは、特に複数のクライアントによる同時アクセスを許可し、同時に接続されている他のクライアントによってメールボックスに加えられた変更をクライアントが検出するためのメカニズムを提供します。たとえば、例として「複数のエージェントによる同じメールボックスへの同時アクセス」を具体的に引用しているRFC3501セクション5.2を 参照してください。 

MIMEメッセージ部分へのアクセスと部分フェッチ

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

メッセージ状態情報

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

サーバー上の複数のメールボックス

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

サーバー側の検索

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

組み込みの拡張メカニズム

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

短所

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

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

サーバー上のメールストレージと検索アルゴリズムが注意深く実装されていない限り、クライアントは大量のメールボックスを検索するときに大量のサーバーリソースを消費する可能性があります。

IMAP4クライアントは、新着メールの到着を通知するために、IMAPサーバーへのTCP / IP接続を維持する必要があります。メール到着の通知は帯域内信号方式で行われるため、クライアント側のIMAPプロトコル処理が多少複雑になります。[19]プライベートプロポーザルであるプッシュIMAPは、通知だけでなくメッセージ全体を送信することにより、プッシュ電子メールを実装するようにIMAPを拡張します。ただし、プッシュIMAPは一般的に受け入れられておらず、現在のIETFの作業では、他の方法で問題に対処しています(詳細については、レモネードプロファイルを参照してください)。

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

セキュリティ

IMAP接続を暗号で保護するために、SSL / TLSを利用するTCPポート993のIMAPSを使用できます。[3] [4] 2018年1月の時点で、TLSが推奨されるメカニズムです。[21]

または、STARTTLSを使用して、 SMTPプロトコルを実装するMSAまたはMTAと通信するMUA間の安全な通信を提供できます

ダイアログの例

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

C:<接続を開く>
S:* OKIMAP4rev1サービス対応
C:a001ログインmrcシークレット
S:a001 OKLOGINが完了しました
C:a002受信トレイを選択
S:* 18が存在します
S:*フラグ(\ Answered \ Flagged \ Deleted \ Seen \ Draft)
S:* 2最近
S:* OK [UNSEEN17]メッセージ17は最初の見えないメッセージです
S:* OK [UIDVALIDITY 3857529045] UIDは有効です
S:a002 OK [READ-WRITE] SELECTが完了しました
C:a003フェッチ12フル
S:* 12 FETCH(FLAGS(\ Seen)INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 ENVELOPE( "1996年7月17日水曜日02:23:25 -0700(PDT)"
      「IMAP4rev1WGmtgの概要と議事録」
      (( "テリーグレイ" NIL "グレー" "cac.washington.edu"))
      (( "テリーグレイ" NIL "グレー" "cac.washington.edu"))
      (( "テリーグレイ" NIL "グレー" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ( "ジョンクレンシン" NIL "KLENSIN" "MIT.EDU"))NIL NIL
      "<[email protected]>")
      BODY( "TEXT" "PLAIN"( "CHARSET" "US-ASCII")NIL NIL "7BIT" 3028
      92))
S:a003 OKFETCH完了
C:a004フェッチ12本体[ヘッダー]
S:* 12 FETCH(BODY [HEADER] {342}
S:日付:1996年7月17日水曜日02:23:25 -0700(PDT)
S:差出人:テリーグレイ<[email protected]>
S:件名:IMAP4rev1 WGmtgの概要と議事録
S:宛先:[email protected]
S:cc:minutes @ CNRI.Reston.VA.US、ジョン・クレンシン<[email protected]>
S:メッセージID:<[email protected]>
S:MIME-バージョン:1.0
S:コンテンツタイプ:TEXT / PLAIN; CHARSET = US-ASCII
S:
S :)
S:a004 OKFETCH完了
Ca005ストア12+フラグ\ deleted
S:* 12 FETCH(FLAGS(\ Seen \ Deleted))
S:a005 OK + FLAGSが完了しました
C:a006ログアウト
S:* BYEIMAP4rev1サーバーが接続を終了しています
S:a006OKログアウトが完了しました

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ ディーン、タマラ(2010)。Network +ネットワークガイドデルマー。p。519. ISBN 978-1-42390245-4
  3. ^ a b c ブルム、リチャード(2002年12月15日)。オープンソースの電子メールセキュリティサムズパブリッシング。ISBN 9780672322372 –Googleブックス経由。
  4. ^ a b c ガーフィンケル、シムソン; スパフォード、ジーン; シュワルツ、アラン(2003年12月15日)。実用的なUNIXとインターネットセキュリティ「O'ReillyMedia、Inc。」。ISBN 9780596003234 –Googleブックス経由。
  5. ^ Komarinski、Mark(2000)。Red HatLinuxシステム管理ハンドブックプレンティスホール。p。179。
  6. ^ たとえば、 MicrosoftOutlookクライアントは Microsoft独自のプロトコルであるMAPIを使用して、 Microsoft ExchangeServerと通信しますIBMNotesクライアントは、 Dominoサーバーと通信するときに同様に機能し
  7. ^ マレット、ダイアナ(2000)。IMAPの管理オライリーp。25. ISBN 0-596-00012-X
  8. ^ クリスピン、マーク(2012年2月13日)。「Re:[imap5] IMAPの新しい置換プロトコルの設計」imap5(メーリングリスト)。[email protected] 2014年11月26日取得元のIMAPの仕様と実装はすべてIMAP2に置き換えられたため、元のIMAP(IMAP2より前)の知識は主に私の頭の中にあります。
  9. ^ サービス名とトランスポートプロトコルのポート番号レジストリIana.org(2013-07-12)。2013年7月17日に取得。
  10. ^ a b "RFC 2061-IMAP2BISとのIMAP4互換性"IETF。1996 2010年8月21日取得
  11. ^ 「インタラクティブメールアクセスプロトコル-バージョン3」IETF。1991 2010年8月21日取得
  12. ^ 「IMAP2、IMAP2bis、IMAP3、IMAP4、IMAP4rev1(LANメールプロトコル)」2010年8月21日取得
  13. ^ 「IMAPの概要、歴史、バージョンおよび標準」2010年8月21日取得
  14. ^ 「プロトコルアクション:インタラクティブメールアクセスプロトコル—バージョン3からヒストリック(IETFメールアーカイブ)」1993 2010年8月21日取得
  15. ^ 「InnosoftおよびPOP / IMAPプロトコル?(メールアーカイブ)」1993 2010年8月21日取得
  16. ^ 「インタラクティブなメールアクセスプロトコル-バージョン2bis(インターネットドラフト)」IETF。1993 2010年8月21日取得
  17. ^ 「IMAP2BIS-IMAP2プロトコル(ドラフト)の拡張」1992年。 2011年7月18日のオリジナルからアーカイブ2010年8月21日取得
  18. ^ 「SupでのIMAP実装、Rubyで書かれた電子メールクライアント」rubyforge.com。2007年12月12日にオリジナルからアーカイブされました2011年2月22日取得
  19. ^ 「IMAPIDLE:「プッシュ」電子メールの最良のアプローチ」Isode.com 2009年7月30日取得
  20. ^ 「Courier-IMAP:IMAP接続を介してメールを送信する」Double Precision、Inc 2013年9月24日取得
  21. ^ RFC8314土井10.17487 / RFC8314

さらに読む

外部リンク