С версии 5.5 письмо, поданное по HTTP, можно не собирать: в объекте content вместо готового email_rfc822 передают from, subject, reply_to, headers, text, html, amp_html и attachments, а узел собирает письмо сам.
Кодирование — забота узла: символы вне ASCII он кодирует по мере надобности — в заголовках по RFC 2047, в теле quoted-printable. Текст в запросе — простой UTF-8, кодировать его нельзя: подстановки выполняются до кодирования и переноса строк.
Повторы молча игнорируются: из частей с одинаковым именем в письмо попадает только первая.
Поля объекта content:
| Поле | Что несёт |
|---|---|
| from, reply_to, subject | отправителя, адрес ответа, тему |
| headers | свои заголовки |
| text, html, amp_html | части тела |
| attachments | вложения |
# содержимое частями вместо готового письма "content": {"from": "news@example.com", "subject": "[name], hello", "text": "Hi [name]", "html": "<p>Hi [name]</p>"}
Связанные записи
1 связь
Кодировки при подачеСмежный механизм: они работают вместе. § 8.1.5
grep -n -A4 '<transmissions-api' /etc/pmta/config
Что ещё почитать
3 статьи
◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.
- Цена ошибки
- безопасно: неверное значение ничего не ломает
- Сценарии
- Подключить платформу отправки