max-errors-per-connection

<domain>Хаб задаёт сам

Сколько ошибок по получателям обрывает соединение
в конфигурации это строкаmax-errors-per-connection unlimitedвнутри блока <domain>
Когда вежливее положить трубку

Обрывает соединение после того, как на нём накопилось заданное число ошибок уровня получателя — отказов в ответ на RCPT TO. Считаются именно они: ошибки соединения и ответы на DATA к этому счётчику отношения не имеют.

Что видит приёмник. Соединение, на котором один отказ за другим, — это ровно тот рисунок, по которому распознают перебор адресов. Даже когда никакого перебора нет и дело в старом списке, поведение выглядит одинаково, а отношение приёмника портится одинаково быстро.

Обрыв ничего не чинит. Плохие адреса никуда не денутся: MTA откроет новое соединение и продолжит с того же места. Директива — это вежливость, а не лечение. Лечение — suppression-lists и чистка списка; здесь только смягчение того, как выглядит проблема снаружи.

Умолчание — unlimited. Соединение по числу ошибок не обрывается никогда, сколько бы их ни накопилось.

Главная ловушка. Слишком низкое значение превращает одну проблему в другую. При max-errors-per-connection 2 очередь с заметной долей несуществующих адресов будет переоткрывать соединения почти на каждое письмо — а частые подключения приёмники считают внимательнее, чем отказы. Вместо «много ошибок на одном соединении» получится «шквал коротких подключений», и это хуже.
Что делает Хаб. Пишет 10 — в шаблоне политик получателей, в каждом из пятнадцати блоков: у четырнадцати крупных почтовиков и в общем <domain *>. Причина названа там же в комментарии: не доводить соединение до ошибки «слишком долго без команды DATA».

Рядом Хаб пишет и соседа по смыслу — max-msg-per-connection со значением от выбранного темпа (20 · 50 · 100). Границ у соединения получается две: по числу писем и по числу ошибок, и срабатывает та, до которой дошли раньше.

Чистотой списка Хаб при этом занимается на своей стороне: жёсткие отказы уходят в чёрный список, и до MTA адрес во второй раз не доезжает. Порог в десять ошибок — страховка на случай списка, пришедшего извне.

Рекомендуемые значения

Не ниже десятка. Смысл в том, чтобы обрывать соединение при явно плохом списке, а не при обычной доле недействительных адресов. Десять ошибок подряд — это уже не случайность; две — вполне.

Считайте от доли брака. Если на сотню писем приходится пять отказов по получателям, то при двадцати письмах на соединение до порога в десять дело обычно не дойдёт вовсе — и это правильно: директива должна срабатывать редко.

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

Порядок величины и правило «не ниже десятка» — наши. Из руководства здесь умолчание unlimited и то, что считаются ошибки уровня получателя.
Пример в конфигурации
# обрывать соединение при явно плохом списке, но не при обычном браке
<domain hotmail.com>
    max-msg-per-connection 50
    max-errors-per-connection 10</domain>
Два предела на одно соединение: по письмам и по ошибкам. Сработает тот, до которого дойдёт первым, — на чистом списке это всегда первый.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Ставят единицы, чтобы «быть вежливее»

наш опыт

Чем чреватоПри двух-трёх ошибках на обрыв очередь с обычной долей брака начинает переоткрывать соединения почти на каждое письмо. Приёмник видит шквал коротких подключений — картину, на которую он реагирует резче, чем на отказы по получателям.
Как заметитьЧисло подключений сопоставимо с числом писем, появляются ответы про слишком частые соединения.
Как правильноПоднять порог до десятка и выше, а с плохим списком разбираться подавлением, а не обрывами.

Ждут, что обрыв уменьшит число отказов

§ 3.3.10.1

Чем чреватоДиректива обрывает соединение, но не трогает очередь: те же адреса будут отданы в следующее соединение и дадут те же отказы. Общее число ошибок не изменится — изменится только их распределение по соединениям.
Как заметитьДоля отказов по получателям та же, что и до правки.
Как правильноУбирать несуществующие адреса — suppression-lists и чистка списка. Эта директива про то, как проблема выглядит, а не про саму проблему.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-errors-per-connection <integer>
Значения
целое число ошибок или unlimited
Умолчание
unlimited § 3.3.10.1
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Подхватывается по pmta reload, перезапуск не нужен; на уже открытые соединения новое значение не влияет.
Как проверить на узле
Отдельного счётчика обрывов нет. Косвенный признак — соотношение числа соединений и писем, плюс сами ошибки получателей в учёте:
grep -rn max-errors-per-connection /etc/pmta/
pmtaacctfind --output csv[type,dsnStatus,rcpt] /var/log/pmta/acct-*.csv
Если отказов по получателям много, а соединений с приёмником заметно больше, чем писем делённых на max-msg-per-connection, — значит обрывы происходят по этой директиве. Отдельно обрывы Хаб не считает.
В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Настроить темп под провайдера