要約

  • 1998年3月のRFC 2298では、差出人が Disposition-Notification-To を付けて処理通知を求められる。受信側のユーザーエージェントは依頼を黙って無視でき、当時の形式には明示的な denied もあった。
  • 通知には表示、転送、処理、削除などの動作が記される。仕様は利用者の同意を強く勧め、一人の受信者について一通のメールから送れる通知を一回に限った。2004年のRFC 3798は、使われなかった denied と failed を削除した。

封筒に忍ばせた小さな質問

1998年のオフィスでメールを送る。件名も本文も普通だが、ヘッダーには差出人の願いが一行ある。処理されたら、このアドレスへ知らせてほしい。Disposition-Notification-To はその宛先を示す。ネットワークを越えて受信箱に着いたとき、差出人ができるのはそこまでだ。返答を出す場所と出さない場所は、受信側のプログラムにある。

RFC 2298は、Message Disposition Notification、略してMDNを定めた。第2節はヘッダーを「依頼」と位置づける。受信側のユーザーエージェントは黙って流してよい。原版には denied という返事もあり、相手に処理状況を知らせたくない意志を示せた。さらに仕様は、通知を送る前に利用者の同意を取るよう強く勧めた。一通ずつ確認する画面でも、あらかじめ設定した好みでもよい。受信箱は差出人の監視窓として設計されなかった。

通知の語彙は、俗にいう「既読」より細かい。displayed はメールソフトが受信箱を見ている誰かに内容を表示した状態。dispatched は印刷や転送などで別の場所へ送った状態。processed は規則やサーバーが処理した状態。deleted は削除した状態だ。定義の章が数えているのはプログラムの動きである。表示の向こう側にいる人が文面を理解したかどうかは、ソフトの記録項目からは出てこない。

同じ displayed でも、出来事の経路は異なる。RFC 2298は手動の操作と自動の操作を分け、通知の送信についても、その一通で利用者が許可した場合と事前設定に従った場合を分けた。差出人が受け取る一語の裏には、誰が操作し、誰が送信を許したかという二つの問いがある。プロトコルはその差をフィールドとして残した。

自動のやり取りが増殖しないよう、仕様は回数にも上限を設けた。一人の受信者について、同じメールからユーザーエージェントが発行できるMDNは一つまで。MDNそのものに新たな通知依頼を入れてはならず、MDNを受け取って別のMDNを作ることもできない。二台の機械がお互いに「受け取った？」「そっちは？」と無限に聞き合う喜劇を、数行の規則で閉じた。

宛先にも仕掛けがあり得る。差出人が通知の行き先を別人のアドレスにすれば、受信者たちのソフトを利用して第三者へ大量のメールを送れる。RFC 2298は Disposition-Notification-To と Return-Path を比べるよう求めた。違う宛先、欠けた戻り道、複数の宛先があれば、利用者に確認するか自動送信を控える。原文はメールのループとメール爆撃を理由に挙げている。小さな確認票を、他人を困らせる装置にしないためだ。

この制度では、差出人は質問を出せる。受信側のプログラムはアドレスと設定を確かめる。利用者は返すか黙るかを選ぶ。返ってくる通知は、その端末がしたことを述べる。配達のあとにも選択が残る設計だった。

やがて、はっきり断るための語は規格から消えた。2004年にRFC 2298を置き換えたRFC 3798は、denied と failed の実装・利用が見られなかったとして削除した。沈黙という返事のない返事は残る。「NO」の印を押す書式は消えたが、受信箱の扉は相変わらず受信側に付いていた。

既読通知の歴史は、差出人が勝手に人の注意を測る道具の歴史ではない。送信ヘッダー、受信側の判断、有限の状態報告がぶつかる場の歴史だ。メールソフトが表示した事実は報告できる。相手の心に文章が届いた瞬間は、その報告書の欄外にある。