Мы используем postfix 2.7 и настраиваемый SMTPD (на основе qpsmtpd) в настраиваемой конфигурации для фильтрации спама. У нас есть новое требование для фильтрации отказов, сгенерированных постфиксом, с помощью нашего пользовательского процесса qpsmtpd (не столько для фильтрации содержимого, сколько для соответствующей обработки этих отказов).
Наша текущая конфигурация выглядит (частично) так:
main.cf (показаны только настройки):
2526 inet n - - - 0 cleanup
pickup fifo n - - 60 1 pickup
-o content_filter=smtp:127.0.0.2
Наш smtpd вводит сообщения в postfix на порту 2526, обращаясь напрямую к демону очистки. А команда custom pickup инструктирует postfix передавать всю локально сгенерированную почту (из cron, nagios или других настраиваемых сценариев) нашему настраиваемому smtpd.
Проблема в том, что эта конфигурация не влияет на сообщения о недоставке, генерируемые postfix, поскольку они не проходят через демон подбора.
Я попытался добавить тот же параметр content_filter к командам демона bounce, но, похоже, это не имеет никакого эффекта:
bounce unix - - - - 0 bounce
-o content_filter=smtp:127.0.0.2
defer unix - - - - 0 bounce
-o content_filter=smtp:127.0.0.2
trace unix - - - - 0 bounce
-o content_filter=smtp:127.0.0.2
Для справки вот мой main.cf файл, а также:
biff = no
# TLS parameters
smtpd_tls_loglevel = 0
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtp_tls_security_level = may
mydestination = $myhostname
alias_maps = proxy:pgsql:/etc/postfix/dc-aliases.cf
transport_maps = proxy:pgsql:/etc/postfix/dc-transport.cf
# This is enforced on incoming mail by QPSMTPD, so this is simply
# the upper possible bound (also enforced in defaults.pl)
message_size_limit = 262144000
mailbox_size_limit = 0
# We do our own message expiration, but if we set this to 0, then postfix
# will try each mail delivery only once, so instead we set it to 100 days
# (which is the max postfix seems to support)
maximal_queue_lifetime = 100d
hash_queue_depth = 1
hash_queue_names = deferred, defer, hold
Я также попытался добавить параметр internal_mail_filter_classes в main.cf, но также не повлиял:
internal_mail_filter_classes = bounce,notify
Я открыт для любых предложений, в том числе для обработки нашего текущего цикла фильтрации содержимого другим способом.
Если неясно, о чем я спрашиваю, дайте мне знать, и я могу попытаться уточнить.
В этом случае вы делаете это слишком сложно. Это простой способ.
Вам необходимо иметь это (дополнительное) в вашем main.cf:
notify_classes = resource, software, bounce, 2bounce
bounce_notice_recipient = random.bounce@example.com
2bounce_notice_recipient = random.bounce@example.com
transport_maps = hash:/etc/postfix/transport_maps #or another file. See below.
в /etc/postfix/transport_maps ставить
random.bounce@example.com smtp:127.0.0.2:25
затем postmap /etc/postfix/transport_maps. Потом postfix reload или перезапустите Postfix.
Это будет уведомлять пользователя random.bounce@example.com обо всех отказах, и поскольку этот пользователь, как говорят, проходит через 127.0.0.2:25, вы получаете все эти письма через этот сервер. Замените адреса / IP / порт в соответствии с вашей средой.