Назад | Перейти на главную страницу

Является ли смарт-хостинг для записи A нарушением раздела 1 RFC-5321?

У меня есть сервер sendmail, настроенный на smarthost для подчиненного ресурса. В настоящее время конфигурация:

define(`SMART_HOST',`relay:[vip.example.local]')dnl

Поскольку он отправляет A запись для vip.example.local. Мне сказали, что это нарушение раздела 5.1 IETF RFC-5321, в котором говорится:

Как только клиент SMTP лексически определяет домен, в который будет
доставляться для обработки (как описано в разделах 2.3.5 и 3.6), поиск DNS ДОЛЖЕН выполняться для разрешения доменного имени (RFC 1035
[2]). Ожидается, что имена будут полностью определенными доменными именами.
(FQDN): механизмы для вывода FQDN из частичных имен или локальных имен.
псевдонимы выходят за рамки этой спецификации. Из-за истории
проблемы, SMTP-серверы, используемые для первоначальной отправки сообщений, НЕ ДОЛЖНЫ делать такие выводы (серверы отправки сообщений [18]
немного большей гибкости) и промежуточные (ретрансляционные) серверы SMTP НЕ ДОЛЖНЫ их создавать.

Поиск сначала пытается найти запись MX, связанную с именем. Если запись CNAME найдена, полученное имя обрабатывается, как если бы это было исходное имя. Если возвращается несуществующая ошибка домена, эта ситуация ДОЛЖНА быть сообщена как ошибка. Если возвращается временная ошибка, сообщение ДОЛЖНО быть поставлено в очередь и повторено позже (см. Раздел 4.5.4.1). Если возвращается пустой список MX, адрес обрабатывается так, как если бы он был связан с неявной записью MX RR с предпочтением 0, указывающим на этот хост. Если записи MX присутствуют, но ни одна из них не может использоваться, или неявный MX непригоден, эта ситуация ДОЛЖНА быть сообщена как ошибка.

Если для данного имени найдены одна или несколько записей MX RR, системы SMTP НЕ ДОЛЖНЫ использовать какие-либо адресные записи RR, связанные с этим именем, если только они не расположены с использованием записей MX RR; правило "неявного MX" выше применяется только
если отсутствуют записи MX. Если записи MX присутствуют, но
ни один из них не может использоваться, эта ситуация ДОЛЖНА быть сообщена как ошибка.

Когда выполняется поиск доменного имени, связанного с MX RR, и
получено связанное поле данных, поле данных этого ответа ДОЛЖНО
содержат доменное имя. Это доменное имя при запросе ДОЛЖНО вернуть
хотя бы одна адресная запись (например, A или AAAA RR), которая дает IP
адрес SMTP-сервера, на который должно быть направлено сообщение.
Любой другой ответ, в частности, включая значение, которое будет возвращать запись CNAME при запросе, выходит за рамки настоящего стандарта.
Запрет на метки в данных, которые разрешаются в CNAME, является
более подробно обсуждается в RFC 2181, раздел 10.3 [38].

Поскольку почтовые серверы поддерживают возможность интеллектуального хостинга для IP-адреса, я не понимаю, как интеллектуальный хостинг для записи A может быть нарушением.

Это, очевидно, относится к почтовым серверам, пытающимся доставить почту по назначению. Это совершенно не имеет отношения к ситуациям, когда вы доставляете всю почту на смарт-хост; смарт-хост, которому вы доставляете, отвечает за это, а вы - нет.

И я нет. Ваш сервер не доставляет электронное письмо напрямую. Он передает его >> умному хосту для доставки

Таким образом, даже если это доставка смарт-хоста, вам не следует использовать .local для helo. .local (.lan) - это зарезервированные имена для mDNS Apple. (zeroconf)

В вашем случае вы неверны и всегда должны быть разрешаемым именем хоста.

Если поиск MX выполняется на основе .local, это ошибки ... поскольку он не может найти ваше имя хоста на принимающем сервере.

И в зависимости от настройки почтового сервера, на который вы пересылаете, это разрешено. Это зависит от используемого провайдера.

Имя клиента также должно быть разрешаемым, но поскольку многие люди неправильно настраивают DNS и забывают PTR, немногие блокируются на «неизвестных» именах хостов.

в вашем случае ваш сервер никогда не сможет отправлять электронную почту на мои серверы. Они все проверяют правильность DNS и разрешаемое имя хоста helo.

И все больше серверов делают это, почему этот параметр спасает меня примерно от 80% спама. Так что исправьте свое имя хоста или не запускайте почтовый сервер.