Demo
Demo
База знаний PMTA›Механизм§ 7

Что подающая система собирает перед отправкой

Connection, Message, Recipient
Три предмета, и каждая настройка принадлежит одному из них

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

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

Руководство честно о выгоде. Обвязки не быстрее обычного соединения по SMTP — кроме случая слияния, когда на одно письмо приходится несколько получателей. То есть берут их ради персонализации и управления отдельным письмом, а не ради скорости.

Транспорт — изменённый SMTP, поэтому подача бывает и локальной, и удалённой; разницы в модели это не создаёт.

Главное для тех, кто обвязки не использует: те же решения доступны и по обычному SMTP — через управляющие заголовки письма (control-headers). Что подающая система вправе решить, знать полезно, даже если сама обвязка не нужна.

Главная ловушка — считать, что подачу определяет конфигурация узла. Адрес отправки, идентификатор задания, идентификатор конверта, кодировку, тип возврата и уведомления по каждому получателю выбирает подающая система, а не файл настроек. Настройка узла задаёт умолчание и границы; всё, что подающая система назвала явно, обычно сильнее. Искать причину странного поведения одного письма в конфигурации, когда её задала подача, — самый частый способ потратить время впустую.
Что делает Хаб. Обвязками не пользуется — прогревочный отправитель подаёт письма обычным SMTP на порт подачи, и площадки, с которыми Хаб связан, тоже.

Но управляющие заголовки он использует: в письмо добавляется X-Virtual-MTA с именем адреса отправки, и при необходимости другие заголовки. Это ровно то, о чём говорит эта запись, — решение принимает подающая сторона, просто выражено оно заголовком, а не вызовом обвязки.

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

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

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

Уровень На кого действует Пример решения
соединение на всё, что через него подано к какому узлу и под каким входом
письмо на всех получателей письма адрес отправки, задание, кодировка
получатель на одного человека переменные слияния, уведомления

Правило выбора простое: чем ниже уровень, тем дороже. Настройка получателя означает, что письмо нельзя передать одной передачей всем сразу. Если персонализации нет, всё, что можно, стоит задавать на уровне письма.

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

Таблица уровней и правило «чем ниже, тем дороже» наши. Из руководства здесь порядок сборки, состав трёх предметов, честная оговорка о скорости и то, что транспорт — изменённый SMTP.
Пример в конфигурации
# то же решение двумя способами: обвязкой и заголовком
# обвязка: свойство письма
#   msg.setVirtualMTA("mta-news-1")
# обычный SMTP: тот же выбор управляющим заголовком
X-Virtual-MTA: mta-news-1X-Job: campaign-4417
Хаб подаёт вторым способом. Выделенная строка выбирает адрес отправки для одного письма; узел снимет её перед отправкой, если так настроен блок подачи, — иначе заголовок уедет получателю.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Берут обвязку ради скорости

§ 7

Чем чреватоРуководство говорит прямо: обвязки не быстрее обычного соединения, кроме слияния с несколькими получателями на письмо. Затраты на новую зависимость окупаются персонализацией, а не пропускной способностью.
Как заметитьПереход на обвязку не изменил скорость отправки, зато добавил библиотеку в сборку подающей системы.
Как правильноОставаться на SMTP, если персонализация не нужна. Управляющие заголовки дают те же решения без новой зависимости.

Задают на уровне получателя то, что верно для всего письма

§ 7

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

Ищут причину в конфигурации, когда решила подача

§ 7

Чем чреватоАдрес отправки, задание и кодировку выбирает подающая система. Разбор странного поведения одного письма по файлу настроек заканчивается ничем: в файле стоит умолчание, а письмо ушло не по нему.
Как заметитьОдно письмо ушло не с того адреса, при том что конфигурация у всех одна.
Как правильноНачинать с учёта: там видно, что было решено для конкретного письма. И проверять, разрешено ли блоку подачи слушаться заголовков.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у модели нет — есть старшинство: то, что назвала подающая система, сильнее умолчания из конфигурации. Но границы задаёт узел: блок подачи решает, разрешено ли вообще слушаться заголовка выбора адреса и заголовка задания. Запрещённый заголовок просто не действует, а письмо принимается.
⇄

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

3 связи

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

allow-mailmerge<source>Слияние надо ещё и разрешить в блоке подачи — иначе подающая система его не применит. § 7.1

То же имя в других блоках

Как письмо попадает в MTAТот же способ подачи среди прочих: обвязки — одна из дверей на узел. § 7

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

Заголовки, которыми отправитель управляет доставкойТе же решения, доступные по обычному SMTP: заголовок вместо вызова обвязки. inference

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

Обвязка подачи на C++Смежный механизм: они работают вместе. § 7.4Обвязка подачи на PerlТа же настройка на другом уровне. § 7.2Обвязка подачи на JavaТа же настройка на другом уровне. § 7.3Обвязка подачи на .NETТа же настройка на другом уровне. § 7.6Подача по HTTPS на своём приёмнике, по образцу SparkPostДругой способ передать то же самое: там протокол SMTP, здесь запрос HTTP с телом в JSON. § 8.1

Как проверить на узле
Что именно решила подача, видно в учёте — там записаны и адрес отправки, и задание:
grep -m5 'campaign-4417' /var/log/pmta/acct*.csv
pmta show jobs
В строке учёта есть поля адреса отправки и задания — по ним видно, послушался узел заголовков или подставил умолчание. Вторая команда покажет задания, известные узлу: если задания нет в списке, значит заголовок не был принят.
◇

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

3 статьи

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

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