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

always-allow-api-submission

<source>

Включить ли разом все права, нужные подаче по API
в конфигурации это строкаalways-allow-api-submission falseвнутри блока <source>
Ярлык, за которым стоит одна конкретная строка

Умолчание — false. Руководство описывает директиву как удобство: она разом включает все разрешения и возможности SMTP, нужные нашим API подачи.

И тут же говорит, чему это равно на сегодня: значение yes равносильно allow-mailmerge yes. Со значением no вопрос решают остальные настройки по отдельности.

То есть строка — не выключатель отдельной способности, а ярлык для набора, и набор этот вендор оставляет за собой право менять. Сегодня в нём одна директива; в следующей версии может оказаться больше.

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

Отсюда правило: если из набора нужна одна возможность — включайте её прямой строкой. Ярлык оставьте для случая, когда вы действительно подаёте через API вендора.

Что делает Хаб. Не пишет — строка убрана из рабочей конфигурации 29.08.2026.

Почему убрали. Подачей по HTTP Хаб не пользуется вовсе, блока <transmissions-api> в конфигурации нет, а слияние, которое строка включает на сегодня, нам не нужно. Решающим доводом стало слово руководства «сейчас эквивалентна»: содержание директивы вендор оставил за собой право расширить, а разрешение было выдано всем адресам сразу.

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

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

Что ставить. Вопрос — подаёте ли вы через API вендора:

Значение Когда
false (умолчание) подача идёт обычным SMTP — наш случай
true подача действительно идёт через API вендора, и перечислять права по одной незачем

Между ними есть третий путь: включить нужную возможность прямой строкой. Он предпочтительнее ярлыка везде, где набор известен, — потому что не меняется при обновлении MTA.

Умолчание false, назначение и оговорка «на сегодня равносильна разрешению слияния» — из руководства, § 3.3.7.72. Совет предпочитать прямую строку — наш.
Пример в конфигурации
# ярлык оправдан там, где подача действительно идёт через API вендора
<source 10.0.0.0/24>
    always-allow-api-submission true</source>
На сегодня та же строка равносильна allow-mailmerge yes. Если нужна именно она — честнее написать её прямо: набор за ярлыком вендор может расширить.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают ярлык ради одной возможности

§ 3.3.7.72

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

Оставляют ярлык там, где API не используется

наш опыт

Чем чреватоИсточник получает права без применения. Убрать их потом труднее, чем не выдавать: строка выглядит нужной, пока не прочитаешь, чему она равна.
Как заметитьЯрлык стоит в конфигурации, а подача идёт обычным SMTP.
Как правильноУбрать строку и проверить, что подача не сломалась — обычному SMTP она не нужна.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
always-allow-api-submission <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.7.72
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source> и подчиняется слиянию источников: соединение попадает под все адресные блоки, которые его накрывают, и узкий перекрывает широкий. Ярлык в блоке 0/0 раздаёт свой набор прав всем подсетям, которые сами не сказали обратного.
⇄

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

1 связь

На что влияет

allow-mailmerge<source>Единственное, чему ярлык равносилен на сегодня; набор за ярлыком вендор может расширить. § 3.3.7.72

Сюда ссылаются

Что нужно обвязке подачиДиректива, которой этот механизм и включается. § 7.1

Как проверить на узле
Смотреть надо и ярлык, и то, что он включает:
grep -n 'always-allow-api-submission\|allow-mailmerge' /etc/pmta/config /etc/pmta/virtualhost.txt
printf 'EHLO test\r\nQUIT\r\n' | nc <адрес-узла> 2525
Приветствие приёмника показывает, какие расширения источнику на самом деле объявлены. Это и есть надёжный способ узнать, что включает ярлык в вашей версии MTA.
◇

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

3 статьи

◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки
Соседние настройки блока <source>:allow-smtputf8disconnect-on-transient-errorallow-authaccept-invalid-recipientsmax-message-sizeВсе 74 директив блока →