База знаний PMTA›Блок <source>›Директива§ 3.3.7.34

reject-invalid-virtual-mta

Отвергать ли письмо, назвавшее несуществующий или пустой поток

в конфигурации это строкаreject-invalid-virtual-mta trueвнутри блока <source>

Что делать с письмом, назвавшим поток, которого нет

Умолчание — true, то есть отвергать на подаче. Отправитель получает отказ сразу, письмо на узел не попадает, и это честное поведение: имя потока названо неверно, догадываться MTA не берётся.

Вторая роль этой строки важнее первой. Директива invalid-virtual-mta-fallback на уровне узла умеет вместо отказа отправлять такие письма запасным потоком. Но она не работает, пока здесь стоит умолчание: сначала срабатывает отказ. Две строки в двух разных областях описывают одно поведение, и настроить надо обе.

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

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

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

Что ставить. Директива имеет смысл только в паре с invalid-virtual-mta-fallback, и осмысленных сочетаний два:

Здесь	Запасной поток	Что происходит
true (умолчание)	не задан	отказ на подаче — отправитель узнаёт сразу
false	задан	письмо уходит запасным потоком
false	не задан	поведение не описано — так не настраивают
true	задан	запасной поток не действует, отказ остаётся

Первое подходит своей подаче: отказ виден и чинится. Второе — чужой, где отказ теряется в чужих логах, а письмо терять нельзя.

Умолчание true и требование выключить его ради запасного потока — из руководства. Разбивка по сочетаниям — наша.

Пример в конфигурации

# обе строки нужны вместе: без этой запасной поток не подействует
invalid-virtual-mta-fallback mta-hub-pool

<source 10.0.0.0/24>
    process-x-virtual-mta yes
    reject-invalid-virtual-mta false</source>

Первая строка — уровня узла, вторая — источника. Письмо из этой подсети с заголовком, называющим несуществующий поток, уйдёт пулом вместо отказа. Уберите любую из двух — и вернётся отказ.

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

▲

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

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

Задают запасной поток и оставляют отказ включённым

§ 3.3.1.55.2

Чем чреватоЗапасной поток не подействует: сначала срабатывает умолчание true. Конфигурация выглядит настроенной, применяется без предупреждений и работает по-старому.

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

Как правильноДописать reject-invalid-virtual-mta false в тот источник, откуда идёт подача. Правило простое: две строки, обе обязательны.

Выключают отказ, не назвав запасного потока

§ 3.3.1.55.2

Чем чреватоРуководство описывает выключение отказа только вместе с запасным потоком; поведение без него не документировано. Отказ снят, а куда денется письмо — неизвестно.

Как заметитьЧасть писем не отвергается и не находится в очередях; в учёте по ним ничего.

Как правильноЛибо назвать запасной поток, либо вернуть умолчание. Половина этой пары настройкой не является.

Выключают отказ на весь узел ради одной платформы

наш опыт

Чем чреватоСтрока в широком блоке <source> 0/0 снимает отказ у всех, включая свою подачу. Опечатка в имени потока в плане прогрева перестаёт быть видимой ошибкой и превращается в письма, ушедшие не с того адреса.

Как заметитьПрогрев «идёт», а суточные объёмы по адресам не сходятся с планом.

Как правильноВыключать отказ только в узком блоке — той подсети, откуда подаёт платформа, ради которой всё и делается.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · платформа: любая

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

Справочные данные

Синтаксис: reject-invalid-virtual-mta <boolean>
Значения: yes | no | true | false
Умолчание: true § 3.3.7.34
Применение: reload, перезапуск не нужен
Очередь: уже поставленное в очередь не затронет
Где писать: <source>
Сколько раз: один раз в блоке

Всё здесь — из руководства, с разделом.

Наследование

Директива живёт в <source> и сливается по правилу источников: более узкий блок перекрывает более широкий. Отсюда полезное следствие: отказ можно оставить умолчанием для всех и выключить точечно — в блоке той подсети, откуда подаёт чужая платформа.

⇄

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

2 связи

Без чего не работает

invalid-virtual-mta-fallbackGlobalЗапасной поток не подействует, пока здесь стоит no: сначала отказ, потом уже всё остальное. § 3.3.1.55.2

Зависит от

process-x-virtual-mta<source>Неверное имя обычно приезжает именно заголовком — значит, вопрос встаёт там, где заголовок разрешён. § 3.3.7.34

Как проверить на узле

Проверять надо пару, а не одну строку. Обе видны в собранной конфигурации:

grep -n "invalid-virtual-mta" /etc/pmta/config

В выводе должны быть обе строки: invalid-virtual-mta-fallback в корне файла и reject-invalid-virtual-mta false в нужном источнике. Одна без другой означает, что настроено не то, что задумано.

◇