Почему блокировка пикселей отслеживания недостаточна: новая волна нулевого клика в слежке за электронной почтой

Понимание эволюции отслеживания электронной почты за пределами пикселей

Классический пиксель отслеживания электронной почты — этот невидимый прозрачный 1×1 изображение, встроенное в HTML-письма — стал символом слежки через электронную почту. Когда ваш почтовый клиент загружает удалённые изображения, он отправляет HTTP-запрос на сервер отправителя, раскрывая факт открытия сообщения вместе с вашим IP-адресом, информацией об устройстве и приблизительным местоположением. Подробное руководство Inbox Monster по пикселям отслеживания электронной почты объясняет, что этот механизм долгое время был основой аналитики email-маркетинга, позволяя отправителям измерять процент открытий и вовлечённость.

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

Как изменения платформ усложнили защиту конфиденциальности

Ситуация стала сложнее, когда крупные почтовые провайдеры внедрили собственные функции конфиденциальности. Переход Gmail к автоматическому отображению изображений в конце 2013 года кардинально изменил ландшафт отслеживания. Как подробно описано в анализе Newfangled по кэшированию изображений Gmail, Google теперь загружает изображения через прокси-серверы, которые кэшируют копии, что означает, что пиксели отслеживания всё ещё срабатывают, но информация исходит от инфраструктуры Google, а не напрямую от получателя. Это защищает некоторые данные пользователей, при этом предоставляя отправителям подтверждение открытия.

Функция Mail Privacy Protection (MPP) от Apple пошла другим путём, скрывая IP-адреса пользователей и предварительно загружая содержимое писем через прокси-серверы Apple. Согласно официальной документации Apple, эта функция предотвращает определение отправителями точного местоположения пользователей и связывание их активности между службами. Однако такая защита может привести к срабатыванию пикселей отслеживания с серверов Apple вне зависимости от того, фактически ли человек прочитал сообщение, создавая новый уровень «шума» в данных отслеживания.

Эти меры на уровне платформ демонстрируют важную реальность: даже крупные технологические компании испытывают трудности с полной ликвидацией отслеживания электронной почты, сохраняя при этом функциональность писем. Напряжённость между богатыми HTML-письмами и защитой конфиденциальности создаёт пробелы, которые продолжают использовать продвинутые средства слежки, влияя на конфиденциальность при отслеживании электронной почты.

Наблюдение на основе CSS: скрытая угроза, которую не устраняет блокировка пикселей

Хотя большинство пользователей понимают, что блокировка изображений предотвращает работу отслеживающих пикселей, немногие осознают, что каскадные таблицы стилей (CSS) — язык, используемый для оформления и форматирования содержимого электронной почты — могут быть использованы для слежки и утечки данных. Это представляет собой одну из самых серьезных уязвимостей в традиционных методах защиты конфиденциальности, поскольку CSS работает независимо от настроек загрузки изображений и может функционировать даже при полном отключении JavaScript.

Прорывные исследования специалиста по безопасности Майка Гуальтьери по техникам CSS-эксфильтрации демонстрируют, как CSS можно использовать для кражи конфиденциальных данных без выполнения скриптов. Эта техника использует возможности CSS-селекторов для выделения определённых шаблонов ввода и свойства CSS для встраивания внешних URL. Злоумышленник, который может внедрить CSS на страницу, может создавать правила, соответствующие определённым символам или строкам в полях форм, а затем применять стили с фоновыми изображениями, указывающими на URL, контролируемые атакующим. Каждый запрос к URL может кодировать частичную информацию из целевых данных, позволяя злоумышленнику реконструировать учетные данные и личную информацию путем анализа серии HTTP-запросов.

Конкретные уязвимости внедрения CSS в почтовых системах

Теоретический риск стал реальной угрозой с появлением CVE-2026-26079 — критической уязвимости в Roundcube Webmail. По данным рекомендаций безопасности SentinelOne, эта ошибка в обработке CSS в Roundcube позволяла злоумышленникам внедрять произвольные CSS в содержимое электронной почты. При отображении этот вредоносный CSS мог осуществлять утечку чувствительной информации, изменять визуальный вид писем или проводить фишинговые атаки, меняя интерфейс пользователя — и всё это без необходимости какого-либо клика со стороны жертвы.

