Постфикс соединился с Подсистемой балансировки нагрузки, как отклонить сообщения подключения/разъединения в mail.log
У нас есть несколько Постфиксных серверов, подключенных к нашей Подсистеме балансировки нагрузки F5, которая проверяет на соединение на порте 25 каждых пар секунды к серверам, чтобы удостовериться, что это доступно. К сожалению, это создает довольно много шума в журналах, и я наблюдал бы это от Подсистемы балансировки нагрузки, чем от почтового сервера, если существует разъединение от сбалансированного пула загрузки.
Вот то, на что сообщения похожи, каждая пара секунды:
Oct 19 10:34:46 mail postfix/smtpd[14755]: connect from unknown[x.x.x.x]
Oct 19 10:34:46 mail postfix/smtpd[14755]: lost connection after CONNECT from unknown[x.x.x.x]
Oct 19 10:34:46 mail postfix/smtpd[14755]: disconnect from unknown[x.x.x.x]
Oct 19 10:34:49 mail postfix/smtpd[14755]: connect from unknown[x.x.x.x]
Oct 19 10:34:49 mail postfix/smtpd[14755]: lost connection after CONNECT from unknown[x.x.x.x]
Oct 19 10:34:49 mail postfix/smtpd[14755]: disconnect from unknown[x.x.x.x]
Oct 19 10:34:51 mail postfix/smtpd[14755]: connect from unknown[x.x.x.x]
Oct 19 10:34:51 mail postfix/smtpd[14755]: lost connection after CONNECT from unknown[x.x.x.x]
Oct 19 10:34:51 mail postfix/smtpd[14755]: disconnect from unknown[x.x.x.x]
Я просто видел бы информацию, связанную с почтовым сервером и отправляющий почту - но что-либо связанное с подключением, и разъединился бы от этих двух IP-адресов (подсистемы балансировки нагрузки), я мог заботиться меньше об и не буду скорее иметь того спама журналов.
Каковы мои опции здесь? Моя Постфиксная конфигурация является очень мягкой/основной, и я не делаю никакого вида входа или отладки кроме значения по умолчанию (за исключением smtpd_helo_restrictions = warn_if_reject check_helo_access static:reject который я использую для отслеживания HELOs для хранения нас от черного списка, но не связан с этим).
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
inet_protocols = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = mail.contoso.com, localhost.localdomain, localhost
myhostname = mail.contoso.com
mynetworks = 10.0.0.0/8 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = smtp-relay.gmail.com
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_helo_restrictions = warn_if_reject check_helo_access static:reject
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
Предполагая, что вы используете настройки по умолчанию, это на самом деле вопрос системного журнала, а не вопрос постфикса, поскольку постфикс отправляет эти события в системный журнал, а затем системный журнал (вероятно, rsyslog) выполняет обработку.
Вы я хочу отфильтровать эти сообщения:
: msg, contains, "from unknown [xxxx]" ~
@version: 3.5
filter f_F5 {message not ("from unknown [xxxx]");};
Какой монитор вы используете на BIG-IP для проверки узла SMTP здоровье? Если вы используете базовый протокол TCP, который ищет только соединение через сокет, это поправимо.
Существуют мониторы SMTP, которые вы можете настроить, которые будут запускать EHLO / QUIT, чтобы полностью закрыть соединение. Это еще один бонус, потому что он будет ждать, пока службы SMTP не станут доступны после сброса узла, вместо доступности TCP.
Если можете, проверьте это: https://devcentral.f5.com/questions/difference -between-tcp-monitor-and-smtp-monitor
Хотя вы можете очистить журналы, лучше исправить проблему. И не забудьте протестировать предварительную версию, прежде чем случайно уронить SMTP-сервер.
-Chase