要約

  • RFC 3516 の FETCH BINARY は、サーバーが MIME Content-Transfer-Encoding を外して本文 section を返す仕組みである。NUL を含む結果は literal8 で運べるが、それは復号ビューであり、mailbox に入った直列化 message そのものではない。
  • BINARY.SIZE と partial offset は復号後の座標である。保存形式、FETCH BODY、CRLF、RFC 2047 header、暗号処理の対象 bytes はそれぞれ別に記録しなければならない。

base64 は、任意の octet を扱えない古い mail transport のために binary content を安全な文字列へ変えた。しかし IMAP client が読む段階では、膨らんだ表現を download してすぐ元へ戻すことになる。RFC 3516 は、低速 radio link や streaming multimedia では、この往復が無視できないと考えた。

2003 年4月に公開された IMAP4 Binary Content Extension は、復号作業を server へ移した。CAPABILITY に BINARY を掲げる server に FETCH BINARY を送ると、指定した MIME body section の転送符号化を外した結果が返る。帯域と client 処理を節約しても、その bytes が元の message 列になるわけではない。

IMAP body section には必ず CTE がある。header に明記されなければ 7bit と見なされる。MIME における CTE は、逆変換 algorithm と、変換後 data の domain の両方を規定する。base64 や quoted-printable は表現を変える。identity transformation であっても、NUL のように base IMAP literal で表せない domain を持つことがある。

そこで RFC は処理を二段階に分けた。まず CTE に対応する decoding を行い、その後に decoded data の domain を判断する。octet sequence を得ただけでは、それを載せる protocol element は決まらない。

広い domain のために導入された literal8 は、tilde と長さの後に任意の octet を置ける。NUL も許される。結果が8bit domain に収まり NUL を含まない場合、server は通常の string を使うべきだとされた。client は stream 全体を検索せずに、外側の形式から domain を区別できる。

count はその response に関して正確だが、storage provenance までは語らない。server が最初から decoded payload を保存していたのか、base64 から今作ったのか、別の内部形式を使っているのかは分からない。literal8 は返された octet の容器であって disk image ではない。

BINARY.PEEK は mailbox state を分ける。BODY.PEEK と同様、読み出しによって暗黙に \\Seen を付けない。未読のままであることは有用な保証だが、返された bytes の由来とは別である。正しい PEEK response も server が作った decoded view である。

BINARY.SIZE は CTE を外した section の大きさ、すなわち対応する BINARY response の予定 octet 数を示す。encoded body、物理 storage、message 全体、表示後 file の大きさではない。server が実際に decoding しなければ数えられない実装では高コストになり得るため、無意味な照会を避けるよう RFC は警告した。

partial fetch では座標系の違いが事故になる。FETCH BINARY の offset と length は decoded section を基準にする。base64 text や FETCH BODY の位置をそのまま使うことはできない。別表現の resume counter を流用すると、protocol 上は正常な fragment が、意図した場所と違う位置から届く。

server が CTE を知らない場合、推測は禁止された。BINARY と BINARY.SIZE は NO [UNKNOWN-CTE] で失敗しなければならない。この receipt が証明するのは変換能力の欠如であり、message corruption ではない。

RFC 4466 は後に IMAP response code の枠組みを更新し、RFC 9051 は binary mechanism を IMAP4rev2 へ取り込んだ。現在の trace にはこれらの版を反映すべきだが、encoded section、decoded section、stored representation の区別は消えていない。

header encoding は別の layer である。RFC 2047 encoded-word は特定の message header に non-ASCII text を置く仕組みで、MIME body の CTE ではない。RFC 3516 は、BINARY FETCH や APPEND の際に encoded header text を変換してはならないとした。body decoding の要求は、message 全体を復号し直す権限ではない。

line-oriented text section にはもう一つ規則がある。server 内部の保存方法にかかわらず、IMAP CRLF line termination で送信しなければならない。interoperability には必要だが、response の newline bytes が storage の forensic copy だとは主張できなくなる。

storage と interface の分離も明記された。server は binary content を非符号化状態で保存してよい。それでも BODYSTRUCTURE は base IMAP が受け入れられる CTE を使った message として記述し、FETCH BODY はその説明に合う形を返す。公開 interface は互換契約であり、内部 bytes の露出ではない。

APPEND は逆方向の変換を扱う。client は NUL を含む data を literal8 で追加できる。destination mailbox が binary storage を扱えなければ UNKNOWN-CTE で拒否する。扱える server は CTE を変更できるが、その変換で payload data を失ってはならない。

payload を失わないことと、message serialization が同じであることは違う。base64、quoted-printable、identity form は同じ content を異なる octet で表せる。CTE field、header folding、line ending も直列化の一部である。content-preserving change でも、その bytes を対象にした digest や signature は壊れ得る。

RFC 3516 自身が、不要な encoding change は message に施された多くの cryptographic operation を無用にすると警告した。矛盾ではない。一方は payload recovery を保証し、他方は exact bytes と対象 header に依存する。「lossless」と記録しただけでは verifier input は残らない。

この拡張は client の MIME decoder も不要にはしなかった。特定状況の optimization であり、新しい universal storage format ではない。対応 client は、自身でも基本 CTE decoding を実行できるべきだとされた。capability は fast path であって、通常 path を捨てる理由ではない。

Heng Lu の symbolic reality と operational reality の区別を使うと、receipt を整理できる。CAPABILITY の BINARY は能力宣言で、BINARY.SIZE は一つの decoded response に関する約束である。counted literal は connection 上の観測である。stored bytes、RFC 5322 message、MIME payload、rendering、signature input は、関連していても交換できない層にある。

有効な evidence chain は message identifier と retrieval context を固定し、BODYSTRUCTURE、section、CTE、command、\\Seen、response code、domain、length、partial offset、返却 bytes と hash を保存する。original identity が必要なら raw message retrieval と hash を別に残す。signature を扱うなら canonicalization と verifier が読んだ exact sequence を記録する。

そうすれば二つの正しい観測は衝突しない。server は decoded body を正しく返した。一方、downloaded file の hash は stored message と一致しない。RFC 3516 はどちらかを誤りにしたのではなく、その間の transformation を定義した。

歴史的成果は実用的だった。binary content は、別の transport のための encoding overhead を IMAP retrieval のたびに払わずに済む。残る教訓は receipt の節度である。server は本文を復号し、client は有用な octet を得た。元の message には別の retrieval、hash、proof が必要だった。

出典