Коренной причиной была неправильная обработка CSS-комментариев в функции очистки Roundcube, что позволяло обходить фильтры и сохранять вредоносный CSS в итоговом HTML. Злоумышленник мог эксплуатировать эту уязвимость, просто отправив специально подготовленное письмо ; как только получатель открывал или предварительно просматривал сообщение, браузер рендерил CSS, что потенциально вызывало утечку данных через url() -функции или изменение интерфейса для сбора учетных данных. Этот механизм атаки без клика работает полностью независимо от традиционных средств защиты от tracking pixel, что ставит под угрозу конфиденциальность при отслеживании электронной почты.

Даже законные возможности электронной почты могут создавать каналы слежки на основе CSS. Документация Microsoft по использованию пользовательских веб-шрифтов в Dynamics 365 демонстрирует, как маркетологи загружают шрифты через объявления @font-face , которые получают файлы шрифтов с удалённых URL. Хотя основная цель — эстетика, эти обращения к внешним ресурсам могут логироваться сервисами хостинга шрифтов, создавая альтернативный маячковый канал, который работает независимо от настроек блокировки изображений.

Эксплуатация с нулевым кликом на базе ИИ: тревожный звонок EchoLeak

Интеграция ИИ-ассистентов в рабочие процессы электронной почты создала совершенно новый класс угроз слежки с нулевым кликом, с которыми традиционные средства защиты никогда не были предназначены бороться. Обнаружение EchoLeak (CVE-2025-32711) в Microsoft 365 Copilot в 2025 году стало переломным моментом, демонстрируя, как функции ИИ могут быть использованы для выведения конфиденциальных данных без какого-либо взаимодействия пользователя, кроме открытия письма.

Согласно научной статье об EchoLeak, компания Aim Security обнаружила уязвимость инъекции команд в Microsoft 365 Copilot, которая позволяла удалённым неаутентифицированным злоумышленникам выводить конфиденциальные данные посредством одного специально созданного письма. Атака работала путем отправки письма со скрытыми инструкциями, которые, обрабатываемые Copilot в рамках обычной работы с электронной почтой, заставляли модель ИИ получить доступ к внутренним файлам и вставить их конфиденциальное содержимое в специально созданное изображение Markdown или ссылку в ответе.

Как работает эксплуатация ИИ с нулевым кликом

Элегантность и опасность EchoLeak заключается в использовании стандартного поведения ИИ-ассистента. Когда Copilot отображал свой ответ в Outlook или Teams, интерфейс клиента автоматически пытался получить внешний URL-адрес изображения, включённого в ответ. Этот HTTP-запрос, кодирующий конфиденциальные данные, проходил через асинхронный API предварительного просмотра Microsoft Teams на сервер злоумышленника. Поскольку загрузка изображения происходила автоматически в процессе отображения ответа Copilot, для завершения утечки не требовалось никаких кликов пользователя — отсюда и название эксплуатации с нулевым кликом.

Эта уязвимость успешно обходила несколько уровней защиты, включая фильтры инъекции команд XPIA Microsoft и механизмы удаления ссылок, используя обфусцированные инструкции и опираясь на домен Microsoft, одобренный CSP, для проксирования исходящих запросов. Эти последствия выходят далеко за пределы экосистемы Microsoft: поскольку почтовые клиенты всё активнее интегрируют функции суммирования, категоризации и составления текстов на базе ИИ, данный класс атак становится широко актуальным на рынке.

Для пользователей, которые тщательно настроили свои почтовые клиенты на блокировку пикселей слежки и удалённого содержимого, эксплуатация на базе ИИ представляет совершенно иной вектор угрозы. Канал утечки в EchoLeak был сгенерированным ИИ изображением Markdown, URL которого кодировал конфиденциальные данные — это вовсе не традиционный пиксель слежения. Даже пользователи с жёсткими настройками блокировки изображений могут разрешать их для функций продуктивности или доверять содержимому, которое, кажется, исходит от их собственного ИИ-ассистента, что делает этот путь эксплуатации особенно коварным в контексте конфиденциальности при отслеживании электронной почты.

