要約

  • 元のSMTPでは、サイズ制限や記憶域不足が、DATA全体を受信して破棄した後にしか分からない場合があった。
  • RFC 1870は、サーバがEHLOで固定上限を示し、クライアントがMAIL FROMで推定オクテット数を申告する仕組みを定めた。恒久的な超過は552、一時的不足は452で表せた。
  • 数値は限定された証拠にとどまる。DATAの終端でも、全経路の記憶域予約でも、MAIL成功を最終配送に変える保証でもない。

判定が費用より後に来た

RFC 821の取引は、MAIL、一つ以上のRCPT、そしてDATAという順序を持つ。受信側が354を返すと、送信側はヘッダ、本文、終端行を送り、受信側は完成したオブジェクトを見て最終応答を返した。

この順序は明快だが、資源について既知の事実を遅い位置に置いた。管理上の固定上限により最初から不可能な場合も、たまたまバッファや安定記憶域が足りない場合もある。拡張のないSMTPでは、それでも全オクテットを転送してから捨てるしかなかった。マルチメディアメールが増えるほど、回線と時間を消費する失敗になった。

所有者の異なる二つの宣言

仕組みは1993年のRFC 1427に現れ、RFC 1653を経て、1995年のRFC 1870で標準化された。受信サーバはEHLO応答にSIZEを掲げ、常に受け入れる最大メッセージの固定値を任意で添える。

値ゼロは固定上限がないことを意味する。数値を省略したSIZEは、固定上限について何も通知しないだけで、無限を意味しない。送信側はMAIL FROMに別のSIZEを付け、今回送るメッセージを見積もる。正確な計算が難しければヒューリスティックを使え、過小より過大に寄せることが勧められた。

サーバは自らの規則を、クライアントは自らのオブジェクトを述べる。共通の数字は判断を可能にするが、相手にディスクやキューの支配権を渡さない。

計測はフレーミングではない

数えるのは354後に送るヘッダ、本文、行間のCR-LFである。DATAの終端となる単独ピリオドと、ドット透過のためだけに追加されるピリオドは除く。

しかしRFC 1870は、SIZEを内容終端の判定に使うことを禁じる。誤った見積もりは受理判断を変えても、本文を次のコマンドに化けさせない。DATA終端がフレーミング権限を保つ。SIZEは資源証拠であり、ドット透過やBDATとは別の問題である。

452は時間を残し、552は閉じる

申告値が固定上限を超えれば、サーバは552を返せる。同じ規則に同じ物を再試行しても成功しない。一時的に資源が足りず、後で回復し得るなら452を返し、送信側は再キューできる。

この区別は将来の仕事を配分する。恒久規則を一時障害と見れば無駄な再試行が続き、一時不足を恒久拒否と見れば可能だった配送を失う。さらに受信側は宛先ごとに判断できる。同じ申告サイズでも、あるRCPTを受理し、別を延期し、別を恒久拒否できる。共通尺度はローカルなメールボックス方針を消さない。

早い250は受領証ではない

MAILへの250は絶対保証ではない。実際のDATAが申告を超えるかもしれず、資源は変化し、後段リレーや最終配送も失敗し得る。サーバは過小申告を許してよいが、義務ではない。

一方、申告値を受け入れたなら、実データがその値以内である限り、通常の固定上限だけを理由にDATA後の552を返すべきではない。この限定された信頼は、早期判断を有用にしつつ、普遍的な予約を作らない。

後のRFC 5321は少なくとも64Kオクテットの受理を求め、制限が必要なサーバにSIZEを勧めた。世界共通の添付上限は作らなかった。各リレーが自分の費用を決め、標準はそれを早く伝える方法だけを共有した。

情報源と限界

元の取引はRFC 821、拡張の系譜はRFC 1427、RFC 1653、RFC 1870、後の基準はRFC 5321にある。これらは現在の普及率や事業者別上限を測定しない。SIZEは内容認証、クォータ証明、全経路予約、配送受領証ではない。限られた容量証拠により、最終権限を集中させずに明らかに無駄な転送を減らした歴史である。