Суффикс cid, похожий на ID VPN, — это всего лишь MIME Content-ID

Вы видите openvpn внутри идентификатора в угловых скобках в заголовке письма, и очевидный вывод — что сообщение связано с сеансом VPN. Прочитайте всю строку, прежде чем на этом настаивать: эта строка находится в Content-ID, а Content-ID — это имя одной части тела внутри одного сообщения. Ссылка cid: в HTML указывает на это имя, и пара существует для того, чтобы письмо могло нести изображение, не отправляя его дважды. Ничто в этой схеме не достигает сервера 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 позволяет значению нести имя хоста отправителя или строку, похожую на имя учётной записи. Затем найдите каждое место, где встречается то же имя: ссылку cid: в HTML, другой заголовок, цитату из более раннего ответа. Именно совпадение этих вхождений говорит вам о назначении части.

Именно это свойство делает идентификатор значимым для приватности. Значение, производное от имени хоста или имени учётной записи, путешествует вместе с сообщением и может раскрыть что-то о машине или о человеке, который его отправил. Это всё ещё не сеанс VPN, и относиться к нему как к сеансу — значит потратить находку впустую.

Удалённое изображение или встроенная часть: разный трафик

Элемент img с источником https и элемент img с источником cid выглядят в HTML одинаково, а в сети ведут себя по-разному. Первый называет ресурс, который клиент может загрузить после открытия сообщения, и эта загрузка сообщает отправителю, что письмо прочитано и с какого адреса. Второй разрешается относительно части, уже находящейся внутри сообщения, поэтому его показ ни с кем не связывается.

Одно сообщение может смешивать и то и другое, и проверка одного не очищает другое. Считайте удалённые ссылки отдельно от встроенных и отмечайте, что допускают настройки клиента. Именно это различие — решение, важное для приватности, а не слово внутри идентификатора.

Поделитесь доказательством, не отправляя письмо

Когда кто-то другой должен на это посмотреть, сначала отредактируйте и делайте это последовательно. Замените адреса и посторонние заголовки, затем сохраните Content-ID и его cid: ссылку написанными одинаково в копии, потому что расхождение уничтожает единственное важное доказательство. Скажите, какой части принадлежал заголовок и какая строка на него ссылалась. Проверяющему нужна связь, а не письмо.

Затем разделите два вывода письменно: что письмо содержит и чего оно не доказывает. Утверждение, сформулированное так, можно проверить и оспорить, и именно это позволяет полезный отчёт.