Обход аутентификации и злоупотребление доверенными отправителями

Одна из самых неприятных особенностей современных угроз электронной почте заключается в том, что злоумышленники могут отправлять сообщения с механизмами наблюдения, которые проходят все стандартные проверки аутентификации, выглядя так, будто они исходят от легитимных, доверенных источников. Многие пользователи полагают, что если письмо проходит проверку SPF, DKIM и DMARC, значит оно безопасно, а встроенные ресурсы безвредны. К сожалению, такое предположение создает опасную слепую зону, которую активно используют продвинутые злоумышленники, нарушая конфиденциальность при отслеживании электронной почты.

Согласно подробному анализу методов обхода DMARC от Sendmarc, злоумышленники могут отправлять поддельные или вредоносные письма, которые проходят проверку DMARC несколькими способами. Один из самых простых методов — отправка с инфраструктуры, уже доверенной целевым доменом, например, IP-диапазоны, добавленные в SPF-записи и никогда не удалённые, сторонние платформы, когда-то использовавшиеся, но теперь не контролируемые, или сервера, явно авторизованные через DKIM. Если злоумышленник может отправлять с авторизованного IP-адреса или сервера, он может согласовать SPF или DKIM и пройти проверку DMARC, что делает его сообщения полностью аутентифицированными, хотя отправитель является враждебным.

Канал наблюдения через захват аккаунта

Возможно, самым мощным вектором обхода DMARC является захват аккаунта. После того как злоумышленники получают доступ к настоящему почтовому ящику пользователя или системе, настроенной на отправку почты от имени организации, каждое их сообщение будет проходить SPF, DKIM и DMARC, как если бы оно было легитимным. Такие письма могут легко содержать трекинговые пиксели, вредоносный HTML или метки на основе CSS, которым получатели и системы безопасности склонны доверять, поскольку отправитель выглядит аутентично и знакомо.

Исследование также показывает, что инфраструктура Microsoft для электронной почты иногда пропускает письма с ошибкой DMARC в папки входящих из-за неправильно настроенных коннекторов или чрезмерно разрешающих списков, присваивая им специальный уровень доверия Spam Confidence Level (SCL:-1), который обходит фильтрацию спама. Кроме того, использование Sender Rewriting Scheme (SRS) на пересылаемых сообщениях может привести к подделке писем, которые выглядят так, будто успешно проходят SPF и DMARC на последующих узлах, хотя изначально они были подделаны.

Как объясняется в обзоре Cloudflare о подделке электронной почты, злоумышленники часто изменяют заголовки писем, включая поля "от" и "ответить на", чтобы выдавать себя за легитимных отправителей. Они также могут регистрировать похожие домены или изменять отображаемые имена, чтобы ввести получателей в заблуждение. Когда такие аутентифицированные на вид письма содержат трекинговые пиксели или более продвинутые метки, они используют подразумеваемое доверие пользователей к знакомому бренду и индикаторам аутентификации, чтобы максимально эффективно осуществлять наблюдение без кликов.

Метаданные: Врожденный канал слежки, недоступный для блокировки пикселей

Даже в гипотетическом сценарии, где почтовый клиент отображает все сообщения в виде обычного текста без внешних ресурсов, без предварительного запроса DNS и с идеальной санитацией CSS, значительная угроза конфиденциальности сохраняется через метаданные электронной почты. Это, возможно, самое основное ограничение, связанное с фокусом исключительно на защите от трекинг-пикселей: мониторинг метаданных работает на совершенно другом уровне, с которым блокировка контента на стороне клиента не справится.

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

Возможности профилирования по коммуникационным паттернам

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

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

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

Регуляторная и правовая среда: почему соблюдение требует больше, чем блокировка пикселей

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

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

Требования ЕС к цифровому согласию

