要約

  • RFC4865のFuture Message Releaseは、メールを指定時刻より前に送出しないよう依頼する仕組みであり、その瞬間の送出や受信者への到着を保証しない。
  • DELIVERBYと併用するクライアントは、配達期限を送出許可時刻より厳密に後へ置く必要がある。サーバー側の拒否条件は別の文言で定められており、容量、時計、期限後の処理、通知の証拠も切り分けなければならない。

メールの待ち行列が減らないからといって、常に処理能力が不足しているとは限らない。まだ送ってはいけないメールを保管しているだけの場合もある。同じように、受付で返したエラーが必ずしも品質低下を意味するわけではない。矛盾した依頼を引き受けなかった結果かもしれない。

仮に、朝提出されたメールに「正午までは送出しない」と「午前十一時を過ぎたら配達を試みない」という二つの条件があったとする。これは説明のための仮定であり、観測した事故でも実行済みの試験でもない。空の待ち行列を用意し、回線を増強しても、二つの条件を同時に満たす時間は生まれない。

片方の条件を黙って外せば、システムは「成功」と表示できるかもしれない。しかし、それは同じ依頼をうまく実行したことにはならない。送信者の意図のどちらを軽く扱うか、サービスが代わりに選んだことになる。

2007年5月のRFC4865は、SMTPのメール投稿サービスにFuture Message Releaseを定義した。端末が十分な保存領域を持たない、あるいは予定時刻までオンラインでいられない場合に、サーバーへ事前に渡して待ってもらう仕組みだ。便利さの裏では、内容の保管、現在の容量消費、将来の実行義務が移動する。

予約で確定するのは何か

投稿サーバーはEHLO応答でFUTURERELEASEを示し、最大待機時間と最も遠い許容日時を知らせる。利用するクライアントは対応を確認したうえで、MAILコマンドに待機パラメーターを一つだけ付ける。

HOLDFORは時間の長さを、HOLDUNTILは日時を指定する。それぞれ対応する上限を超えてはならない。パラメーターがなければ既定の待機時間が適用される、という意味でもない。サーバーが機能を持つことと、個別のメールに待機を指示したことは別である。

二つの表現方法があるのは、端末の時刻能力が一様でないためだ。現地時刻は使えてもタイムゾーン情報が不足する場合や、十分に正確な時計がない場合を、規定は考慮している。表現を選べることには実用上の意味がある。

ただし、HOLDFORなら時計問題から自由になる、とは書かれていない。RFC4865は、サーバーの時刻が不正確だったり変化したりすれば、どちらの方法でも早過ぎる送出や遅れが起き得ると警告する。端末に都合のよい指定方法と、運用側の信頼できる時間基準は同じものではない。

将来の送出要求付きで受け付けたメールを、サーバーは指定時間の経過や指定日時の到来より前に送出してはならない。ここで決まるのは「それ以前には出さない」という下限だ。許可される最初の瞬間に必ず実行するという保証ではない。

待機条件が解けても、実際の送出試行、次のサーバーの受付、最終的な配達は残る。受信者が読む時刻はさらに別である。カレンダーに表示された一つの値だけで、これらの出来事まで予約したと考えることはできない。

二つの時刻が未来でも、依頼は矛盾する

RFC2852のDELIVERBYは、配達までの時間と、間に合わない場合の扱いを指定する別の拡張だ。優先処理を要求する仕組みではない。サーバーが優先度を上げることはできるが、指定しただけでその扱いを受ける権利が生まれるわけではない。

DELIVERBYは送出を遅らせる命令でもなく、配達できないメールの通常の保持期間を延ばすものでもない。予約送信と併用して時間の窓を作れても、その窓に通る能力まで確保したことにはならない。

RFC4865の第5.2.1節は、併用するクライアントに対し、明示した、または時間間隔から導いた送出許可時刻より、配達期限を厳密に後へ置くよう求める。二つとも未来の日時ならよい、という確認では足りない。

サーバーについては第5.2.2節に別の書き方がある。両方の拡張に対応するサーバーが、送出時刻のほうが配達期限より後だと判断した場合、MAILを拒否しなければならない。応答501と拡張状態コード5.5.4が推奨される。

この二つを、同じ比較式へ勝手に直してはいけない。サーバーの明記された拒否条件は「後」であり、「同時か後」ではない。一方、その文言を根拠に、クライアントが同じ時刻を指定しても適合すると主張することもできない。クライアントには厳密に後へ置く義務が残る。

等しい値への実装の反応が重要なら、独立した境界試験として観測すべきだ。クライアントが自身の条件を守ったかと、サーバーが何を返したかを分ける。この分析では、その試験結果を持っているとは主張しない。

明らかな逆転に対する受付拒否には実務上の意味がある。送信者は、早く漏れることを避けたいのか、遅れて届くことを避けたいのかを選び直せる。受付率を上げたいサーバーが、その業務判断を見えない場所で代行せずに済む。

期限切れを一種類の処理にしない

DELIVERBYのReturnとNotifyは、期限後の結果が異なる。Returnでは、期限までに対象の配達または中継ができなければ、それ以後の配達試行を続けてはならない。通知条件に該当する受信者には、規定された失敗通知を生成する必要がある。

Notifyでは、期限を過ぎても作業を止める必要はない。規定は、拠点の方針に従って試行を続け、該当する受信者に所定の遅延通知を出す扱いを示す。通知を出す境界と、試行を終える境界は一致しない。

画面上の「期限切れ」という短い表示だけで再試行や廃棄を決めると、二方向に間違える。何でも再試行すればReturnの停止条件を破り得る。何でも止めれば、継続すべきNotifyの作業を放棄し得る。届いた件数が多いほど常に正しい、という評価では扱えない。

