要約

  • RFC 5364 は、一つの展開済み URI リストから受信者ごとに異なる履歴を作る。copyControl が欠ければ bcc となり、ブラインド項目は他者の履歴から消える一方、匿名項目はダミー URI と件数だけを残し得る。
  • 同一 URI は原則一回だけ送信し、競合する表示区分は to、cc、bcc の順に解決する。bcc は anonymize にも優先するため、正規化と開示判定を別々に記録する必要がある。
  • 履歴本文は互換性のため任意扱いであり、URI の存在、到達、受諾、参加、課金を証明しない。TLS や S/MIME が守るのは保管経路であり、投影の完全性や真実性ではない。

任意の本文には二つの成功状態がある

受信者履歴は recipient-list-history disposition を持ち、handling=optional とされる。multipart や新しい disposition を理解しない端末でも、主要求を拒否せず処理できるようにする設計である。

ここから二つの受領証が必要になる。一つは SIP 要求が受理されたという記録、もう一つは履歴本文が保持、解析、表示され、必要な局所制御に使われたという記録だ。

中継が本文を添付しただけで「履歴付き配信」と報告すると、旧式端末が本文を捨てた事実が見えなくなる。特にブラインド受信者に対する返信制御は、履歴が読まれなければ働かない可能性がある。

MIME 境界、disposition、handling 値、端末能力、parser の結果、表示結果、fallback を保存する。任意部分の無視は許される動作でも、観測不能であってよいわけではない。

可用性を保つ互換性と、開示文脈を必須にする安全性は別の判断である。機微な用途では、履歴なしで処理を続ける条件をサービス側が明示すべきだ。

履歴は元リストの複製ではない

relay はリソースリストを展開し、最終 URI ごとに要求を作る。その際に添付する履歴は、元の XML をそのままコピーしたものではない。

to と cc は可視項目として残り得る。bcc は他の受信者のコピーから外される。ブラインド受信者本人のコピーだけには、自分が非公開であることを知らせるために本人の URI を含められる。

同じ実行から異なる本文 hash が生まれるのは正常である。改ざんか正しい秘匿かを判断するには、観察者の URI、適用規則、表示項目、除外項目、匿名項目を結び付けなければならない。

元リスト hash、展開結果、分類解決、各送信要求 ID、各履歴本文 hash を連鎖させる。全員分を一つの「最終受信者一覧」に平坦化すると、誰に何を見せたかという証拠が消える。

リスト作成者の操作権限、中継の開示責任、受信端末が得る限定された視界は、それぞれ異なる権限面である。

属性がなければ bcc になる

copyControl が存在しない項目は bcc として扱われる。古いリスト、移行時の欠落、拡張を知らない生成器が、結果として URI の公開許可を持つことはない。

明示された bcc と既定値として補われた bcc は、出力が同じでも診断が違う。前者は作成者の意思であり、後者は不完全な入力に relay が安全側の規則を適用した記録である。

元 XML、hash、schema、属性の有無、parser、既定値規則、最終区分を残す。正規化後の bcc だけを保存すると、元データが欠けていたのか明示されていたのか分からない。

parser やライブラリを更新するとき、属性欠落 fixture が引き続きブラインド扱いになることを確認する。既定値の退行は、既存リスト全体を静かに公開側へ変え得る。

bcc と匿名化は異なる情報を隠す

bcc は他者向け履歴から項目を消す。anonymize=true は、実 URI を仕様定義の匿名 SIP placeholder に置き換え、count で複数項目を表せる。

匿名化は身元を隠すが、存在と人数を明かし得る。「匿名の受信者が四人いる」という情報は、交渉や対応判断に影響する。実 URI がないだけで漏えいゼロとは言えない。

同じ項目に bcc と anonymize があれば、bcc が優先する。匿名 placeholder を出力すれば、ブラインド規則が隠すはずの存在を知らせてしまう。

監査では身元漏えいと件数漏えいを分けて検査する。各投影について、元属性、優先規則、完全除外集合、匿名集合、count と実際の本文を保持する。

製品画面で両者を単に「非公開」と表示すると、どの事実が受信者へ伝わったのか確認できない。

重複排除は表示意図を選ぶ処理である

ネストしたリストを展開すると、URI scheme の比較規則上は同一の宛先が複数経路から現れることがある。文字列一致だけでは不足し、過剰な正規化も別の宛先を誤って統合する。

