Вопрос или проблема
Я недавно настроил ECMP на нашем сетевом брандмауэре, чтобы полностью мультидомицировать нас между интернет-провайдерами.
Настроить SPF было совсем просто, а вот с этой антиспамной техникой из 1970-х сложнее… Некоторые из наших контрагентов (которые используют свои собственные экземпляры postfix и должны продолжать принимать почту, отправляемую моим) настаивают на работе с postfix, используя “reject_unknown_client_hostname”. Вот определение из документации: “Отклоните запрос, если 1) сопоставление IP-адреса клиента с именем не удалось, или 2) сопоставление имени с адресом не удалось, или 3) сопоставление имени с адресом не соответствует IP-адресу клиента.” По сути, PTR-запись для данного IP должна быть действительно правильной.
Поскольку наш почтовый сервер postfix не знает, через какой публичный IP он будет выходить для данного соединения, мы должны отправлять одно и то же имя сервера в сообщении EHLO, независимо от того, по какому каналу оно выходит.
Лучшее решение, которое мы можем придумать, не создавая целый другой экземпляр postfix, это наличие PTR-записей на обоих публичных IP-адресах, указывающих на одно и то же имя A-записи, и затем наличие двух A-записей для этого имени, по одной для каждого IP. Я знаю, что это обычно ужасная идея, так как многие библиотек операционных систем не возвращают больше одной A-записи клиенту, и это, несомненно, приведет к неразрешимым сбоям. Какие есть другие варианты?
Имя хоста HELO, которое MTA использует для SMTP, не обязательно должно совпадать с PTR его видимого публичного IP-адреса. Оно просто должно разрешаться на этот публичный IP.
Каждый публичный IP-адрес, однако, нуждается в правильной PTR-записи, и этот PTR должен соответствовать соответствующей подтвержденной вперед A-записи (FCrDNS).
.
Ответ или решение
Конфигурация DNS и PTR-записей для почтового сервера Postfix, использующего два публичных IP-адреса, является важной задачей для обеспечения корректной доставки электронной почты и минимизации проблем, связанных с анти-спам механиками. Рассмотрим вашу ситуацию и предложенные вами решения.
Проблема и текущие решения
Ваше предприятие использует ECMP для улучшения сетевого многообразия между интернет-провайдерами. Это приводит к тому, что исходящие почтовые сообщения могут использовать один из двух публичных IP-адресов, что в свою очередь усложняет корректную настройку обратных PTR-записей для каждого IP-адреса. Некоторые контрагенты используют Postfix с параметром "reject_unknown_client_hostname", требующим, чтобы для IP-адреса был корректно настроен обратный DNS.
Рекомендации по настройке DNS и PTR
-
Обратные PTR-записи: Для каждого из ваших публичных IP-адресов необходимо настроить PTR-запись, указывающую на правильное доменное имя. PTR-записи должны быть "forward-confirmed", то есть обратное направление должно подтверждаться прямым разрешением (A или AAAA-записью), которое возвращает тот же IP.
-
Имена хостов HELO/EHLO: MTA (почтовый агент передачи) может отправлять одно и то же имя хоста в HELO/EHLO для обоих IP-адресов. Однако важно, чтобы это имя разрешалось в публичный IP, используемый в данный момент соединения.
-
Использование нескольких A-записей: Предложенное вами решение с несколькими A-записями для одного доменного имени может создавать проблемы, так как не все ОС корректно обрабатывают такие случаи. Несмотря на это, такое решение может сработать, если убедиться, что обе A-записи корректно указывают на соответствующие IP-адреса и отвечают требованиям обратного подтверждения.
-
Альтернативные варианты:
- Разделение функционала: Рассмотрите возможность запуска отдельного экземпляра Postfix для каждого IP с отдельными настройками DNS, что может уменьшить риск сбоев.
- Использование GRE-записей: Некоторые организации используют DNS-записи GRE, чтобы управлять трафиком между несколькими IP, однако это не всегда применимо в MTA-системах.
- Сложные маршруты: Установите более сложные маршрутизации в конфигурации Postfix, чтобы контролировать исходящий IP в зависимости от получателя.
Заключение
Оптимальная конфигурация DNS и PTR для многоадресной системы требует тщательного планирования и тестирования. Убедитесь, что каждое изменение протестировано в вашей среде, чтобы минимизировать риск отказов доставки. Это позволит вам поддерживать высокую производительность системы и минимизировать риск отклонения почты получателями.