Европейские органы по защите данных начали выдвигать особенно детальные требования к отслеживанию электронной почты. Как подробно описано в руководстве Mailbird по требованиям цифрового согласия в ЕС, французский CNIL предлагает требовать двойное независимое согласие пользователей: одно для получения маркетинговых писем и отдельное, отдельное согласие для технологий отслеживания, таких как пиксели открытия и кликов. Это означает, что объединение согласия на коммуникацию и наблюдение всё чаще считается неприемлемым, и отправители должны позволять получателям получать письма без отслеживания.

В соответствии с GDPR несоблюдение требований может привести к штрафам до 20 миллионов евро или 4 процента мирового годового оборота, что делает управление конфиденциальностью при отслеживании электронной почты риском на уровне предприятия. Согласно полному руководству Mailbird по законам о конфиденциальности электронной почты, регуляторы часто рассматривают отслеживание с помощью пикселей в письмах аналогично cookie-файлам, требуя информированного согласия в соответствии с Директивой о конфиденциальности и GDPR.

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

Архитектура конфиденциальности Mailbird: основа для всесторонней защиты

Понимание ограничений только блокировки пикселей ясно показывает, что эффективная конфиденциальность электронной почты требует более целостного подхода. Архитектура Mailbird обеспечивает надежную основу для противодействия многим из упомянутых выше угроз наблюдения без кликов, хотя пользователям все же необходимо понимать более широкий контекст экосистемы, в которой работает любой почтовый клиент.

Согласно документации по безопасности Mailbird, клиент функционирует исключительно как локальное приложение на компьютере пользователя, сохраняя все содержимое электронной почты только на этом устройстве, а не на серверах Mailbird. Этот архитектурный выбор значительно снижает уязвимость к атакам на стороне сервера, таким как проблема с инъекцией CSS в Roundcube, и ограничивает поверхность атаки для централизованных взломов. Независимый анализ подтвердил, что содержимое сообщений хранится на локальной машине и не сохраняется на серверах Mailbird.

Минимальный сбор данных и контроль пользователя

Политика конфиденциальности Mailbird подчеркивает, что компания собирает только минимальные, анонимизированные данные об использовании — например, метрики использования функций — для улучшения продукта, при этом пользователи могут полностью отключить отправку отчетов об использовании. Важное обновление уточнило, что Mailbird больше не отправляет имена и адреса электронной почты в систему управления лицензиями, а любые собранные данные никогда не использовались и не будут использоваться в коммерческих целях за пределами улучшения продукта.

Данная философия проектирования соответствует принципам конфиденциальности по умолчанию и решает несколько категорий рисков наблюдения, которые влияют на веб-ориентированные почтовые сервисы. Поскольку Mailbird не функционирует как вебmail-платформа и не хранит содержимое почты на своих серверах, он избегает некоторых классов уязвимостей и снижает подверженность запросам государственных органов к серверам провайдеров.

Тем не менее важно понимать, что эта архитектура автоматически не решает все проблемы. Поскольку Mailbird подключается к внешним почтовым провайдерам через стандартные протоколы, содержимое сообщений и метаданные по-прежнему проходят через инфраструктуру провайдера, а специфичные для провайдера функции, такие как кеширование изображений Gmail или Apple Mail Privacy Protection, работают независимо от клиента. Кроме того, Mailbird должен отображать HTML-письма с помощью некоторого механизма рендеринга, и в зависимости от особенностей этого механизма и его настройки он может обрабатывать HTML и CSS таким образом, что теоретически подвергает пользователей риску отслеживания через пиксели, CSS-маяки и другие загрузки внешнего контента, если это не контролируется должным образом.

Решение вопросов интеллектуальных функций и интеграции ИИ

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

Такая прозрачность относительно компромиссов между удобством и конфиденциальностью особенно ценна, поскольку почтовые клиенты все больше интегрируют возможности ИИ. Хотя Mailbird включает интеграцию ChatGPT в рамках премиум-подписки в качестве дополнительной функции, критически важно понимать, как именно эта интеграция обрабатывает данные — что именно отправляется в OpenAI, как долго они хранятся и как получают согласие пользователя — для оценки ее конфиденциальности в условиях угроз нулевого клика, таких как EchoLeak, с учетом требований конфиденциальности при отслеживании электронной почты.

