Кратко

  • id в TXT-записи MTA-STS сообщает отправителю, что политику следует загрузить заново. Он не содержит и не подписывает её, не доказывает загрузку всеми отправителями и не отзывает одновременно старые кэши. Для каждого поддерживающего отправителя действуют конкретные байты, полученные по аутентифицированному HTTPS, с известным временем загрузки и неистёкшим max_age.
  • Воспроизводимое решение связывает домен политики, проверку PKIX узла политики, точные байты, происхождение кэша, обход MX, STARTTLS, сертификат, очередь, повторные попытки и итог. enforce — транспортное правило одного отправляющего MTA, а не доказательство доставки, сквозной секретности, личности владельца ящика или деловых полномочий.

Два отправителя вправе принять разные решения

Начальная сцена — искусственный проверочный пример, а не описание происшествия. Получатель считает новую политику текущей, потому что изменил TXT и веб-сервер. Отправитель A видит новый ID, аутентифицирует mta-sts.<домен>, загружает файл и начинает новый срок кэша. В его списке уже есть резервный MX.

Обновление отправителя B завершается ошибкой. RFC 8461 не требует отбрасывать ещё действующую политику только из-за недоступности проверки в реальном времени. Неистёкший кэш нужно применить. В нём нового резервного MX нет, поэтому B признаёт этот узел неподходящим и откладывает доставку.

Текущих DNS и веб-страницы получателя недостаточно для аудита обоих решений. Нужен снимок состояния отправителя во время попытки. Первый вопрос должен звучать не «какова политика сейчас?», а «какие аутентифицированные байты этот отправитель имел право применить тогда?».

ID сообщает об изменении, но не является политикой

TXT по адресу _mta-sts.<домен-политики> содержит v=STSv1 и id. Изменение ID побуждает к новой загрузке, однако это не хэш HTTPS-файла, не перечень MX и не глобальный отзыв. Разные отправители замечают DNS и успешно получают HTTPS-объект в разное время.

Если кэша нет, корректный TXT и неудачная загрузка политики заставляют отправителя вести себя так, будто MTA-STS не внедрён. Если действующий кэш есть, та же ошибка оставляет старое правило в силе. Поэтому события «увиден новый ID» и «применена новая политика» необходимо хранить раздельно.

До окончательного отказа при enforce отправитель обязан проверить обновление ID. В остальных случаях ошибка остаётся временной и сообщение повторяется по правилам SMTP. Так уменьшается риск возврата по правилу, которое получатель уже заменил.

HTTPS аутентифицирует определённый набор байтов

Файл находится на узле политики mta-sts.<домен-политики> по фиксированному пути /.well-known/mta-sts.txt. Сертификат должен соответствовать этому узлу, быть действительным и строить цепочку до корня, которому доверяет отправитель. Политика содержит version, mode, записи mx и max_age; в режиме none MX может отсутствовать.

Для аудита фразы «HTTPS сработал» мало. Нужны URL, время, статус, тип содержимого, окончательные байты, цепочка сертификатов, результат проверки имени и хэш разобранного тела. Изменение тела при прежнем ID или нового ID без изменения тела — наблюдаемое операционное расхождение.

max_age создаёт несколько допустимых настоящих

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

Корректное отключение учитывает это перекрытие. Оператор публикует аутентифицированную политику none с коротким max_age, меняет ID и ждёт истечения самого длинного старого кэша, прежде чем удалить TXT и HTTPS. Если сначала убрать пути восстановления, у отправителей останется старый enforce, который уже невозможно заменить.

Проверяется MX в конкретном соединении

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

Выбранный узел обязан предложить STARTTLS и представить действующий PKIX-сертификат с подходящим DNS-ID и доверенной цепочкой. SNI при загрузке HTTPS содержит имя узла политики, а SNI в SMTP — имя выбранного MX. Эти доказательства относятся к разным проверкам.

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

Очередь превращает правило в последствие

Политика действует через состояние SMTP-очереди. Следует сохранять ID очереди, выбранный MX, временную или окончательную классификацию, график повторов, проверку нового ID перед окончательным отказом и финальный статус. Без временной линии отчёт описывает симптомы, а не причину.

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

TLSRPT — агрегированное свидетельство

Политика _smtp._tls из RFC 8460 запрашивает отчёты об обнаруженных политиках, суммарных количествах и примерах ошибок. Они помогают отличать неисправность от вмешательства и сравнивать регионы или реализации. Документация Microsoft и Google подтверждает заявленные рабочие поверхности их продуктов, но не универсальное поведение всех MTA.

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

DANE и REQUIRETLS очерчивают соседние границы

MTA-STS аутентифицирует политику через HTTPS и PKIX и не требует DNSSEC, поэтому первоначальное обнаружение можно подавить. DANE задаёт иную границу понижения защиты с помощью DNSSEC. Неудачную проверку DANE нельзя отменить более удобным результатом MTA-STS.

REQUIRETLS из RFC 8689 переносит намерение автора отдельного сообщения через поддерживающие ретрансляторы. MTA-STS выражает правило домена получателя для поддерживающих отправителей. Доменная политика, намерение сообщения и доказательство соединения — разные объекты полномочий.

Решение, которое можно воспроизвести

Минимальная запись связывает домен политики; резолвер, время, байты TXT, TTL, DNSSEC и ID; URL, время, байты и сертификат HTTPS; разобранные версию, режим, MX, max_age, хэш и срок; хэш и срок старого кэша; RRset и порядок MX; узел, адрес, SNI, STARTTLS и PKIX; очередь, повторы и исход; применимый результат DANE; свидетельство TLSRPT.

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

Источники