要約

  • RFC2061の互換対応は義務ではない。CAPABILITY の返答は旧方式へ進む手掛かりであって、後続操作の同等性まで保証しない。RFC2061
  • 本文取得後にフラグを戻す処理は、最初から変えない処理とは異なる。COPY の属性保持には不確実性が残り、UID と CLOSE には機能的な代替がない。RFC2061

本文を下見するだけでも、互換処理ではサーバー上の \Seen を一度立て、必要に応じて消すことがある。欲しいバイト列は届く。それでも、状態を変えずに取得できたとは限らない。1996年12月、University of WashingtonのMark Crispinが記したRFC2061には、そんな置換手順が載っている。これは標準を定める文書ではなく、情報提供用のメモだった。旧ソフトウェアとの通信を試みるか、失敗を受け入れるかは、実装者自身に委ねられている。

当時のIMAP2bisはPineとともに広く配布されていた一方、確定した記述文書を欠いていた。メモも知識の不完全さと伝承的な情報の存在を認め、遭遇しやすい旧変種に対象を絞る。広く使われていたという記述は、市場占有率の測定でも現在の配備状況の説明でもない。RFC2061

年代の区別も欠かせない。RFC1176は1990年8月のIMAP2の基礎資料で、IMAP2bisの確定仕様ではない。RFC1730は1994年12月のIMAP4、RFC2060は1996年12月のIMAP4rev1を記す。RFC2061は両版に対応する実装者に両方の参照を求める。1994年12月のRFC1732はIMAP2やIMAP2bis、よりまれな変種も扱う先行資料であり、対象を絞った1996年のメモと同一視できない。RFC2061

判定が決めるのは、引き受ける互換経路

CAPABILITY への OK 応答では、対応するIMAP4の変種が示される。既知の変種を一つも認識できなければ、クライアントは相手をIMAP2bisとして扱う。BAD はIMAP2bisまたはそれ以前を示す、というのがメモの判定手順である。これは互換経路を選ぶための手掛かりで、未知のサーバーの正体を確定する検査ではない。タイムアウトや認証・暗号化の失敗一般を BAD と読み替える根拠も、後続命令の動作保証も与えない。RFC2061

置換の性質は一様ではない。以下の三分類は、RFC2061の対応関係を読むための本稿の整理であり、同メモの正式な分類ではない。

本稿の分類 具体的な対応 残る境界
目的に近い操作でつなぐ LIST は FIND ALL.MAILBOXES に、シーケンス中の * は自発的な EXISTS 応答で得たメッセージ数に置き換える。 構文・応答の参照元である旧 FIND MAILBOXES 自体からは有用な情報を得にくい。得た件数も、メールボックスの状態を固定しない。
意味を縮める、または別操作で補償する SEARCH はRFC1176の構文で組み直し、必要なら複数回検索する。BODYSTRUCTURE は非拡張型の BODY に置き換える。 同じ文字集合・検索条件への対応は保証されない。本文の HEADER、TEXT、MIME、HEADER.FIELDS、HEADER.FIELDS.NOT も節番号だけに縮める。綴りの変更で豊かな構造や部分指定の意味を再現できるわけではない。
機能的な代替がない UID の取得項目と命令、CLOSE には機能的な代替がない。LSUB、SUBSCRIBE、UNSUBSCRIBE にも直接の機能的な代替はない。 旧来の bboards は別の概念であり、メモは旧クライアントを支えるサーバーを含め、新しいソフトウェアに旧掲示板命令を実装しないよう勧める。すべてを模倣する方針ではない。

「あとで戻す」は「変えない」ではない

BODY.PEEK[section] の代替は、BODY[section] で取得し、必要に応じてクライアント側で \Seen を解除する手順である。RFC2061のこの助言は、RFC2060の本文取得規定と対照すると意味が明確になる。通常の BODY[section] は暗黙に \Seen を立て、BODY.PEEK[section] は立てない。

取得前から立っていた \Seen を、一律に消してよいわけではない。さらにRFC2060は外部の処理によるフラグ変更を認め、変更の自動通知を推奨する。ここからの本稿の推論は、可変のフラグを共有する環境では、取得と補償は別々の書き込みであり、途中の状態を他のクライアントが観測したり、その間に更新したりする余地を排除できない、ということだ。元の値を知るだけでは、その後の他者の更新まで消してよいことにはならない。RFC2061は原子的な復元を定めておらず、これは同メモに記録された事故や、全サーバーで必ず生じる競合を述べたものではない。RFC2060・RFC2061

