メールヘッダーの山かっこ付き識別子の中にopenvpnを見つけると、メッセージがVPNセッションと関係しているという結論に飛びつきたくなります。その前に行全体を読んでください。この文字列はContent-IDの中にあり、Content-IDとは一つのメッセージ内の一つの本文パートの名前です。HTML内のcid:参照はその名前を指しており、この組が存在するのは、メールが画像を二度送らずに運べるようにするためです。この仕組みのどこもVPNサーバーには届かず、サフィックスのどこにも識別子を誰が作ったかは書かれていません。

識別子が実際に指しているもの

HTMLメールが一つの塊として届くことはほとんどありません。本文と各インライン画像は通常、別々のMIMEパートとして運ばれ、クライアントが表示のために組み立て直します。そのためには画像パートの名前と、その名前に解決する参照が必要です。

以下の組は説明のために作ったものです。

Content-ID: <[email protected]>

<img src="cid:[email protected]" alt="Company mark">

ヘッダー行は画像パート側にあり、img要素はHTMLパート側にあります。山かっこはヘッダーの構文に属するため、cid:参照は通常それを付けずに識別子を書きます。エスケープが必要な文字を含む値は符号化しなければならず、だからこそこの組は変換規則ではなく例なのです。意味を担うのは二つの文字列の一致であり、どちらか片方ではありません。

@openvpnサフィックスは構築上の詳細

Content-IDは一つのメッセージ内で一意になるよう作られ、メールソフトはしばしば@とドメインを付けてアドレスのように見せます。その形は生成側の慣習であり、経路ではありません。ヘッダーのどこもクライアントにmailer.exampleへの接触を求めておらず、メッセージを表示するときに照会も起きません。この項目はアカウント名でもVPNユーザーでもVPNクライアントが残した印でもありません。メッセージを組み立てた人が、パートに名前を付けるときにこの文字列を選んだのです。

RFC 2392はcidスキームを定義し、メッセージとそのパートへの参照に限定しています。この範囲を文字どおり読めば、サフィックスは命名以上の何かの証拠ではなくなります。これは、サフィックスから作成者を特定できないことも意味し、ヘッダーに見慣れた語が現れたときに人がする飛躍がまさにそれです。

生のソースを調べ、それからプライバシーの問いを判断する

生のソースを開いてContent-IDの値全体を読んでください。RFC 2392は値が発信者のホスト名やアカウント風の文字列を運ぶことを許しているからです。次に、同じ名前が現れる箇所をすべて探します。HTML内のcid:参照、別のヘッダー、以前の返信からの引用ブロックです。それらの出現の一致が、そのパートの目的を教えてくれます。

まさにこの性質のため、識別子がプライバシー上重要になり得ます。ホスト名やアカウント名から派生した値はメッセージとともに移動し、送信した機械や人物について何かを明かし得ます。それでもVPNセッションではなく、そう扱うと発見を無駄にします。

リモート画像か埋め込みパートか:異なる通信

ソースがhttpsのimg要素と、ソースがcidのimg要素は、HTMLでは似て見えますがネットワーク上では違う振る舞いをします。前者はメッセージを開いた後にクライアントが取得し得る資源を指し、その取得は送信者に、メッセージが読まれたこととどのアドレスからかを伝えます。後者はメッセージ内に既にあるパートに対して解決されるため、表示しても誰とも通信しません。

一つのメッセージが両方を混在させることがあり、片方を確認しても他方は晴れません。リモート参照は埋め込みとは別に数え、クライアントの設定が何を許すかを記録してください。プライバシーで重要な判断はその区別であり、識別子の中の語ではありません。

メッセージを送らずに証拠を共有する

他の人がこれを確認する必要があるときは、まず伏せ字にし、一貫して伏せ字にしてください。アドレスと無関係なヘッダーを置き換え、そのうえでContent-IDとそのcid:参照をコピー内で同一の綴りに保ちます。不一致は意味のある唯一の証拠を壊すからです。ヘッダーがどのパートのものだったか、どの行がそれを参照したかを伝えてください。レビュー担当者に必要なのは関係であり、メッセージではありません。

そのうえで二つの結論を文書で分けてください。メッセージが何を含むか、そして何を証明しないかです。そう枠組みされた主張は検証も反論もでき、有用な報告書はそれを可能にします。

関連記事