要約

  • クライアントがBODY=8BITMIMEを宣言して上位ビットを持つオクテットを送れるのは、そのセッションのEHLO応答で相手が8BITMIMEを広告した後だけだった。
  • 受け入れたサーバーは全ビットを保存する責任を負い、次の中継が非対応なら、情報を失わない正当な7ビットMIMEへ変換するか、恒久的失敗にしなければならなかった。

内容の記述と輸送路の能力は別だった

MIMEは、メディア型、文字集合、転送符号化をメール自身が語る仕組みを与えた。しかし説明が正しくなってもSMTPの道路が自動的に広がるわけではない。RFC 2045は7bit、8bit、binaryという輸送領域を区別する。意味の通るMIME本文でも、次の中継が保持を約束していない高位ビットを含み得た。

したがって8BITMIMEの核心は国際文字そのものではない。どの稼働中サーバーが、どの接続で、その表現を預かったのかを特定することにあった。

小さな契約は三つのRFCを経た

RFC 1426は1993年2月に最初の拡張を公開した。RFC 1652が1994年7月に置き換え、さらにRFC 6152が2011年3月にRFC 1652を置き換えた。この系譜は仕様の履歴であり、現在の普及率ではない。

サーバーは成功したEHLO応答に8BITMIMEを並べる。IANAのSMTPサービス拡張登録簿は、このキーワードをEHLOパラメーターなしで記録し、RFC 6152を参照する。新しいSMTP動詞はない。

クライアントはMAIL FROMにBODY=7BITまたはBODY=8BITMIMEを付けられる。BODYが示すのは後続するDATA本文のオクテット領域であり、言語、文字集合、メディア型ではない。輸送上の幅と内容の意味は別の証拠である。

許可は今の接続にしか効かなかった

8ビット本文を送る前に、クライアントはEHLOを発行し、250応答の中に能力表示を見なければならない。EHLOが成功しない、またはキーワードがなければ、US-ASCII域外のオクテットを送ってはならない。TCPが任意のバイトを運べることも、前回の接続で同じ製品が受け入れたことも、現在の広告の代わりにはならない。

約束は一ホップだけを拘束する。受信中継が本文を受け入れても、その次のサーバーは8BITMIMEを出さないかもしれない。最初の広告は経路全体の証明でも、最終利用者の表示能力の保証でもない。

受け入れは全ビットの保管責任だった

対応サーバーはDATAで受け取った各オクテットの全ビットを保存し、そのまま配達または中継しなければならない。この責任はスプール、検査器、キュー、送信プロセスを横断する。入口だけが対応していて内部の古い部品が上位ビットを落とすなら、広告は実装上の虚偽になる。

ただし、これは認証や安全性の約束ではない。送信者を証明せず、本文が安全とも配達が完了するとも言わない。受け入れたオクテットを七ビット時代の仮定で変質させない、という限定された責務である。

8ビットは任意のバイナリではなかった

DATAの行構造とドット透過性は残る。単独のピリオド行は依然として終端であり、行頭のピリオドは輸送時に重ねる。行長制限も消えず、RFC 6152はCRLF込みで1,000オクテットまでしか保証しないサーバーを認めている。

そのため8BITMIMEが支えるのはMIMEの8bitであってbinaryではない。行の中で許される値を増やしたが、行そのものをなくしてはいない。CHUNKINGとBINARYMIMEは別の境界を扱う。

次のホップで変換か失敗かを選ぶ

次のサーバーが能力を広告しない場合、中継は「たぶん通る」と送れない。RFC 6152は二つの選択を残す。quoted-printableやbase64などを使い、情報を一切失わない正当な7ビットMIMEへ変換するか、障壁を恒久的な配達失敗として扱う。

規格が変換器を指定しないのは重要である。ヘッダー、multipart境界、改行、転送符号化ラベル、署名まで整合しなければならない。出力が七ビットだけでも、読み手が別の意味を得るなら無損失ではない。証明できない書換えより明示的失敗の方が誠実である。

宣言は検証可能な台帳を作った

BODY=8BITMIMEはクライアントの申告で、自動的な真実ではない。運用では、相手が広告した能力、送信側のBODY値、実際に観測した本文領域、次ホップでの処置を分離して記録する必要がある。そうして初めて文字化けを送信元、危険な変換、内部欠損、表示障害に切り分けられる。

歴史的な成果は、権限の範囲を小さくしたことだった。MIMEは荷物を説明し、SMTP接続はこの保管者が引き受けられるかを示し、次の接続はもう一度問い直した。

出典と限界

規範の系譜はRFC 1426、RFC 1652、RFC 6152にある。RFC 2045がMIME領域を定義し、IANA登録簿が現在の項目を示す。これらは現代の導入率や変換頻度を測定しない。