Кратко

  • Раздел 6.5 draft-ietf-emailcore-as-30 говорит, что принимающая реализация SMTP должна уметь получать почту с конфиденциальностью передачи и без неё. Выбор действий отправителя и получателя в конкретной ситуации отнесён к местной политике. Документ остаётся Internet-Draft на стадии «AD Followup», а не опубликованным RFC.
  • В версии 29 получателю предписывалось не требовать конфиденциальности канала от отправителя. Сентябрьская дискуссия касается смысла новой нормы о технической способности и риска смешать её с обязанностью пропускать каждое открытое соединение. Итогового решения IESG она не подтверждает.

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

В тридцатой редакции заявления EMAILCORE о применимости пункт 6.5 сначала требует от SMTP-отправителя использовать конфиденциальную передачу, если она доступна и принимается адресатом. Затем получателю предписывается способность принять почту как с защитой канала, так и без неё. Следующая фраза относит решение по отдельному случаю к местной политике. В предыдущей редакции формула была иной: получатель не должен требовать от отправителя конфиденциальности при передаче. Журнал изменений прямо связывает переработку шестого раздела с проверкой IESG.

Речь идёт о смене адресата и предмета нормативной фразы, а не о появлении нового криптографического механизма.

Состояние процедуры существенно для понимания новости. Datatracker по-прежнему показывает редакцию 30 как действующий проект со статусом «AD Followup». В бюллетене видны позиции DISCUSS, некоторые из них были внесены по редакции 29 и относятся к разным вопросам. 18 сентября редактор John Klensin в ответе Roman Danyliw отделил собственные замечания от позиции рабочей группы, которая ещё не проверила эту часть ответа. 28 сентября Eric Rescorla предложил убрать нормативное требование, если оно ничего не добавляет; Rob Sayre подчеркнул различие между свойствами программы и решением того, кто её эксплуатирует, ожидая более частого требования TLS.

Это аргументы конкретных участников, не принятый итог IETF и не исследование работающих серверов.

Действующий RFC 3207 задаёт другую, более узкую границу. Публично указанному SMTP-серверу он не позволяет требовать STARTTLS для локальной доставки, а серверу без публичной ссылки позволяет сделать согласование обязательным. Важно сохранить и вид механизма, и область действия нормы. Она не означает, что любая почтовая служба обязана без условий впускать незащищённый трафик. EMAILCORE обсуждает базовую способность принимающей реализации, то есть ещё один слой, а не замену уже опубликованного правила.

RFC 8689 с REQUIRETLS относится к намерению отправителя отдельного сообщения. Для поддерживающих его промежуточных узлов такое сообщение может потребовать защиты и завершиться неудачей, вместо того чтобы уйти открытым способом. BTW ранее описывал именно этот путь сообщения. Он не отвечает на вопрос, какой набор способов приёма обязан сохранить универсальный серверный продукт. Требование сообщения, правило публичного MX, возможность программы и политика подключения должны проверяться отдельно.

В дальнейшем эта формулировка может попасть в проверки совместимости, документацию поставщиков и закупочные условия. Если «должен уметь» прочитать как «обязан всегда разрешать», ответственному администратору могут ошибочно приписать чужую политику. Если же функция полностью исчезнет из продукта, исключительный сценарий совместимости потребует новой версии вместо разрешённой настройки. Проект не оценивает частоту таких случаев и не доказывает реального сбоя доставки из-за редакции 30. Открытым остаётся вопрос: на каком уровне закреплять общее средство взаимодействия, не превращая его в распоряжение для каждого оператора.

Источники