Demo
Demo
База знаний PMTA›Блок <feedback-loop-processor>›Директива§ 3.3.4.3

deliver-email

<feedback-loop-processor>устарела

Прежний общий переключатель доставки — устаревшая директива
в конфигурации это строкаdeliver-emailвнутри блока <feedback-loop-processor>
То же имя ещё 1:<bounce-processor><feedback-loop-processor>— часть из них другие настройки, часть та же самая
Одно решение вместо двух

Строка решала судьбу всех писем обработчика разом. Объявлена устаревшей, и раздел руководства состоит из одной фразы: пользуйтесь deliver-matched-email и deliver-unmatched-email.

Разделение появилось не зря. Узнанные и непонятые письма почти всегда требуют разного: первые выбрасывают, потому что данные уже в учёте; вторые доставляют или пересылают, потому что это может быть что угодно.

Перенос не механический. Умолчания у замены разные: deliver-matched-email — false, deliver-unmatched-email — true. То есть одно значение старой строки превращается в два осознанных решения.

Главная ловушка — перенести значение в обе строки одинаково. Так теряется весь смысл разделения: либо выбрасывается посторонняя почта, которую стоило бы прочитать, либо доставляются распознанные отчёты на адрес без ящика.
Что делает Хаб. Не пишет: пользуется обеими строками замены — и ставит обеим no, в обработчике отказов и в обработчике жалоб. Это не механический перенос, а решение: ящиков за адресами обработчиков нет, распознанное уходит в учёт, постороннее гасится. Цена — посторонняя почта на эти адреса до человека не доходит; чем это грозит, разобрано у deliver-unmatched-email.

Строку стоит знать в лицо при разборе чужой конфигурации.

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

Переносить надо не значение, а решение:

Что было Что стало
deliver-email no deliver-matched-email no — данные уже в учёте
deliver-unmatched-email — решать отдельно
deliver-email yes обе yes, если за адресом настоящий ящик
Факт устаревания и обе заменяющие строки — из руководства (§ 3.3.4.3). Таблица переноса и умолчания замены — из § 3.3.4.1 и § 3.3.4.2.
Пример в конфигурации
# так было раньше
<feedback-loop-processor>
    deliver-email no</feedback-loop-processor>

# так пишут теперь — два разных решения
<feedback-loop-processor>
    deliver-matched-email no
    deliver-unmatched-email true
    forward-unmatched-to postmaster@example.com
</feedback-loop-processor>
Нижний блок — не перенос значения, а два отдельных решения: данные уже в учёте, а посторонняя почта пусть дойдёт до человека.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Переносят одно значение в обе строки

наш опыт

Чем чреватоРазделение и было сделано ради разных решений. Одинаковые значения либо выбрасывают посторонние письма, либо доставляют отчёты на адрес без ящика.
Как заметитьВ блоке обе строки с одинаковым значением.
Как правильноРешать отдельно: узнанные обычно no, непонятые — true с пересылкой.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
deliver-email <boolean>
Значения
значения не документированы — в разделе только пометка об устаревании
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<feedback-loop-processor>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка писалась внутри своего <feedback-loop-processor>. Заменяющие её строки живут там же.
⇄

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

1 связь

Чем заменена

deliver-matched-email<feedback-loop-processor>Половина замены: решение про узнанные письма. § 3.3.4.3

Как проверить на узле
Найти устаревшую строку в конфигурации:
grep -rn "deliver-email" /etc/pmta/
Найдутся оба обработчика, если строка стоит в обоих. Каждую заменяют парой строк с осознанно выбранными значениями.
◇

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

3 статьи

◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.

В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Приём входящей почты
Соседние настройки блока <feedback-loop-processor>:deliver-unmatched-emailforward-unmatched-todeliver-matched-emailforward-errors-toВсе 5 директив блока →