Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.66

smtp-553-means-invalid-mailbox

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

Считать ли голый ответ 553 признаком несуществующего ящика
в конфигурации это строкаsmtp-553-means-invalid-mailbox yesвнутри блока <domain>
Догадка за приёмника, который не договорил

Приёмник отвечает на команду RCPT кодом 553 и не даёт уточнённого кода — того самого, что выглядит как 5.1.1. Кода мало: 553 в почтовых правилах означает «такое имя ящика не принимается», а за этой формулировкой прячутся и несуществующий адрес, и запрещённый отправитель, и просто внутренняя политика приёмника.

Эта строка решает, что записать в таком случае. Вендорское умолчание yes трактует голый 553 как 5.1.1 — ящика не существует. При no ответ остаётся неразобранным и попадает в общую категорию.

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

Главная ловушка. От догадки зависит категория отказа, а от неё — попадёт ли адрес в чёрный список. «Ящика нет» — окончательный отказ, адрес выбывает навсегда. «Отправитель не принят» — отказ о нас, а не о получателе, и вычёркивать его адрес не за что. Приёмник, отвечающий голым 553 на политику отправителя, с этой строкой вычёркивает вашу базу вашими же руками.
Что делает Хаб. В шаблоне политик приёмников yes стоит во всех пятнадцати блоках: у четырнадцати известных почтовиков — у них голый 553 действительно означает отсутствующий ящик — и в общем <domain *>. Именно здесь решается, будет отказ жёстким или мягким, а Хаб вычёркивает адрес только по жёстким — так что цена неверной догадки ложится прямо на базу.
Рекомендуемые значения

Известным почтовикам — yes. Их ответы предсказуемы, и голый 553 у них про адрес, а не про отправителя.

Незнакомым приёмникам — осторожнее. Старые и самодельные почтовые серверы дают 553 по любому поводу и уточнённых кодов не выдают вовсе. Догадка на таком приёмнике ошибается чаще, чем угадывает.

Разбирайте текст ответа рядом. Что именно приёмник имел в виду, часто написано словами после кода. Разбор через bounce-category-patterns точнее любой догадки по числу.

Разделение по знакомству с приёмником и совет разбирать текст — наши. Из руководства здесь умолчание yes и главное условие: догадка делается только тогда, когда уточнённого кода в ответе нет.
Пример в конфигурации
# известный почтовик: голый 553 у него про адрес
<domain gmail.com>
    smtp-553-means-invalid-mailbox true</domain>

# незнакомые приёмники: не назначаем адрес несуществующим по догадке
<domain *>
    smtp-553-means-invalid-mailbox false    bounce-category-patterns careful
</domain>
Во втором блоке разбор ответов задан рядом намеренно: отказавшись от догадки, категорию надо получить откуда-то ещё.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Оставляют умолчание для незнакомых приёмников

§ 3.3.10.66

Чем чреватоОтказ по политике отправителя записывается как несуществующий ящик. Адрес получателя выбывает из базы навсегда, хотя он живой, а претензия была не к нему.
Как заметитьВ жёстких отказах домены, куда почта раньше доходила, и заметная доля голых 553 в учёте.
Как правильноДля незнакомых приёмников поставить false, а категорию получать разбором текста ответа.

Считают, что строка действует всегда

наш опыт

Чем чреватоПри наличии уточнённого кода догадка не делается вовсе. Правку вносят, ждут изменения статистики и не получают его, потому что приёмник и так отвечает полным кодом.
Как заметитьЗначение поменяли, распределение категорий не изменилось.
Как правильноСначала посмотреть, приходят ли вообще ответы 553 без уточнённого кода.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
smtp-553-means-invalid-mailbox <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
yes § 3.3.10.66
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Подхватывается по pmta reload; уже записанные отказы не пересчитываются — правка действует только на будущие ответы приёмников.
⇄

Связанные директивы

1 связь

На что влияет

Два обработчика входящих отчётов и что с ними делатьДогадка, сделанная здесь, становится категорией отказа — и дальше по ней разбирают входящие отчёты. § 3.3.10.66

Как проверить на узле
Значение печатает команда настроек очереди; много ли голых ответов 553 вообще приходит, видно по учёту:
pmta show settings gmail.com/vmta1 | grep -i smtp-553
grep -c '553 ' /var/log/pmta/acct-*.csv
Если голых 553 в учёте нет, значение строки ни на что не влияет. Хаб долю таких ответов по приёмникам пока не считает.
◇

Что ещё почитать

3 статьи

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

В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Настроить темп под провайдера
Соседние настройки блока <domain>:smtp-pattern-listbounce-category-patternsbounce-upon-no-mxbounce-upon-5xx-greetingbounce-upon-transfer-failureВсе 135 директив блока →