Summary

  • RFC 1845は1995年の実験的なSMTP拡張で、受信側のCHECKPOINT応答、送信側のTRANSID、不揮発性の保存状態を使って中断した転送を再開する。
  • 対話例の355 6135は、受信側が本文データを6,135バイト保存したことを示す。宛先などのエンベロープ命令や、SMTPのドット詰めで増えたバイトは数えない。

長いメールを不安定な回線で送る。終わりに近いところでTCP接続が切れる。送り手は最初から全量を送り直す。また切れればまた最初からだ。従来のSMTPに途中で再開する手続きがなかったため、通信量の請求書だけが膨らむ。D. Crocker、N. Freed、A. Cargilleが1995年9月に示した実験的なRFCは、この浪費を受け手側の記録で止めようとした。6,135という数字はRFCに書かれた例であり、実際の障害の観測値ではない。

最初に確かめるのは能力だ。送信側がEHLOを送り、受信側の応答にCHECKPOINTがあれば、この方式を使える。そこでMAIL FROMにTRANSIDを添える。これはメール一般の名前ではなく、特定のSMTPリンクで運ぶ一つのコピーの取引番号で、大文字と小文字も区別する。通常のMessage-IDは、別々の経路を通る複数のコピーに共通することがある。別のコピーの進捗を借りてしまわないため、RFCはTRANSIDを別に用意した。

受信側は番号だけ覚えていても足りない。取引の最新状態を不揮発性の保存先に残す必要がある。RFCは中断状態を少なくとも48時間保持するよう勧めるが、保存期間は運用方針に委ねた。再接続する送信側も、古い接続が解放されるまで待ち、DNSを調べ直す。元のサーバーのアドレスがまだ有効なら先に試し、続いて他の候補へ進む。他のサーバーで再開できないなら、取引全体を送り直す。元の機械が戻るのをいつまでも待つわけにはいかない。

再開時には同じTRANSIDでMAIL FROMを繰り返す。受信側が355 6135を返したとき、6,135は保存済みの本文データのバイト数だ。MAIL FROMやRCPT TOの文字数を足さない。行頭の点を守るためSMTPが挿入したバイトも足さない。DATAで送る場合、位置は行の先頭でなければならない。手元のファイルを単純に6,135バイト飛ばすだけでは、受信側と同じ場所を指せない。基準はSMTPの正規の本文データ列である。

例の続きは地味でよい。送信側はDATAを再開し、保存済みの部分を省いて残りを送り、250 OKを受ける。RFCは送信側が全データ列を作り直し、位置に達するまで出力だけ抑える実装も挙げる。回線に同じ前半をもう一度流さなければ、節約の目的は果たせる。

この数字は一つの取引についての保存記録だ。受信者がメールを読んだ証明でも、全経路で共通のメッセージ番号でもない。狭い範囲を正確に言い切るから、切れた回線の先で次の一手を決められる。