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

replace-message-id-header

<source>

Заменять ли идентификатор письма, который поставил отправитель
в конфигурации это строкаreplace-message-id-header falseвнутри блока <source>
Замена чужого идентификатора своим

Умолчание — false. С true MTA заменяет имеющийся Message-Id на свой. Если заголовка в письме нет, строка не делает ничего — дописывание это другая директива, add-message-id-header.

Уникальность нового значения между серверами держится на том же host-id, что и у дописывания.

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

Разойдётся это не сразу — в момент, когда придёт жалоба и по ней попробуют найти письмо.

Что делает Хаб. Не пишет — и не должен. Библиотека отправки ставит свой Message-Id, и Хаб сохраняет его вместе с записью отправки. Замена на узле оставила бы у нас идентификатор, которого ни у кого больше нет.
Рекомендуемые значения

Что ставить. Случай для true узкий:

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

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

Умолчание false и оговорка «на письмо без заголовка не действует» — из руководства, § 3.3.7.5. Уникальность через номер узла — § 3.3.1.33. Разбор про потерю связи наш.
Пример в конфигурации
# замена имеет смысл только вместе с явным номером узла
host-id 7

<source 10.0.0.0/24>
    replace-message-id-header true</source>
Письмо из этой подсети уйдёт с идентификатором, который назначил узел, а не подающая платформа. У платформы в базе останется прежний — и связать их будет нечем.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают замену на всём узле

наш опыт

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

Ждут, что замена допишет недостающий заголовок

§ 3.3.7.5

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

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

1 связь

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

add-message-id-header<source>Соседний вопрос: та дописывает недостающий идентификатор, эта переписывает имеющийся. § 3.3.7.5

Как проверить на узле
Настройку видно в конфигурации, следствие — в контрольном ящике:
grep -n 'replace-message-id-header\|^host-id' /etc/pmta/config /etc/pmta/virtualhost.txt
Проверять надо на письме, у которого идентификатор уже был: сравнить, что ушло с подающей стороны и что дошло до ящика. Совпали — строка не сработала; разошлись — сработала.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки
Соседние настройки блока <source>:process-x-jobjobid-prefixallow-mailmergeadd-message-id-headeradd-received-headerВсе 74 директив блока →