次の中継先にも条件がある。ReturnはDELIVERBY非対応のサーバーへ渡せず、そのサーバーの固定最小時間が残り時間を上回る場合にも渡せない。Notifyは非対応の区間を通れるが、RFC2852が定める通知上の帰結を伴う。義務が保たれたかどうかは、転送ログの存在だけでは分からない。

また、失敗を知らせる通知そのものが優先して運ばれるとは限らない。RFC2852はこの点を明示する。配達試行を短い時間で打ち切らせても、送信者が同じ時間内に失敗を知れる保証にはならない。通知がまだない状態を、成功と補ってはならない。

受付の段階も正確に記録する必要がある。MAILへの肯定応答は、メール全体の提出が最後まで成功した証拠でも、配達完了の証拠でもない。RFC2852は、受信者の処理やデータ送信完了の段階で、履行できない条件が分かる場合を挙げる。「受付済み」という一つの指標では、まだ交渉中の状態まで混ざってしまう。

認証済みでも、容量は無限ではない

サーバーが代わりに待つということは、送って処理を終えることのできない内容を保有するということだ。権限のない利用への対策は必要だが、正当に利用できる人の要求でも容量は尽きる。認証は利用者を識別しても、その人が使う資源を無限にはしない。

RFC4865は、将来送出するメールの保存領域に利用者ごとの割当量を設けることを推奨する。その割当量を実施しているサーバーが、新しいメールで上限を超えると検知した場合は、MAILを拒否しなければならない。

ここでは条件を省かないことが重要だ。割当量を導入する推奨と、導入済みの割当量について検知した超過を拒む義務は同じ強さではない。すべての実装が同じ方法で領域を予約しているという説明にもならない。

X.7.16とX.7.17は、利用者側の割当量不足とシステム側の割当量不足を分ける。ある利用者の待ち行列が減るのを待つことと、共有予算に余裕が戻るのを待つことは別の対処だ。同じ「容量不足」として一律の再試行時間を与える根拠にはならない。

個別の要求が上限内でも、将来負荷が平らになるとは限らない。多くのメールが同時に送出可能になることは、検証に値する運用上の想定である。ここで測定した事故ではないが、制約が保存量から送出処理や外向き輸送へ移る可能性を示す。

したがって、最大何日先まで予約できるかという表示を、その日の空き能力の証明とみなしてはいけない。商品として遠い将来まで約束する部門と、その約束を保管して実行する部門には、容量と費用について明確な接点が必要になる。

Lu HengのNote32は、制御する力と経済的な結果が分離する代理問題を論じる。この視点をメールへ適用すると、誰が将来の待機を売り、誰が資源と結果を負担するのかが問える。ただし、それは特定企業や技術者の悪意を示す証拠ではない。BTW.Mediaについて述べたNote36が求めるのも、陣営の擁護ではなく構造の記述である。

元の依頼と、実際に起きたことを並べる

将来送出の要求を含むメールについて投稿サーバーがDSNを生成する場合、RFC4865は機械可読部分にArrival-DateとFuture-Release-Requestを含めるよう求める。後者は当初の待機要求を、規定された形で保存する。

これによって、依頼された待機と意図しなかった輸送遅延を区別しやすくなる。ただし、元のパラメーターは実際の送出時刻そのものではない。次の区間が受け付けた証拠にもならない。依頼の記録と実行の観測を対応させる作業が残る。

クライアントは、DSNやMDNを投稿サーバーへ提出する際、この将来送出を要求してはならない。処理結果を伝える通知を、同じ拡張で故意に先送りする通知へ変えないための明確な制限だ。ネットワーク上で通知に遅れが絶対に生じない、という保証とは違う。

メールヘッダーのDateも待ち行列の履歴の代わりにはならない。RFC4865は、提出後にはDateを含むヘッダーが変わらないこと、クライアントが将来時刻をDateに選ぶことはできること、輸送側が遅れを隠すために追跡情報を変更する要求や期待はないことを述べる。

一方、RFC6409は、提出段階で欠落した、あるいは構文が不正なDateを限定的に補完・修正することを認める。この扱いまで否定する「サーバーは日付を一切変更できない」という説明は強過ぎる。

RFC4409を置き換えるRFC6409は、投稿と中継を分離し、投稿は通常587番ポートを使うとする。特定の25番サービスを投稿用と位置づける一般的な許容は、普通の中継サービスでFUTURERELEASEを宣言してよいという意味ではない。拡張自体の投稿専用という範囲は保たれる。

文書の限界まで含めて判断する

RFC4865の検証済み編集上の正誤表2040は、未定義だった日時の生成規則をRFC3339のdate-timeへ結び直す。報告者が2010年に自分の稼働サーバーへ言及したことは、帰属と時点のある証言であり、現在の導入規模を測ったものではない。

RFC2852の編集上の正誤表2300は、文書更新まで保留されている。対象は文法記述の空白で、期限の意味を変更するものではない。正誤表の状態を飛ばして、新しい動作規定が承認済みであるかのように扱うべきではない。

この分析は、SMTPコマンドの実行、時計の操作、実サービスの待ち行列調査を行っていない。文書から説明できるのは義務と確認すべき条件である。等しい日時への応答、実際の遅延、負荷時の回復は、利用する実装の証拠を別に必要とする。

予約機能の価値は、すべての依頼を受け付けることではない。待つべき仕事を確実な責任の下に置き、矛盾する仕事を相手の意図を改変する前に返せることだ。到着の約束を増やす前に、出発できる時間が本当にあるかを確かめる必要がある。

資料