FLAGS.SILENT、+FLAGS.SILENT、-FLAGS.SILENT も、それぞれ非 SILENT の STORE 項目で代用し、その操作に返るタグなし FETCH 応答を無視する。クライアント側で無視することは、返信を発生させないことではない。サーバー上の変更や、外部から観測される効果まで消えるわけでもない。RFC2061

成功応答にも埋められない空白

RFC2061によれば、IMAP2bisでは COPY によるフラグと内部日時の保持が曖昧で、この互換性の記述からサーバーの挙動を知ることはできない。一方、RFC2060には保持を推奨する SHOULD がある。後者を旧方式に遡及させることはできない。コピーの成功応答は、属性まで保持した証拠にはならない。個別サーバーでの比較試験は、試した条件での観測を増やせても、欠けている普遍的な仕様上の約束を作り出せない。RFC2061・RFC2060

失敗時の助言も読み分ける必要がある。IMAP2bisの TRYCREATE は、NO の内部ではなく、別の自発的な OK 応答に現れる。この応答形式を解析するときも、元の命令が失敗した文脈を保たなければならない。作成を試すための別のヒントが届いても、失敗した COPY が成功に変わるわけではない。RFC2061

互換の向きと、安全性の時代を分ける

逆方向、すなわちIMAP2bisクライアントとIMAP4サーバーの組み合わせについて、メモが挙げる問題は、適切に実装されたクライアントという条件の下で、引用符付き文字列のバックスラッシュ処理だけである。\ または " が含まれる場合はリテラルを使う。この限定された知見を、あらゆる旧ソフトウェアの動作保証にはできない。RFC2061

また、利用できない AUTHENTICATE を LOGIN で代用する助言は、当時の互換処理であり、メモは安全性を論じないと明記している。IETFの2018年1月のRFC8314は、メール送信・アクセスにTLSを用いる後年の安全上の境界を示す。1996年の助言を現在の平文認証や保護水準の引き下げの推奨に転用してはならず、2018年の文書を1996年のTLS導入実績の証拠にすることもできない。RFC2061

後年の視点から、約束の範囲を読む

Lu Hengは2026年の任意採用を論じた文章で「Non-adoption is not a violation.」と述べる。本稿では、この見方をクライアントが参加する互換関係を選ぶ自由に限って重ねる。2025年の象徴的な主張と実効を分ける文章の「Most conflicts persist because participants mix these layers.」も、宣言された機能と実際の動作を分ける補助線になる。ただし、いずれも技術的な協調をめぐる後年の見解であり、IMAPの歴史資料でも、1996年のMark Crispinの意図を証明するものでもない。この視点を適用するのは本稿の解釈である。互換性を評価する単位は、単なる接続成功ではなく、命令ごとに何を約束し、どの制約を受け入れたかである。

出典と根拠の範囲

資料 本稿での位置づけ
RFC2061 1996年12月。任意の互換対応、命令の置換、把握できない挙動を記す中心的な一次資料。
RFC2060 1996年12月のIMAP4rev1仕様。本文取得、フラグ通知、コピー時の属性保持を照合する基準。
RFC1176 1990年8月のIMAP2資料。旧来の検索・メールボックス探索の構文を参照するために用い、IMAP2bisの確定仕様とは扱わない。
RFC1730 1994年12月のIMAP4仕様。1996年の改訂版と区別する。
RFC1732 1994年12月の先行互換メモ。IMAP2・IMAP2bisやまれな変種を含む、より広い対象を扱う。
RFC8314 2018年1月のTLS文書。歴史的な認証の助言を現在の安全性の推奨に転用しないためだけに参照する。
Lu Hengによる任意採用の論考 2026年。互換関係への参加を選ぶという後年の視点であり、当時のIMAP実装の証拠ではない。
Lu Hengによる象徴と実効の論考 2025年。能力の表示と実際の効果を区別するための解釈上の参照であり、歴史的事実の根拠ではない。