Мое чутье подсказывает, что «это не проблема и логически не может быть исправлено». Я настраиваю резервное соединение с интернет-провайдером для использования с нашим почтовым сервером обмена на месте.
Вот что я настроил:
198.51.100.30 -> primary ISP
203.0.113.40 -> backup ISP
В DNS нашего домена example.com добавлено следующее:
mail.example.com. A 198.51.100.30
mail2.example.com. A 203.0.113.40
example.com. MX 10 mail.example.com.
example.com. MX 20 mail2.example.com.
PTR добавлен соответствующими интернет-провайдерами:
198.51.100.30 mail.example.com
203.0.113.40 mail2.example.com
Теперь наш почтовый сервер всегда работал только с mail.example.com как баннер, все хорошо, MXToolBox доволен. Однако что мне делать с баннером о нашем отказоустойчивом MX? Очевидно, что отказоустойчивый PTR mail2.example.com и создаст в MXToolBox сообщение «Обратный DNS не соответствует баннеру SMTP».
Я просто не переживаю по этому поводу или я что-то не правильно установил?
РЕДАКТИРОВАТЬ: сертификат SSL SAN, установленный на почтовом сервере, имеет оба mail.example.com и mail2.example.com.
Вам нужно только беспокоиться о названии баннера, когда mail2 используется для отправки исходящей почты. И в этом случае он все равно должен соответствовать обратному DNS для используемого IP-адреса. Единственное, что осталось проверить, это то, что собственное имя используется в любых сертификатах SSL (все 3 имени должны совпадать для каждого сервера - имя баннера / вертолета, имя в сертификате SSL и обратный поиск) и что резервный сервер указан в любых записях SPF и т. д. В моих записях SPF просто перечисляются «все MX для этого домена».
Так что да, насколько я могу судить, с тем, что вы опубликовали, у вас все должно быть хорошо.
Наилучший вариант - иметь два сервера, то есть настроить другой Exchange (или, альтернативно, SMTP-сервер с открытым исходным кодом, например Postfix) в качестве резервного / вторичного MX-сервера. В большинстве случаев сам сервер может вызывать большее время простоя, чем подключение к Интернету. Поскольку несоответствие баннеров является проблемой только для исходящей почты, этот сервер вполне может быть mail2.example.com в вашей текущей конфигурации.
Конфигурация исходящей почты
Второй подход заключался бы в том, чтобы оба соединения были настроены с одним и тем же именем хоста, поскольку на самом деле это один и тот же хост с разными IP-адресами и маршрутами. Этого можно добиться с помощью циклический DNS конфигурация + соответствие записей PTR и баннера SMTP, например
mail.example.com. A 198.51.100.30
mail.example.com. A 203.0.113.40
40.113.0.203.in-addr.arpa. PTR mail.example.com.
30.100.51.198.in-addr.arpa. PTR mail.example.com.
Не забудьте добавить запись SPF, позволяющую обоим IP-адресам отправлять почту, например
example.com. IN TXT "v=spf1 +ip4:198.51.100.30/32 +ip4:203.0.113.40/32 -all"
Конфигурация для входящей почты
Если вы хотите предпочесть первого интернет-провайдера второму во входящей почте (например, если у него лучшая пропускная способность), вы можете отделить свою конфигурацию MX от этого, например. добавляя
mx1.example.com. A 198.51.100.30
mx2.example.com. A 203.0.113.40
example.com. MX 10 mx1.example.com.
example.com. MX 20 mx2.example.com.
Несоответствие баннеров не является проблемой для входящей почты, так что это будет нормально.
Сертификат
Чтобы сертификат действовал для обеих конфигураций, теперь у него должны быть SAN для всех mail.example.com, mx1.example.com и mx2.example.com. Как правило, это не имеет большого значения, поскольку сертификаты почтового сервера редко проверяются на самом деле, и большинство почтовых систем по-прежнему допускают откат на незашифрованные соединения.
Вместо проверки сертификата на основе CA, Аутентификация именованных объектов на основе DNS (ДЕЙН, RFC 6698) - это предлагаемая альтернатива, позволяющая также проверять самоподписанные сертификаты. Для обратной совместимости невозможно настроить SMTP-сервер так, чтобы он разрешал только зашифрованные соединения, что оставляет дыру для атак MitM для соединений, которые могут быть установлены через TLS. С помощью DANE можно объявить, что для подключения должен использоваться TLS, и должны быть разрешены только сертификаты, опубликованные в зоне DNS.
Вы правы своим чутьем, чувствуя, что это не актуальная проблема по двум причинам:
Записи MX определяют, где вы хотите получать входящие сообщения электронной почты для своей электронной почты.
Ваша резервная запись MX не предназначена для использования для отправки почты, только для получения входящей почты.
Получать электронную почту легко: хотя некоторые отправители могут иметь несколько более строгую проверку, например, содержимого сертификата TLS для обеспечения обратной совместимости, почти все отправители просто доставляют почту в ваши записи MX, пока что-то одновременно прослушивает TCP-порт 25, правильно отвечает на сообщения протокола SMTP и возвращает "250 Запрошенное почтовое действие успешно завершено "ответ после принятия письма для доставки вам.
(Только надежная отправка электронной почты, безусловно, требует более тщательной настройки и соблюдения протокола.)
Входящий SMTP-сервер вообще не должен идентифицировать себя. Ему нужно только принимать сообщения, которые он хочет получить, и отклонять те, которых он не хочет. (Только отправитель должен идентифицировать себя.)
Насколько я знаю только актуальный Номер кода возврата ответа SMTP почти во всех серверных сообщениях актуален сам протокол. Текст, следующий за кодом ответа SMTP-сервера не только в сообщении баннера, но также и в сообщении об ошибке, а также в большинстве других сообщений интересен только для целей отладки / взаимодействия с человеком и вообще не имеет отношения к протоколу SMTP (и в большинстве случаев игнорируется). Обратите внимание, что это только для сообщений сервера, для борьбы со спамом сами SMTP-серверы гораздо строже в отношении того, что им требуется при получении сообщений от клиентов / других почтовых серверов.
Из RFC 5321 :
Реализации SMTP-сервера МОГУТ включать идентификацию своего программного обеспечения и информацию о версии в ответе на приветствие подключения после кода 220, что позволяет более эффективно изолировать и устранять любые проблемы. Реализации МОГУТ предусматривать для SMTP-серверов отключение объявления программного обеспечения и версии, если это вызывает проблемы с безопасностью.