<domain>
Приёмник объявляет расширение 8BITMIME, узел этим пользуется: если подающее приложение сказало, что тело восьмибитное, узел передаёт это дальше — параметром команды MAIL FROM. Строка отменяет передачу.
Она не меняет само письмо. Кодировка тела остаётся прежней; меняется только то, сообщают о ней приёмнику или молчат. К тому, что объявлено в заголовках письма, строка отношения не имеет.
Зачем молчать. Руководство описывает конкретный сбой: внешний шлюз получателя объявляет 8BITMIME и принимает такое письмо, а внутренний узел за ним восьмибитных тел не понимает — и письмо отбивается уже внутри чужой сети. Умолчав, вы заставляете внешний шлюз обойтись без этого расширения.
Только точечно, под конкретного получателя. В блоке со звёздочкой строка лишает расширения всех приёмников сразу, включая тех, у кого с ним всё в порядке.
Признак, по которому включают. Отказы приходят не от внешнего шлюза, а изнутри чужой сети, с упоминанием кодировки или преобразования тела.
Проверяйте после включения. Если отказы не ушли, дело было не в объявлении расширения.
# корпоративный шлюз принимает восьмибитное, а узел за ним — нет <domain corp.example.com> ignore-8bitmime true</domain>
что делают не так и чем это кончается2 ошибки▶
§ 3.3.10.77
наш опыт
1 связь
pmta show settings corp.example.com/vmta1 | grep -i ignore-8bitmime grep -i '8BITMIME' /var/log/pmta/pmta.log | tail -10
3 статьи
◇Как складывается политика для приёмникаНастройки собираются от самого общего образца к самому точному; порядок блоков в файле не значит ничего.◇Щадящий режим — вторая личность очередиОчередь, которой приёмник начал отказывать, переключается на параллельный набор лимитов, повторов и маршрутов — десять директив, действующих только в этом режиме.◇Наблюдение за репутацией внутри узлаMTA сам следит за ответами приёмников и по совпадению с образцом меняет режим очереди — реакция внутри соединения, а не по телеметрии.