Postfix. Как изменить тему письма.

Вопрос снимается: мне подсказали насчет ф-ии REPLACE у header_checks
а также про необходимость доп. входа для избирательного изменения темы

Зато есть другой вопрос. :-)

что я-то работаю с sendmail и, зная о нерац-ти использования сторонних фильтров через milter

Чем это не рационально ?

Тем, что фильтр вызывается на каждом этапе smtp-диалога.

Вообще-то, это не совсем так. Новый тред с фильтром образуется уже на этапе появление очередного процесса sendmail. Далее вызываются только соответствующие этапам каллбэки. Они могут что-то делать, могут не делать. Назвать это вызовом фильтра уже, думаю, нельзя. Скорее это обращение к функциям. Нерациональностью можно считать только изначальный старт треда фильтра, но это вопрос использования milter вообще.

Спасибо за уточнение.
ТОже уточню:
Нерациональностью можно считать только изначальный старт треда фильтра, то есть с началом нового smtp-диалога. И то только для моей почтовой системы, которая использует свой собств.фильтр и отсекает массу спама на начальном этапе.

Вот, скажем, за вчерашний день моим почтовиком было отказано 23 тысячам соединений на основе анализа заголовков.
Из пропущенных писем в 800 случаях VadeRetro
распознал спам ( причем из этих 800 писем 480 VR уничтожил). В итоге до пользователей дошло только 1770 писем.
То есть до VR дошло только 2250 писем, а 23 000 обращений к функциям milter было совсем не оправдано. Я бы даже уточнила 23000*N,
где N - кол-во заголовков письма, которые VR успеет обработать.
Например, если отказ происходит на этапе check_eoh, то N=4

Если кто-то не делает предпроверки, тогда вся почта должна пройти через milter+filter и вопрос о нерациональности отпадает сам собой.

К слову сказать, и сами фильтры порой грешать нерац-тью.
В предыд. версиях Спамообороны тема письма у сообщения, которое набирало необходимый для его уничтожения вес, все равно изменялась (помечалась меткой), о чем в логе появлялась торжественная запись о том, что тема изменена, а потом о том, что письмо уничтожено.

А техподдержкой на мое неудомение было отвечено, что в новой версии это исправлено, дальше цитирую дословно «ХОТЯ ЭТО НИКОМУ И НЕ МЕШАЛО»

Я вот что имел ввиду.

Если какие-то milter-фильтры вообще используются, то нет разницы, когда срабатывают любые проверки: каллбэки уже начинают отрабатываться. При этом, если какой-то из фильтров обладает универсальностью, задействование его дополнительных возможностей на оверхэд не повлияет. Вообще же без фильтров обойтись сложно: нужно как-то задействовать антивирус, антиспам и т.п. Учитывая, что просто удалять письмо нельзя в любом случае (100% гарантии точности определения вирусов и спама нет, а сервер «чёрная дыра» - ужас-ужас), а боунс генерировать плохо, решение надо принять в момент отработки сессии, то есть, или 5xx на ту сторону, или принимаем до конца.

Вариант с бакапом удаляемых сообщений и их последующим просмотром плох по нескольким причинам. Как минимум, это проблема с соблюдения закона о связи (правда, важно только для провайдеров) и само по себе время на отсмотр.

Соответственно, это приводит к тому, что либо сам MTA должен уметь обращаться к соответствующим сервисам в нужные моменты, либо нужен какой-то механизм, похожий на мильтер, позволяющий сделать прослойку между нужным сервисом и MTA.

Ну а предпроверки... мильтер-фильтр тоже может вполне в этом участвовать, при этом, на основании каких-то начальных данных, можно по-разному использовать и антиспам, и антивирус. У меня вот spamassassin используется только для сообщений с определённой степенью подозрительности: если реверс начинается с mail, relay, mx (и ещё там кое-что), то конткнтный фильтр вообще не используется. Собственно, все проверки до DATA у меня мильтер делает (один). Он же общается со spamassassin (как я написал уже) и clamd.