Соединение оборвалось со стороны приёмника. Руководство называет две причины, и вторая куда содержательнее.
Первая — сервер выключили или он упал. Обычная неполадка, проходит сама.
Вторая — приёмник закрыл соединение в ответ на содержимое письма. Это крайняя мера: вместо того чтобы отказать словами, он просто уходит. Так ведут себя фильтры, которым нечего или незачем объяснять.
Отличить их помогает избирательность. Обрыв на всех письмах подряд — это про сервер. Обрыв на части писем при нормальной доставке остальных — это про содержимое.
⚠️ И это как раз тот случай, где категория вводит в заблуждение: обрыв из-за содержимого выглядит сетевой неполадкой, а лечится правкой письма.
Косвенный признак у нас есть: если обрывы кучкуются вокруг одной рассылки, а прочие идут нормально, дело в её содержимом.
Как отличить:
| Наблюдение | Причина |
|---|---|
| рвутся все соединения к приёмнику | сервер выключен или упал |
| рвётся часть, привязанная к одной рассылке | содержимое письма |
| обрывы начались после смены шаблона | почти наверняка содержимое |
Про содержимое искать не в сети, а в письме. Ссылки, вложения, домены в тексте — то, на что смотрит фильтр.
Разговор с приёмником не поможет: он ничего не сказал, и объяснять ему нечего.
# признак — избирательность, а не сам обрыв pmta show queues --errors example.com
1 связь
3 статьи
◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Сторож, который перезапускает MTAПрисматривает за MTA и после падения поднимает его сам, отправляя отчёт о падении на адрес ответственного.◇Как складывается политика для приёмникаНастройки собираются от самого общего образца к самому точному; порядок блоков в файле не значит ничего.