deliver-local-dsn

<domain>устарела

Формировать ли отчёты для почты, принятой от этого домена
в конфигурации это строкаdeliver-local-dsn trueвнутри блока <domain>
Устаревшая половина той же задачи

Умолчание — true. Строка решала, формировать ли отчёты об исходе — отказ, задержка, доставка — для писем, принятых от домена, названного в этом блоке.

Записи учёта при этом писались как обычно: подавлялись только письма-отчёты.

Директива объявлена устаревшей. Замена — suppress-local-dsn в блоке источника, и разница между ними не только в названии: прежняя отбирала по домену отправителя письма, новая — по источнику подачи. Второе точнее: источник известен узлу достоверно, а домен отправителя ставит подающая сторона.

Главная ловушка — держать обе строки одновременно. Они решают одну задачу с разных сторон, и сочетание «подавлено по источнику, разрешено по домену» читается неоднозначно. Проверить, какая победит, можно только опытом — а нужды в этом нет: новая строка покрывает все случаи старой.
Что делает Хаб. Не пишет: пользуется заменой — suppress-local-dsn true действует во всех источниках подачи.

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

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

Что ставить. Ничего: строку следует убрать.

Значение Когда
не писать всегда: задачу решает настройка блока источника
no только в старой конфигурации, которую ещё не перевели

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

Умолчание true, оговорка «записи учёта пишутся как обычно» и пометка об устаревании с указанием замены — из руководства, § 3.3.10.9. Разбор разницы «домен отправителя против источника подачи» наш.
Пример в конфигурации
# так было раньше — по домену обратного адреса
<domain bounce.port25.com>
    deliver-local-dsn no</domain>
Сегодня то же самое пишется в блоке источника строкой подавления: она отбирает по подающей стороне, а не по домену, который та назвала обратным адресом.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Оставляют устаревшую строку рядом с новой

§ 3.3.10.9

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

Полагаются на отбор по домену отправителя

наш опыт

Чем чреватоДомен обратного адреса ставит подающая сторона, и он может оказаться любым. Подавление, привязанное к нему, обходится сменой обратного адреса — случайно или намеренно.
Как заметитьОтчёты приходят по части подачи, хотя подавление настроено.
Как правильноПеренести подавление в блок источника: источник известен узлу достоверно.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
deliver-local-dsn <boolean>
Значения
yes | no | true | false
Умолчание
true § 3.3.10.9
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <domain> и подчиняется слиянию блоков получателей — но отбирает не получателя, а домен отправителя принятого письма. Именно эта странность и стала причиной замены: новая строка живёт там, где отбор естественный, — в блоке источника.
Как проверить на узле
Устаревшую строку стоит искать вместе с её заменой:
grep -n 'deliver-local-dsn\|suppress-local-dsn' /etc/pmta/config /etc/pmta/virtualhost.txt
Если нашлись обе, конфигурацию надо привести к одной: устаревшую убрать, подавление задать в блоке источника.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Приём входящей почты