Кратко

  • 11 сентября IETF объявила перенос завершённым. Через две недели исполнительный директор перечислил восемь исправленных ошибок — от писем, отправленных на ручную проверку, до массовых сообщений, отброшенных без предупреждения, — и оставил две темы в работе.
  • Главный риск остался в автоматической обработке возвратов: старый накопленный хвост дал сомнительные сигналы, и когда система стала отключать подписчиков, IETF остановила её и восстановила затронутые адреса.

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

Это отметка о переключении, а не отчёт о работе сервиса.

Операционный отчёт появился 25 сентября. Исполнительный директор IETF Jay Daley заявил, что большинство проблем решено, и описал восемь исправленных и две остававшиеся в работе. Он также рассказал, что проект новой инфраструктуры заказали три года назад, но после неоднократных проблем завершение поручили новому подрядчику. Один ключевой компонент первоначальной работы не переписывали; связанные с ним проблемы не обнаружили до запуска. «Это была наша ошибка», — написал Daley.

Речь не о единственном громком сбое. Сломались небольшие правила на стыках между списками рассылки и реальными отправителями. Подтверждённый адрес, который писал в список, не подписавшись на него, отсутствовал в глобальном списке разрешённых адресов — письмо уходило на модерацию. Сообщения Precedence: Bulk отбрасывались без уведомления; прежде всего это затронуло письма IANA. Неправильно обрабатывались адреса BATV. Уже подтверждённые адреса с заглавными буквами считались новыми и должны были подтверждаться повторно. Правила для необычных отправителей стали недоступны. Некоторые имена From в Outlook разделялись на части. Уведомления Postorius отправлялись с временного адреса, потому что поле владельца сайта было пустым. Переписывание адресов для DMARC тоже давало сбой при некоторых количествах получателей.

Исполнительный директор сообщил, что эти восемь проблем исправлены. Это число перечисленных дефектов, а не всех не доставленных писем или затронутых участников. Знаменателей в обновлении нет.

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

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

То же обновление описывает ещё один сюрприз с производительностью: режим VERP, включённый в Mailman по умолчанию, увеличивал время обработки почты на четыре-пять порядков. На время расследования VERP отключили. В сообщении нет исходного времени, профиля нагрузки или абсолютной задержки. Новый фильтр Rspamd тоже оставался на настройке: слишком много спама проходило.

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

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

Публичный отчёт показывает контрольное решение, но не его цену. В нём нет количества повторно активированных адресов, доли неверных возвратов, продолжительности остановки, исходного времени VERP или даты завершения настройки Rspamd. Эти данные изменили бы оценку восстановления. Пока твёрдый вывод уже: IETF остановила отключение подписчиков, когда доказательствам из возвратов нельзя было доверять, и публично описала исправление.

Источники