Кратко

  • IETF назначила переход почтовых служб на 11 сентября 2026 года, предупредив о задержке до 60 минут и временной недоступности веб-интерфейса Mailman. Переход ещё не состоялся: это план и ожидание, а не измеренный результат.
  • После ответа нового отправителя postconfirm может вернуть сохранённое письмо в почтовую систему. Это доказывает выполнение локального условия, но не приём списком, правильность переписывания, подпись, DANE-транспорт или поступление подписчику.

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

Объявление IETF от 28 августа назначает работы на 22:00 UTC 11 сентября для доменов IETF, IAB, IRTF и RFC Editor. Веб-интерфейс Mailman3 должен остановиться, архив и IMAP — остаться доступными. Час задержки, улучшение bounce-обработки и устранение возможности открытого реле остаются целями до появления эксплуатационных данных.

У каждого этапа своя ответственность

Функции разнесены по контейнерам Kubernetes и связаны через milter; исходящую почту передают несколько виртуальных машин. Postconfirm, Rspamd, переписывание, DKIM, DANE и обработка возвратов получают отдельные наблюдаемые границы.

Репозиторий postconfirm описывает хранение неизвестных писем во время проверки и повторный ввод после ответа. Он различает reject и discard: во втором случае клиент может увидеть успех, хотя письмо выброшено. Значит, «SMTP OK» без производителя, действия и отпечатка ничего не доказывает о цепочке.

Нужны время хранения, срок, состояние проверки, попытка освобождения и подтверждение повторного ввода с одним отпечатком. Падение длины очереди может означать продвижение, истечение срока, дубликат или исчезновение.

Переписанный адрес — новый операционный факт

Список рассылает с инфраструктуры, которой может не быть в SPF исходного домена. Новый сервис проверяет SPF и DMARC, при необходимости переписывает Envelope/Header From и подписывает DKIM.

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

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

Подготовленный сертификат ещё не виден удалённому MTA

Схема current + next 3 1 1 должна сохранять DANE-совместимый сертификат при ротации. В danebot видны отдельные состояния current и next. Это внутренняя готовность.

DANE для SMTP даёт иной факт: отправляющий MTA проверяет MX/TLSA через DNSSEC и аутентифицирует следующий TLS-узел. RFC не защищает всю почту и зависит от DNSSEC против downgrade. Запланированный ключ, видимый TLSA, реально поданный сертификат и законченный handshake — четыре разных свидетельства.

Приём начинает ограниченное обязательство

По SMTP, ответивший 250 OK после DATA обязан доставить или переслать. Это не чтение. RFC 3464 допускает, что delivered означает передачу экспандеру списка; relayed и expanded имеют иные границы.

Входной MTA, postconfirm, Mailman, переписыватель, подписант, исходящий relay, принимающий MTA и контрольный ящик должны говорить отдельно. Отсутствие bounce не доказывает доставку, а здоровый pod — движение следующей очереди.

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

Переход доказан, когда квитанции всех этапов сходятся. Успешная проверка открывает лишь первую дверь.

Источники