Кратко

  • STARTTLS защищал одну SMTP-сессию, но письмо переживало её в очереди и переходило в новые соединения. RFC 8689 позволил сохранить с сообщением требование аутентифицированного TLS и повторять его на каждом совместимом реле.
  • Если ни один MX не подтверждает личность, защищённый канал и REQUIRETLS после рукопожатия, MTA обязан отказаться от передачи и создать защищённое уведомление о недоставке. Это не сквозное шифрование: промежуточные серверы по-прежнему видят содержание.

Сервер связывается с MX, устанавливает TLS и обнаруживает проблему сертификата. В его очереди ждут два письма одному домену. Обычное локальная политика ещё может попытаться доставить ради доступности. Второе должно остаться на месте или вернуться отправителю.

Такое различие трудно выразить одним состоянием соединения. TCP-канал и удалённый сервер одинаковы, но полномочия над двумя объектами различаются. Для одного допустимо понижение защиты, для другого оно изменило бы обещание отправителя.

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

STARTTLS защищал встречу двух серверов

RFC 2487 в 1999 году добавил STARTTLS к SMTP. Публичные MX работали в неоднородной сети. Немедленное обязательное шифрование разрушило бы совместимость, поэтому доставка оставалась приоритетом, а TLS часто был возможностью.

RFC 3207 заменил раннюю спецификацию в 2002 году. Сервер объявляет STARTTLS в EHLO, клиент посылает команду, ответ 220 начинает рукопожатие. После него обе стороны забывают знания, полученные в открытом виде, и клиент повторяет EHLO внутри защищённого канала.

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

Позже домены получателя получили внешнюю политику. RFC 7672 определил SMTP DANE через TLSA, подтверждённые DNSSEC. RFC 8461 создал MTA-STS: получаемая по HTTPS и кэшируемая политика задаёт допустимые MX и проверку сертификата. Эти механизмы выражают требование принимающего домена, но сами по себе не выделяют одно чувствительное письмо среди обычных.

Требование появилось в конверте

Опубликованный в 2019 году RFC 8689 зарегистрировал возможность EHLO REQUIRETLS. Нового глагола SMTP не появилось. Беззначный параметр был добавлен к команде конверта:

MAIL FROM:<sender@example> REQUIRETLS

Клиент не может использовать его после одного только открытого объявления. Сессия должна идти через TLS; личность MX подтверждается DNSSEC или MTA-STS; сертификат проходит доверенную цепочку или DANE; после STARTTLS сервер снова объявляет REQUIRETLS во втором EHLO.

Последнее условие связывает обещание с тем узлом, который действительно завершил TLS. Строку до шифрования мог убрать или подменить активный посредник.

Приняв сообщение, сервер помечает его для обработки REQUIRETLS. Стандарт не диктует поле базы данных или формат файла очереди. Он требует поведения: при следующей отправке MTA заново строит доказательства и повторяет параметр в новом MAIL FROM.

Локальный псевдоним может размножить адресатов, но не выбор безопасности. Все получившиеся экземпляры должны сохранить одну и ту же метку.

Четыре проверки имели разные значения

Следующий узел выбирается по правилам RFC 5321. Если MX-ответ не аутентифицирован DNSSEC, имя ограничивает MTA-STS. Клиент создаёт TLS, проверяет сертификат и затем ищет REQUIRETLS в защищённом EHLO.

Шифрование скрывает байты от пассивного наблюдателя. Сертификат или DANE связывает ключ с личностью. DNSSEC или MTA-STS определяет, кто вправе представлять домен. Финальное объявление показывает, что следующий хранитель способен сохранить условие и передать его дальше.

Поле «TLS использован» смешивает эти ответы. Зашифрованное соединение с подменённым MX неверно. Правильный сертификат на сервере без REQUIRETLS не сохраняет обязанность. Увиденная только до рукопожатия возможность не доказывает защищённого согласия.

