Demo
Demo
База знаний PMTA›Точка API§ 8.1.4

Подача письма по HTTP

transmissions submission
Вторая дверь подачи

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

Вызов — POST https://адрес:порт/api/v1/transmissions на слушатель <transmissions-api-listener> — только по HTTPS, поэтому слушателю нужен сертификат. Заголовок Content-Type: application/json, ключ — в заголовке Authorization; тело можно сжать, объявив Content-Encoding: gzip.

Ключи — свои, не ключ монитора: их перечисляют строками api-key в <transmissions-api>, от 32 до 128 знаков. Свойства источника для писем, поданных так, задаёт именованный источник {transmissions-api}.

Ответ 200 несёт счёт: сколько получателей принято и сколько отклонено. Ошибки приходят кодами 400, 403, 404, 405 и 500.

Главная ловушка — принять 200 за доставку всем. Код значит, что запрос принят, а отказ по части получателей виден только в теле: total_rejected_recipients больше нуля при том же 200.
Что делает Хаб. Не пользуется: весь парк подаёт почту по SMTP, и слушателя <transmissions-api-listener> Хаб не пишет.
Рекомендуемые значения

Что значит ответ:

Код Когда
200 запрос принят; сколько получателей принято и отклонено — в теле
400 ошибка формата: нет обязательного поля, не тот тип, неподдерживаемое поле SparkPost
403 нет заголовка Authorization или ключ неверен
404 неверный путь
405 метод не POST
500 внутренняя ошибка при разборе верного запроса
Путь, заголовки, сжатие, ключи, именованный источник и коды ответа — из руководства (§ 8.1.1–8.1.9). Разбор ловушки — наш.
Пример в конфигурации
# подать письмо запросом: ключ из <transmissions-api>
curl -s -X POST --insecure -H 'Content-Type: application/json' -H 'Authorization: KEY' --data @msg.json 'https://127.0.0.1:8585/api/v1/transmissions'
–insecure нужен только с самоподписанным сертификатом слушателя. Порт 8585 — из примера руководства: слушатель занимает тот порт, что указан в его блоке.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
⇄

Связанные записи

2 связи

Чем можно заменить

Персонализация внутри MTAМеханизм, который здесь и виден. § 8.1.4

Где применяется

Как API сообщает об ошибкеМеханизм, который здесь и виден. § 8.1.9

Как проверить на узле
Проверить, заведён ли слушатель и отвечает ли он:
grep -n -A4 '<transmissions-api' /etc/pmta/config
curl -s -o /dev/null -w "%{http_code}\n" --insecure -X POST 'https://127.0.0.1:8585/api/v1/transmissions'
Без блоков в конфигурации точки нет вовсе. Любой код HTTP в ответ значит, что слушатель жив; 403 — ключ не принят.
◇

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

3 статьи

◇Персонализация внутри MTAПеременные задаются по каждому получателю, а подставляет их узел при доставке — одно поданное письмо уходит многим с разным содержимым.◇Слияние через расширения SMTPСлияние по SMTP: XMRG вместо MAIL FROM, XDFN с переменными перед каждым получателем и XPRT вместо DATA для каждой части.◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Прогрев адресов · Подключить платформу отправки