Кратко

  • IETF назначил переход почтовых служб ietf.org, iab.org, irtf.org и rfc-editor.org на 11 сентября 2026 года, 22:00 UTC. Доставка может задержаться до 60 минут; веб-интерфейс Mailman3 будет недоступен, а архив и IMAP должны продолжить работу.
  • Принятие, сохранение, проверка, выпуск, переписывание адреса, DKIM-подпись, DANE, исходящая очередь и архив принадлежат разным компонентам. Ни один промежуточный успех не равен сквозной доставке.

Объявление IETF раскрывает устройство перехода: отдельный контейнер на каждую функцию, Kubernetes в выделенном кластере и milter между обработчиками. Rspamd заменяет SpamAssassin, появляется новый адресный rewriter и обновляется управление сертификатами DANE. Исходящая почта — исключение: её передают нескольким виртуальным машинам в сетях с хорошей репутацией.

Это несколько плоскостей, а не один сервис. Архив может отвечать, пока новые письма удерживаются. Веб-управление Mailman3 может исчезнуть при доступном IMAP. Кластер может быть зелёным, когда очередь на одной исходящей VM растёт.

Событие 2026 года не повторяет окно 2024-го

В BTW уже опубликован материал о почтовом окне IETF в августе 2024 года, переводе основного отправления на Amazon SES, подготовке SPF и риске невосстановимых писем. Он остаётся отдельной записью.

В феврале 2025 года IETF писал, что базовая обработка тогда почти не изменилась, а более глубокое использование облачных технологий последует позже. В 2026 году описан именно этот следующий этап: новый postconfirm, новая фильтрация, преобразование адресов, DANE, независимые функции и отдельный выход.

Новый вопрос — не длительность остановки, а передача контроля над рабочей копией сообщения.

Принять, сохранить и выпустить — разные действия

Публичный postconfirm проверяет адрес назначения и состояние отправителя. Если требуется challenge, он сохраняет исходное письмо и посылает подтверждение. Правильный ответ переводит адрес в accept и повторно вводит сохранённый объект в почтовую систему.

Состояния различают unknown, confirming, accepted, rejected, discarded и expired. Reject сообщает SMTP-клиенту об отказе. Discard способен сообщить успех и прекратить доставку. В challenge-пути копия сохраняется до завершения исходной обработки.

Значит, нужны три независимых свидетельства: ответ на входе, реально сохранённые байты и последующая reinjection либо purge. 2xx не является записью архива. Изменение строки approval не доказывает, что письмо пошло дальше. Отсутствие публикации не показывает, было ли истечение, удаление, discard или ранний сбой.

Параметры по умолчанию в репозитории не являются боевой конфигурацией. Срок хранения, топология PostgreSQL, commit и график очистки не опубликованы. Их нужно подтвердить после cutover.

Проверка имеет узкий смысл. В схеме IETF она связывает контроль почтового ящика с согласием Note Well. Она не устанавливает юридическую личность, полномочия организации, истинность текста или право говорить за других.

Переписанный From создаёт транспортную роль, а не нового автора

Список отправляет сообщение со своих адресов. SPF домена автора может их не разрешать, а изменения списка могут разрушить исходный DKIM. Строгий DMARC тогда блокирует легитимный пост.

Новый milter проверяет SPF и DMARC. Если исходный SPF не включает IETF, envelope From может стать обратимым адресом в домене dmarc.* IETF. При quarantine или reject также меняется видимый header From. Затем сообщение подписывается DKIM соответствующего домена IETF.

RFC 9989 признаёт такие обходы устойчивой практикой списков. Они создают выровненную идентичность повторного отправителя, но не передают авторство. RFC 6376 связывает подписывающий домен с подписанными частями; DKIM не доказывает человека, challenge или доставку.

След должен хранить исходный адрес, переписанные envelope/header, применённую политику, версию и свежесть mapping, DKIM domain и selector. Иначе «IETF переслал» превращается в «IETF написал».

Для DANE доверие зависит от времени DNS

Объявление говорит о схеме текущего и следующих сертификатов. RFC 7672 требует опубликовать перекрывающиеся TLSA до смены сертификата и дождаться истечения старых DNS-кэшей. При обязательном DANE несоответствие должно задержать почту, а не незаметно понизить защиту.

Поэтому отчёт о выпущенном сертификате неполон. Нужны TLSA, DNSSEC, TTL, сертификат каждого endpoint, внешний handshake и возраст очереди. Сентябрьский результат ещё не существует, а универсальное применение DANE внешними отправителями не заявлено.

Модульность умножает границы состояния

Независимое масштабирование полезно, но replicas во время rollout могут иметь разные конфигурации. Kubernetes возвращает процесс, но не обязательно контекст его последнего решения. Approval DB, обратимые mappings и ключи живут по разным часам.

Исходящие VM добавляют очередь и IP-репутацию. Кластер может закончить фильтрацию, а удалённый домен ответить defer. RFC 5321 описывает SMTP как поэтапный store-and-forward, не как атомарный commit до читателя.

Заявленная цель убрать возможность open relay соответствует RFC 2505, но её надо проверять свежими, истёкшими, отсутствующими и поддельными mappings. Намерение не является отрицательным тестом.

Архив и IMAP — свидетели, не универсальная квитанция. Письмо под challenge ещё не опубликовано; архивный пост может не дойти части подписчиков. Нужна сквозная корреляция входного ответа, хэша копии, challenge, release/purge, rewrite, подписи, list expansion, архива, очереди, удалённого ответа и bounce. Каждый хэш должен называть этап преобразования.

Приоритет работающего кода требует фактического пути, а не плана. Практический контроль данных находится в копиях, БД, логах, ключах, DNS, pods, VM и архиве. Минимальная спецификация и локальные решения задают границу: общие протоколы обеспечивают смысл интерфейса; каждый оператор выбирает реализацию и отвечает за свой переход.

Модульная система снижает риск только тогда, когда её раздельные свидетельства можно собрать в одну историю сообщения.