Перебор MX не превращался в поиск любого пути

Если первый MX не соответствует, клиент завершает попытку и проверяет остальные. Обычные письма он может доставить тому же серверу. REQUIRETLS относится к сообщению, а не объявляет весь домен навсегда небезопасным.

Когда список исчерпан, передавать отмеченное письмо домену запрещено. RFC 8689 рекомендует статус 5.7.30, если сервер не поддерживает REQUIRETLS, и 5.7.10, если нужная TLS-сессия не установлена. Затем создаётся уведомление о недоставке к исходному возвратному пути.

Так ошибка получила противоположное действие. При возможностном TLS неудача могла разрешить более слабую передачу ради доступности. При REQUIRETLS она отнимает право отправлять. Явный отказ лучше сохраняет исходное решение, чем успешная доставка на новых условиях.

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

Уведомление о неудаче тоже могло раскрыть письмо

Уведомление о недоставке часто цитирует заголовки оригинала: отправителя, получателей, тему и маршрутные данные. Если прямой путь требует защиты, а диагностика возвращается открыто, информация утекает с другой стороны.

Поэтому любое уведомление от REQUIRETLS-письма само должно использовать REQUIRETLS, даже когда причина не связана с TLS. Оно обрабатывается так, словно указан DSN RET=HDRS; конфликтующий RET=FULL игнорируется, чтобы не возвращать полное тело.

У уведомления пустой возвратный путь, иначе его сбой породил бы бесконечную цепь уведомлений. Обратная дорога может не поддерживать то же, что прямая. RFC предупреждает о потере защищённой диагностики и особо обрабатывает сообщение с пустым возвратным путём, когда следующий сервер не объявляет REQUIRETLS.

Отсутствие уведомления не доказывает доставку. Исходное письмо могло быть правильно остановлено, а его объяснение — не найти защищённого пути обратно.

Заголовок TLS-Required: No не требовал открытой передачи

RFC 8689 определил и отрицательный заголовок. TLS-Required: No просит отправляющий MTA не позволять политике DANE или MTA-STS адресата блокировать письмо. Так можно сообщить администратору о сломанном сертификате, не дав этому сертификату закрыть само предупреждение.

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

Если в конверте присутствует REQUIRETLS, параметр имеет приоритет, а заголовок игнорируется для обработки. Несколько таких заголовков запрещены. Содержимое не может ослабить обязательство, принятое в защищённом конверте.

Посредник мог стать новым отправителем

Обычный сервер пересылки передаёт тот же объект. Список рассылки, Sieve, перенаправитель или автоответчик иногда создаёт новое письмо. Меняются адресаты, заголовки и ответственность. RFC просит переносить исходный выбор настолько, насколько это возможно.

Ограничение существенно. Список может раскрыться на домены с разными возможностями; сохранение REQUIRETLS закроет часть аудитории. Пользовательский фильтр может вовсе не видеть SMTP-метку.

Здесь техническая граница становится организационной. Остался ли посредник транспортом чужого сообщения или стал автором нового? Протокол обязывает честный сервер пересылки, но не может автоматически решить вопрос новой авторской воли.

Промежуточные MTA оставались доверенными читателями

REQUIRETLS защищает отдельные переходы, а не содержание от конца до конца. Каждый MTA завершает TLS, видит открытый текст и начинает новую сессию. Злонамеренный сервер пересылки способен ложно объявить поддержку или удалить метку. RFC исключает его из модели угроз, потому что ему уже доверили содержание.

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

Реестр SMTP IANA подтверждает назначение имени REQUIRETLS и ссылку на стандарт. Он не измеряет распространение, трафик или соблюдение.

Историческая идея — память полномочия. Соединения исчезают, письма остаются. REQUIRETLS позволил сохранить с объектом правило, восстановить его при следующем контакте и прекратить передачу, когда оно стало невыполнимым. Недоставка превратилась в один из способов не изменить решение отправителя.