Умный хостинг к запись нарушение раздела RFC 5321 1?
Мне настроили sendmail сервер к smarthost к нисходящему ресурсу. Конфигурация в настоящее время:
define(`SMART_HOST',`relay:[vip.example.local]')dnl
Так как это отправляет A запись для vip.example.local. Мне сказали, что это - нарушение раздела IETF RFC 5321 5.1, который указывает:
После того как клиент SMTP лексически определяет домен, к которому будет почта
поставьте для обработки (как описано в Разделах 2.3.5 и 3.6), поиск DNS ДОЛЖЕН быть выполнен для разрешения доменного имени (RFC 1035
[2]). Имена, как ожидают, будут полностью определенными доменными именами
(FQDNs): механизмы для выведения FQDNs с частичных имен или локальный
псевдонимы за пределами этой спецификации. Из-за истории
проблемы, серверы SMTP, используемые для начального представления сообщений, не ДОЛЖНЫ делать такие выводы (Серверы Отправки сообщения [18] имеют
несколько больше гибкости), и промежуточные (релейные) серверы SMTP не ДОЛЖНЫ делать их.Поиск сначала пытается определить местоположение записи MX, связанной с именем. Если запись CNAME найдена, получающееся имя обрабатывается, как будто это было начальное имя. Если несуществующая доменная ошибка возвращается, об этой ситуации НУЖНО сообщить как ошибка. Если нерегулярная ошибка возвращается, сообщение ДОЛЖНО быть поставлено в очередь и повторено позже (см. Раздел 4.5.4.1). Если пустой список MXs возвращается, адрес рассматривают, как будто он был связан с неявным MX RR, с предпочтением 0, указав на тот хост. Если записи MX присутствуют, но ни один из них не применим, или неявный MX неприменим, об этой ситуации НУЖНО сообщить как ошибка.
Если один или несколько, MX, которым RRs найдены для имени, системы SMTP, не ДОЛЖЕН использовать адрес RRs, связанный с тем именем, если они не расположены с помощью RRs MX; "неявный MX" правило выше применяется только
при отсутствии существующих записей MX. Если записи MX присутствуют, но
ни один из них не применим, об этой ситуации НУЖНО сообщить как ошибка.Когда доменное имя, связанное с RR MX, ищется и
связанное поле данных получило, поле данных того ответа ДОЛЖНО
содержите доменное имя. То доменное имя при запросах ДОЛЖНО возвратиться
по крайней мере одна запись адреса (например, A или RR AAAA), который дает IP
адрес сервера SMTP, к которому должно быть направлено сообщение.
Любой другой ответ, конкретно включая значение, которое возвратит запись CNAME при запросах находится вне объема этого Стандарта.
Запрет на маркировки в данных, которые решают к CNAMEs,
обсужденный более подробно в RFC 2181, Раздел 10.3 [38].
Так как почтовые серверы поддерживают опцию к умному хосту IP, я не понимаю, как smarthosting к запись мог быть нарушением.
Это, очевидно, относится к почтовым серверам, пытающимся доставить почту по назначению. Это совершенно не имеет отношения к ситуациям, когда вы доставляете всю почту на смарт-хост; умный хост, которому вы доставляете, отвечает за это, а вы - нет.
Я тоже. Ваш сервер не доставляет электронную почту напрямую. Он передает его >> на smarthost для доставки
Так что, даже если это смарт-хост доставки, вы не должны использовать .local для helo. .local (.lan) - это зарезервированные имена для mDNS компании Apple. (zeroconf)
В вашем случае, helo не является правильным и всегда должно быть разрешимым именем хоста.
Если MX-поиск выполняется на основе .local wel, то это ошибка... так как он не может найти ваше имя хоста на сервере-приемнике.
И, основываясь на настройках почтового сервера, где ваша переадресация разрешена. Это зависит от используемого провайдера.
Имя клиента, также должно быть разрешимым, но так как многие люди неправильно настраивают dns и забывают PTR, не так уж много блоков на "неизвестных" именах хостов.
В вашем случае, ваш сервер никогда не сможет отправлять электронную почту на мои серверы. Они проверяют правильность DNS и разрешаемое имя хоста helo.
И больше серверов делают это, почему, эта настройка экономит мне около 80% спама. Так что исправьте свое имя хоста helo или не запускайте почтовый сервер.