Коротко. «Зашифрованная почта» может означать четыре разные вещи. Шифрование в пути (TLS) защищает письмо по дороге; шифрование на диске защищает диски почтового сервиса; нулевой доступ не даёт сервису прочитать хранимую почту; при сквозном шифровании письмо могут прочитать только отправитель и получатели. Разница сводится к одному вопросу: у кого ключи.
Четыре вида шифрования почты
| У кого ключ | От чего защищает | Кто всё равно может прочитать | |
|---|---|---|---|
| В пути (TLS) | у серверов на двух концах каждого соединения | от подслушивания сети, например в публичном Wi-Fi | каждый почтовый сервер по дороге, включая ваш сервис |
| На диске | у почтового сервиса | от кражи диска | почтовый сервис и тот, кто может заставить его выдать почту |
| Нулевой доступ | у вас | от чтения хранимой почты самим сервисом | почтовый сервис в момент, когда письмо приходит с другого сервиса или уходит на другой сервис без сквозного шифрования |
| Сквозное | у отправителя и получателей | от всех по дороге, включая почтовые сервисы | отправитель и получатели |
В пути: TLS
- Между вашей программой и почтовым сервисом. Веб-почта работает по HTTPS, а почтовые программы подключаются по IMAP, POP и SMTP с TLS. IETF рекомендует TLS для таких подключений с 2018 года [1].
- Между почтовыми серверами. Серверы шифруют соединения друг с другом через STARTTLS [2]. Это шифрование «по возможности»: если другой сервер не предлагает TLS или злоумышленник по дороге вырезает это предложение, письмо может пойти незашифрованным. MTA-STS [3] и DANE [4] позволяют домену требовать TLS для входящей почты.
- На каждом сервере письмо расшифровывается. TLS защищает дорогу, но не остановки: сами серверы письмо видят [5].
На диске
Почтовый сервис шифрует свои диски или базу данных собственными ключами. Это защищает от кражи диска или резервной копии. Но сам сервис может расшифровать всё, а значит, и тот, кто заставит его выдать почту.
Нулевой доступ
Хранимая почта зашифрована ключом, которого у сервиса нет, поэтому прочитать хранимое он не может. Письма с других сервисов всё равно приходят незашифрованными и шифруются при приёме, и в этот момент сервис их видит. То же при отправке на другой сервис без сквозного шифрования: письмо уходит открытым. Подробнее в статье «Что такое нулевой доступ».
Сквозное шифрование
Письмо шифруется на устройстве отправителя и расшифровывается только на устройствах получателей [5]. Внутри одного сервиса это может происходить автоматически, а между разными сервисами нужен OpenPGP или S/MIME. В веб-версии код приходит с сервера при каждом входе, поэтому и здесь приходится доверять сервису; в приложениях меньше. Подробнее в статьях «Что такое сквозное шифрование» и «Как отправить зашифрованное письмо».
Что остаётся видно в любом случае
- Адреса и время. Без них письмо не доставить. Подробнее в статье «Метаданные письма».
- Часто тема. Классические OpenPGP и S/MIME её не шифруют. Стандарт защиты заголовков вышел в 2025 году [6], но поддерживают его ещё не все программы.
Как понять, что сервис имеет в виду под «шифрованием»
Задайте четыре вопроса:
- Где шифруется: в пути, на диске, с нулевым доступом или сквозным образом?
- У кого ключи: у сервиса или у вас?
- Что происходит с письмами с других сервисов, когда они приходят?
- Что именно шифруется: только текст или ещё тема, отправители и получатели?
Подробный список вопросов в статье «Какая почта самая защищённая».
Шифрование и Methmail
Письма между пользователями Methmail будут зашифрованы сквозным шифрованием: прочитать их смогут только отправитель и получатели. Хранимые письма будут зашифрованы ключами, которых у нас нет. В момент приёма письмо с другого сервиса будет проходить через наш сервер незашифрованным: так устроена обычная электронная почта. Письмо на другой сервис без PGP до доставки (до 48 часов) будет ждать в очереди отправки на томе, зашифрованном нашим ключом. Границы этой защиты описаны в разделе «Чего Methmail не сможет».
Источники
- RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. IETF, январь 2018. https://www.rfc-editor.org/rfc/rfc8314
- RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. IETF, февраль 2002. https://www.rfc-editor.org/rfc/rfc3207
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS). IETF, сентябрь 2018. https://www.rfc-editor.org/rfc/rfc8461
- RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). IETF, октябрь 2015. https://www.rfc-editor.org/rfc/rfc7672
- EFF, Surveillance Self-Defense: What Should I Know About Encryption? (последняя проверка EFF в январе 2025). https://ssd.eff.org/module/what-should-i-know-about-encryption
- RFC 9788: Header Protection for Cryptographically Protected Email. IETF, август 2025. https://www.rfc-editor.org/rfc/rfc9788