Summary

  • Structured Emailの基本草案は、機械が読める application/ld+json を提案する。信頼に関する第02版草案は、受信アプリがその内容を表示・処理する条件を扱う。
  • 第4.1節には七つの代替条件がある。信頼する署名者のほか、既存の信頼できる会話や、以前の信頼できるメールとのつながりも表示判断に入る。
  • DKIMはメール全体を、JWSは構造化部分だけを署名し得る。署名者を信用するかは受信側アプリの判断だ。

一通のメールには、本文の文字、HTMLの見栄え、ソフトウェアが読む構造化データが同居する。便名や時刻が三つの場所に書かれれば、受信アプリはどれを使って操作画面を作るか決めなければならない。基本草案はデータの形を定める。11月2日付の信頼草案は、データを画面上の行動へ昇格させる条件を示した。

草案の分類は迷惑メール、通常のメール、信頼できるメールの三つ。構造化データを処理するのは最後の区分だ。署名の成功はその判断材料になるが、表示を許す規則そのものはメールアプリにある。読者は画面に現れたボタンを送信元の保証と受け取りやすい。実際には製品の判断が一段挟まる。

第4.1節は七つの道筋を列挙する。HTMLに比べて攻撃面が増えないこと、既存の予定招待や更新と同等の扱いをすること、信頼する送信者と有効な個人・ドメイン署名、同じくDKIM署名、信頼するJWS署名者、信頼する送信者との継続中の会話、過去の信頼済みメールとの結び付き。七項目をすべて満たす方式ではない。同一のMIMEでも、クライアントの会話履歴と採用する条件によってボタンの有無が変わる。

会話の記憶が新しいメールを押し上げる

継続中の会話という条件は便利で、同時に危うい。以前からやり取りしていたアカウントが侵害されれば、新しいメールは古い関係を足場にできる。どの相手を、いつから、どの操作まで信頼したか。ここが製品ごとに曖昧なら、署名ログだけを調べてもボタンの理由に届かない。

DKIMはメール全体を対象にし、JWSは構造化部分だけを対象にできる。草案には分離したJWSペイロード、バイト列と正規化JSONの比較という未決事項も残る。迷惑メールフィルターが本文を読み、アプリが別の構造化部分から操作を作るなら、審査した内容と表示した内容が食い違う。表示された旅程と署名対象、本文の三者を並べて初めて原因が見える。

外部参照も画面を越えて働く。メールアプリが遠隔の情報を読み込めば、開封が相手に伝わり、署名対象の外にある内容が入ってくる。第4.3節は、意味のある操作にWeb取得が必要になる場合、データをできるだけ自己完結させるよう勧める。実際の複数アプリで同じ署名済みメール、関連返信、外部参照を比較した公開試験は見当たらない。生のMIME、表示された操作、通信記録を揃えれば、運用上の差が判明する。

信頼草案の履歴 · 基本草案 · DKIM · JWS