remove-header

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

Какие заголовки вырезать из письма
в конфигурации это строкаremove-headerвнутри блока <source>
Что не должно доехать до получателя

Значение — список имён через запятую, а не одно имя: строку не повторяют, её дополняют.

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

Пустая строка (“”) стирает список, унаследованный из более широкого блока. Это единственный способ отменить наследование: перечислением его не отменить, оно только добавляет.

Директива работает и со стороны получателя. Руководство говорит, что её можно писать в <source> или в <domain>, и определять в обоих не требуется. Указатель главы 15 при этом знает только позицию у источника — но вывод настроек получателя (§ 6.3.16) печатает remove-header “” среди прочих, что подтверждает: форма у получателя существует, просто не задокументирована.

Главная ловушка — подпись. DKIM подписывает перечисленные заголовки, и снятие подписанного ломает проверку у получателя. Порядок «подписать или снять раньше» руководство нигде не оговаривает, а список подписываемых заголовков у MTA свой — и часть из них, по § 3.3.10.26, снять нельзя вовсе.

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

Что делает Хаб. Пишет — один и тот же список в каждом источнике, какой генерирует: X-PreviewEmail, X-Mailer, X-Mailer-RecptId, X-Mailer-Sent-By, X-Priority.

Это заголовки платформ рассылки: по ним получатель (и приёмник) узнаёт, каким именно продуктом собрано письмо, а X-Priority к тому же считается признаком массовой рассылки.

Отметку о приёме Хаб снимает не этой строкой, а add-received-header false — она выключает добавление вовсе, и вычищать из списка нечего.

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

Что ставить. Список собирают из того, что рассказывает о вашей инфраструктуре:

Значение Когда
не писать подающая платформа своих заголовков не ставит
список имён через запятую обычный случай: вычистить следы платформы отправки
“” отменить список, унаследованный из широкого блока

В список не стоит класть заголовки, входящие в подпись, — и тем более те, что MTA подписывает всегда.

Синтаксис списка, снятие при доставке, оговорка про два блока и стирание пустой строкой — из руководства, § 3.3.7.9. Умолчание у получателя видно в § 6.3.16. Список неснимаемых заголовков — § 3.3.10.26.
Пример в конфигурации
# так пишет конфигурацию Хаб — заголовки платформ рассылки
<source 0/0>
    remove-header X-PreviewEmail,X-Mailer,X-Mailer-RecptId,X-Mailer-Sent-By,X-Priority</source>
Одна строка, пять имён через запятую. Повторять директиву не нужно — список дополняется в ней самой.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Кладут в список подписанный заголовок

§ 3.3.10.26

Чем чреватоСнятие подписанного заголовка ломает проверку подписи у получателя, и письмо выглядит подделанным. Часть заголовков MTA подписывает всегда и снять их не даёт вовсе.
Как заметитьПриёмники сообщают о неверной подписи после правки списка.
Как правильноСверить список со списком подписываемых заголовков и проверить письмом в свой ящик.

Повторяют директиву вместо перечисления

§ 3.3.7.9

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

Пытаются отменить унаследованный список перечислением

§ 3.3.7.9

Чем чреватоНаследование здесь добавляющее: список из широкого блока приходит в узкий, и перечисление в узком его не отменяет. Заголовок продолжает сниматься там, где он был нужен.
Как заметитьВ узком блоке снимается больше, чем в нём написано.
Как правильноОтменять пустой строкой, а нужное перечислять заново.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
remove-header <header-list>
Значения
имена заголовков через запятую; пустая строка стирает унаследованное
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source> и подчиняется слиянию источников: соединение попадает под все адресные блоки, которые его накрывают, и узкий перекрывает широкий. Наследование здесь добавляющее: список из широкого блока достаётся узкому, и отменить его можно только пустой строкой. Отдельно существует форма у получателя — но она в указателе не описана.
Как проверить на узле
Список видно в конфигурации, результат — в заголовках доставленного письма:
grep -n 'remove-header' /etc/pmta/config /etc/pmta/virtualhost.txt
Проверять надо письмом в контрольном ящике: перечисленных заголовков в нём быть не должно, а подпись DKIM — проходить. Второе важнее: сломанная подпись хуже лишнего заголовка.
В Хабе
Управляется
Инфраструктура → Параметры узла
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разделение отправителей