RFC 5364 は同一受信者へ複数要求を送る合理的用途はないとし、最大一回を想定する。区分が競合すれば to、次に cc、最後に bcc を選ぶ。

先頭行を残す実装では入力順が意味を変える。二回送れば同じ端末が矛盾した履歴を受け取る可能性がある。これは単なるデータ掃除ではなく、開示政策の決定だ。

原 URI、比較方式、衝突 group、出現経路、全属性、勝った区分、唯一の送信 ID を記録する。RFC 5363 の記事が一般的 fan-out と結果を扱うのに対し、ここでは重複した同一性からどの可視性が残るかだけを扱う。

reply-all が最後の秘匿を壊し得る

relay が正しく bcc を適用しても、ブラインド受信者が全員返信すれば自分の URI を可視グループへ露出する。

RFC 5364 は、受信者自身の URI が履歴にない、またはブラインドとして示されるとき、端末が reply-all を止めるか制限することを求める方向を示す。履歴は飾りではなく UI 動作の入力になる。

ただし端末は別名、転送先、複数 account のどれが自分かを判定しなければならない。誤判定は正常返信の過剰禁止か、ブラインド身元の漏えいを生む。

受信本文、parser 結果、選択した局所 identity、照合、button 状態、実際の返信宛先を保存する。server 側 bcc 成功は endpoint 側秘匿成功の証明ではない。

偽造された履歴が UI を操作する可能性もあるため、履歴の信頼文脈と局所 identity 判定を同時に試験する必要がある。

表示された URI は参加者ではない

仕様は、recipient-list history が実際の参加者一覧ではないと明記する。URI は存在しないかもしれず、到達不能、未応答、拒否、または自動端末かもしれない。人は別 identity で参加することもある。

履歴だけで課金もできない。招待は利用ではなく、要求生成は session 受諾ではない。表示項目から時間、capacity、支払責任は分からない。

履歴自体も spoof 可能である。妥当な XML は構造を示すだけで、社会的事実を示さない。署名や暗号化があっても、保護された虚偽は虚偽のままである。

送信要求、endpoint response、認証済み join、media 観測、継続時間、resource 使用、billing event は後段の別証拠として保存する。相関はできるが、履歴 membership で置き換えてはならない。

履歴が答えるのは「この要求にどの開示 view が添付されたか」であり、「誰がそこにいたか」ではない。

TLS と S/MIME は投影を真実にしない

受信者関係は機微なので、認証、認可、TLS、S/MIME は重要である。選択した trust model の下で hop や content を守る。

しかし正しい元リストを読んだか、URI 比較が正しかったか、優先順位や count が正しいか、端末が正しく表示したかは証明しない。もちろん session outcome も証明しない。

transport peer、certificate または key、検証結果、保護範囲を記録し、入力 hash、engine version、規則 version、受信者別出力 hash と分離する。

安全な channel は誤った投影も完全に届けられる。保管の安全性に意味の正しさを借りてはならない。

投影台帳は見えなかった項目も保存する

第一の受領証は submitter、authorization、元 XML、request context を凍結する。第二は nested list の展開 graph、第三は URI 比較と衝突 group を記録する。

第四は明示値、既定 bcc、匿名 flag、重複優先順位、bcc と匿名化の関係を残す。第五は受信者ごとの可視集合、除外集合、placeholder、count と本文 hash を outgoing request に結ぶ。

その後に、optional part の認識、表示、reply-all 抑止、配信 response、実参加、課金という独立した受領証が続く。

表示結果だけでは正しく隠した対象を証明できない。master list だけでは何を明かしたかを証明できない。両方と変換過程が必要である。

試験単位は受信者ごとの正確な本文

fixture は属性欠落、to、cc、bcc、単数・複数匿名、bcc と匿名化の併存、競合属性を持つ同値 URI、ブラインド本人の copy、可視受信者の copy、optional part を無視する旧端末を含める。

各例で request 数と履歴本文の正確な bytes を確認する。次に自己 URI 認識、表示、返信抑止を確認し、最後に参加・課金 logic が履歴を現実の代用にしていないことを検証する。

承認後の元リスト差し替え、重複順序変更、属性削除、count 改変、履歴偽造、optional part 剥離、旧投影 replay も試す。受理した経路には適用規則の証拠が必要である。

RFC 5364 が 2008 年 10 月の Proposed Standard であり、今回取得した errata page に一致項目がないことは文書上の事実である。現行製品の採用や実際の事故を示すものではない。