Несоответствие баннера SMTP с несколькими записями MX

Вам нужно только беспокоиться о том, какое имя баннера используется, когда mail2 используется для отправки исходящей почты. И в этом случае он все равно должен соответствовать обратному DNS для используемого IP-адреса. Единственное, что осталось проверить, это то, что собственное имя используется в любых сертификатах SSL (все 3 имени должны совпадать для каждого сервера - имя баннера / вертолета, имя в сертификате SSL и обратный поиск) и что резервный сервер указан в любых записях SPF и т. д. Насколько я знаю, мои записи SPF просто перечисляют «все MX для этого домена».

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

Вы правы своим чутьем, чувствуя, что это не актуальная проблема по двум причинам:

1. Записи MX определяют, где вы хотите получать входящие сообщения электронной почты для своей электронной почты.
   Ваша резервная запись MX не предназначена для использования для отправки почты, только для получения входящей почты.

   Получать электронную почту легко: хотя некоторые отправители могут иметь несколько более строгую проверку, например, содержимого сертификата TLS на предмет обратной совместимости, почти все отправители просто доставляют почту в ваши записи MX, если что-то одновременно прослушивает TCP. порт 25,правильно отвечает на сообщения протокола SMTP и возвращает ответ « 250 Запрошенное почтовое действие успешно выполнено» после принятия почты для доставки вам.

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

2. Входящий SMTP-сервер вообще не должен идентифицировать себя. Ему нужно только принимать сообщения, которые он хочет получить, и отклонять те, которых он не хочет. (Только отправитель должен идентифицировать себя.)

   Насколько мне известно , только фактический номер кода возврата ответа SMTP почти во всех сообщениях сервера имеет значение для самого протокола. Текст, следующий за кодом ответа SMTP-сервера, не только в сообщении баннера, но также и в сообщении об ошибке, а также в большинстве других сообщений интересен только для целей отладки / взаимодействия с человеком и вообще не актуален с точки зрения протокола SMTP (и в основном игнорируется). Обратите внимание, что это касается только сообщений сервера. Для борьбы со спамом сами SMTP-серверы гораздо строже относятся к тому, что им требуется при получении сообщений от клиентов / других почтовых серверов.

Из RFC 5321 :

Реализации SMTP-сервера МОГУТ включать идентификацию их информация о программном обеспечении и версии в ответе на приветствие при соединении после кода 220, практика, которая позволяет более эффективно изолировать и ремонт любых проблем. Реализации МОГУТ предусматривать Серверы SMTP для отключения программного обеспечения и объявления версии, где это вызывает проблемы с безопасностью

Один из способов настроить Postfix в ситуации, подобной вашей, — определить два исходящих транспортных интерфейса smtp в master.conf:

mail.example.com-out  unix -       -       n       -       -       smtp
   -o smtp_bind_address=198.51.100.30
   -o smtp_helo_name=mail.example.com
   -o syslog_name=postfix-mail.example.com

mail2.example.com-out  unix -       -       n       -       -       smtp
   -o smtp_bind_address=203.0.113.40
   -o smtp_helo_name=mail2.example.com
   -o syslog_name=postfix-mail2.example.com

Затем определить параметр default_transport в файле main.cf:

default_transport = mail.example.com-out

Наконец, создать оболочку скрипт, который регулярно проверяет подключения к вашему провайдеру с помощью cronjob и переключает транспорт Postfix на лету. Вот пример такого сценария bash (при условии, что ваши два интернет-провайдера подключены к интерфейсам eth0 и eth1. В качестве альтернативы используйте ключ -S для команды ping ниже, определяющей исходный IP-адрес: ping -S 198.51.100.30 -c 2 $SERVERIP... - конкретный способ зависит от вашей конфигурации двух интерфейсов шлюза/таблицы маршрутизации), его следует запускать под root:

#!/bin/bash
SERVERIP=8.8.8.8

ping -I eth0 -c 2 $SERVERIP > /dev/null 2>&1
if [ $? -ne 0 ]
then
    echo "ISP1 is down"
    ping -I eth1 -c 2 $SERVERIP > /dev/null 2>&1
    if [ $? -ne 0 ]
        echo "ISP2 is also down"
    else
        echo "Switching to ISP2"  
        sed -i 's/mail.example.com-out/mail2.example.com-out/g' /etc/postfix/main.cf
        systemctl reload postfix
    fi  
else
   echo "ISP1 reachable"
   if grep -q 'mail2.example.com-out' /etc/postfix/main.cf; then
      echo "Switching back to ISP1"
      sed -i 's/mail2.example.com-out/mail.example.com-out/g' /etc/postfix/main.cf
      systemctl reload postfix
   fi
fi

Root's crontab (запустите 'crontab -e' под root для редактирования) пример для запуска скрипта каждые 2 минуты:

*/2 * * * * /path/to/your/script.sh 2>&1 | ts | tee -a /var/log/check_postfix_transport.log

Обоснование:

Баннер SMTP определяется только для демона smtp (сервера), принимающего входящее соединение от клиента smtp. С баннером SMTP сервер идентифицирует себя для подключающегося клиента во время инициации сеанса. Однако это необязательно.

Из RFC 5321:

3.1 Инициация сеанса

Сеанс SMTP инициируется, когда клиент открывает соединение с сервер, и сервер отвечает открывающим сообщением.

Реализации SMTP сервера МОГУТ включать идентификацию своих информация о программном обеспечении и версии в приветственном ответе при подключении после кода 220 .

Клиент (например, другой сервер, который хочет доставить электронную почту на входящий сервер) никогда не отправляет SMTP-баннер на принимающий сервер.На сервер отправляется имя хоста EHLO/HELO, и это именно то, что серверы проверяют на несоответствие PTR в отношении спама и т. д.

Из RFC 5321:

3.2 Клиент Инициация

После того, как сервер отправил приветственное сообщение и клиент получил его, клиент обычно отправляет команду EHLO на сервер, указывающий личность клиента.

На основе EHLO/HELO сервер может проверить PTR (если IP-адрес отправляющей стороны SMTP разрешается обратно в имя хоста) и/или spf и, наконец, решает, действительно ли он хочет получать или ретранслировать сообщение электронной почты, исходящее от SMTP-клиента.

Основываясь на этом, в целом вам следует позаботиться о командах EHLO, которые ваш SMTP-сервер отправляет на другие серверы, когда он хочет отправить им сообщения электронной почты (и действует как SMTP-клиент во время этих подключений). Вы должны убедиться, что ваш SMTP-сервер использует правильный IP-адрес источника и отправляет правильное имя хоста EHLO, которое разрешается обратно в тот IP-адрес, который используется для подключения. И вы можете игнорировать SMTP-баннер просто потому, что он предназначен для получения электронной почты, а не для отправки.

Я предполагаю, что mxtoolbox также смешивает SMTP Reverse DNS Mismatch и SMTP Banner Mismatch и проверяет последнее без всякой причины, и его формулировка о SMTP-баннере в этом отношении частично неверна. Несоответствие SMTP rDNS имеет значение, несоответствие баннера SMTP не имеет значения. Опять же, SMTP-баннер отправляется принимающим сервером (поэтому он определен в Postfix в параметре 'smtpd_banner', а не в 'smtp_banner'), а не отправляющим/ретранслирующим клиентом.Таким образом, это не имеет ничего общего со спамом и т. д.

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