Создание комплексной стратегии защиты помимо блокировки пикселей

Учитывая многогранный характер современного наблюдения за электронной почтой, эффективная защита требует многоуровневой стратегии, которая одновременно учитывает несколько векторов угроз. Хотя ни одно решение не может полностью устранить все риски, сочетание технических мер, осознанных решений и стратегического выбора инструментов может значительно снизить вероятность слежки без взаимодействия (zero-click surveillance) и обеспечить конфиденциальность при отслеживании электронной почты.

Технические меры и настройка

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

Рассмотрите использование почтовых клиентов с локальным хранением данных, а не веб-интерфейсами, так как это снижает риск некоторых видов уязвимостей и ограничивает число участников, имеющих доступ к содержимому вашей почты. Настольные клиенты, такие как Mailbird, которые хранят содержимое локально и собирают минимальную телеметрию, обеспечивают лучший уровень конфиденциальности по сравнению с веб-почтовыми сервисами, вынужденными обрабатывать все ваши сообщения на своих серверах.

Для чувствительной переписки внедряйте сквозное шифрование с использованием PGP или S/MIME. Хотя шифрование не предотвращает срабатывание трекинговых пикселей или маячков CSS после расшифровки и отображения сообщений, оно защищает конфиденциальность содержимого от наблюдения провайдера и перехвата в сети. Однако учтите, что только шифрование не решает проблему раскрытия метаданных и не препятствует обработке расшифрованного содержимого ИИ-помощниками.

Безопасность аккаунта и аутентификация

Сильная аутентификация необходима, поскольку захват аккаунта позволяет злоумышленникам обойти все меры защиты содержимого и отправлять аутентифицированные сообщения со слежкой. Включите двухфакторную аутентификацию для всех почтовых аккаунтов и, по возможности, используйте методы, устойчивые к фишингу, такие как ключи безопасности FIDO2. Согласно рекомендациям Obsidian Security по предотвращению угроз идентификации, современные фишинговые атаки все чаще обходят почтовые защиты через доставку вредоносного контента через платформы для совместной работы и личные аккаунты, что делает комплексную защиту личности обязательной.

Отслеживайте активность вашего аккаунта на предмет необычных шаблонов, таких как входы из незнакомых мест или неожиданные изменения правил переадресации. Это может указывать на компрометацию, позволяющую добывать метаданные и вести слежку даже при заблокированных трекинговых пикселях. Регулярно проверяйте и отзывайте OAuth-разрешения, так как злоумышленники часто сохраняют постоянный доступ через авторизованные приложения.

Управление ИИ и умными функциями

Будьте осознанны при выборе включаемых ИИ-функций и интеллектуальных возможностей почты. Каждая интеграция ИИ, обрабатывающая содержимое вашего почтового ящика, создаёт потенциальные каналы утечки данных — будь то через атаки с внедрением запросов, как EchoLeak, или через регулярный обмен данными с внешними ИИ-провайдерами. При оценке почтовых клиентов с ИИ-функциями задавайте вопросы:

• Какие данные отправляются в ИИ-сервисы и как долго они хранятся?
• Можно ли обработку ИИ выполнять локально или в контролируемой вами среде?
• Какие механизмы согласия и опций отказа предоставляются?
• Как клиент фильтрует вывод ИИ, чтобы предотвратить эксфильтрацию данных?

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

Выбор провайдера и осведомленность об экосистеме

Понимайте, что ваш почтовый клиент — лишь одна часть большой экосистемы. Поведения провайдеров, такие как кэширование изображений Gmail и защитa конфиденциальности Mail Privacy Protection в Apple, работают независимо от настроек клиента, влияя на то, что отправители могут узнать о вас вне зависимости от вашей локальной конфигурации. Выбирайте почтовых провайдеров с сильными обязательствами по конфиденциальности и прозрачной политикой обработки данных.

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

Часто задаваемые вопросы