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

add-received-header

<source>Хаб задаёт сам

Добавлять ли заголовок Received при приёме письма
в конфигурации это строкаadd-received-header trueвнутри блока <source>
Отметиться в цепочке или исчезнуть из неё

Умолчание — true: приняв письмо, узел дописывает свой Received. Так делает любой почтовый сервер — заголовок фиксирует, кто, когда и от кого письмо принял, и из таких отметок складывается цепочка передачи, по которой потом восстанавливают путь.

С false узел в цепочке не отмечается вовсе. Письмо приходит получателю так, будто перед его сервером ничего не было.

Есть и мягкий вариант: hide-message-source оставляет заголовок, но убирает из него имя и адрес того, кто подал письмо. Он решает задачу приватности, не обрывая цепочку, — если задача именно в приватности.

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

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

Что делает Хаб. Пишет false — во всех источниках, какие генерирует: и в базовой конфигурации, и в каждом именованном источнике подачи. То есть узел в цепочке не отмечается.

Причина в шаблоне записана коротко: скрытие источника. Мягкую форму hide-message-source Хаб при этом не пишет — и правильно, она была бы бесполезна: править содержимое заголовка, которого нет, нечего.

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

Что ставить. Выбор между разбираемостью и приватностью:

Значение Когда
true (умолчание) цепочка нужна для разбора, а внутренние подробности прячет мягкая форма
false подающая сторона не должна быть видна вовсе — вместе с ней исчезает и след для разбора

Промежуточный вариант — true плюс hide-message-source: отметка есть, а имени и адреса подающего в ней нет. Он честнее второго и почти так же закрыт.

Умолчание true — из руководства, § 3.3.7.6. Что именно убирает мягкая форма — § 3.3.7.36. Разбивка случаев наша.
Пример в конфигурации
# так пишет конфигурацию Хаб — узел в цепочке не отмечается
<source 0/0>
    add-received-header false    remove-header X-PreviewEmail,X-Mailer,X-Priority
</source>
Обе строки про одно: не показывать получателю больше, чем нужно. Первая убирает отметку узла целиком, вторая вычищает служебные заголовки подающей платформы.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Выключают отметку, когда нужна была мягкая форма

§ 3.3.7.36

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

Полагаются на цепочку там, где сами её убрали

наш опыт

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

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

2 связи

Работают в паре

max-message-hops<source>Защита от петель считает пересылки по отметкам — без них считать нечего. § 3.3.7.38

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

hide-message-source<source>Мягкая форма той же задачи: отметка остаётся, а имени и адреса подающего в ней нет. § 3.3.7.36

Как проверить на узле
Настройку видно в конфигурации, результат — в заголовках доставленного письма:
grep -n 'add-received-header\|hide-message-source' /etc/pmta/config /etc/pmta/virtualhost.txt
Смотреть надо письмо в контрольном ящике: сколько в нём отметок Received и есть ли среди них ваш узел. Отметка приёмника там будет всегда — её ставит он сам, и на неё эта строка не влияет.
◇

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

3 статьи

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

В Хабе
Управляется
Инфраструктура → Параметры узла
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки
Соседние настройки блока <source>:process-x-jobjobid-prefixbccadd-message-id-headeradd-x-virtual-mta-headerВсе 74 директив блока →