Контекст.
У меня есть несколько веб-сервисов доменов, размещенных в капле Digital Ocean (Ubuntu и Nginx в стеке). Судя по всему, DO автоматически устанавливает PTR-запись. Однако когда я спрашиваю
host <IP_ADDRESS>
[...] not found: 3(NXDOMAIN)
Капля использует постфикс, настроенный как где inet_interfaces = all inet_protocols=ipv4, пока mydestination включает домены размещенных веб-служб (как с префиксом www, так и без него). Эти домены отправляют электронную почту через sendmail и хост, определенный как scheduler.sending.ws
DNS и почтовая служба запускаются через второго провайдера (который НЕ является регистратором записи для домена второго уровня). Прежде всего я заметил, что запись A указывает на правильный IP-адрес, но с опечаткой schedule.sending.ws Это можно исправить, хотя я не уверен, что это полностью уместно.
Запись MX правильно указывает на второго провайдера mail.sending.ws Также есть две записи TXT для @ и admin указывает на v=spf1 a mx ptr include:someserver.net ~all.
Это приводит к созданию писем со следующим заголовком с случайный домен, определенный в mydestination постфиксного файла main.cf:
Received: from www.other.ws ([IP_ADDRESS]:46818)
Таким образом, две разные выдающие ссылки, ситуация, которая может быть легко помечена как спам.
извините, пожалуйста, за мое полное замешательство и нарушение протокола, когда я задаю несколько вопросов
Мое настоящее предположение таково:
а) нужно ли установить новую запись TXT DNS для домена выдачи, например: v=spf1 a mx include:scheduler.sending.ws include:someserver.net ~all ?
б) если а) верно, естественно, запись А должна быть исправлена
c) несоответствие в заголовках еще предстоит устранить. Но это, безусловно, должно быть указано приложением (и, следовательно, конкретным доменом), готовящим электронное письмо с одним из доменов, определенных для постфикса ... будет ли постфикс подыгрывать?
отсутствуют ли какие-либо данные для правильного решения этой проблемы?
В общей ситуации вам действительно следует следовать некоторым руководствам, чтобы создать рабочую базовую настройку, вместо того, чтобы пробовать случайные конфигурации с недостаточным пониманием того, как работает электронная почта. В конце концов, администрирование почтовой системы - сложная задача в наши дни. Тем, у кого нет большого опыта и особых потребностей в собственном почтовом сервере, рекомендуется использовать внешний сервис, который имеет все необходимые системы предотвращения спама и обработки репутации отправителя из коробки.
Чтобы ответить на ваши отдельные вопросы и дать рекомендации по изучению лежащих в основе технологий. В этом ответе давайте использовать www.example.com. A 192.0.2.1 как веб-сервер и mail.example.com. A 192.0.2.2 как почтовый сервер для входящей почты. Обоим нужно отправить почту, но только mail.example.com получает это, верно?
а) Нет. SPF include механизм не для этой цели. include:scheduler.example.com означает, что есть другие правила, т.е. другая запись SPF в scheduler.example.com. TXT. Поскольку такой записи, вероятно, нет, это вызовет PermError, что может привести к отклонению сообщения.
Запись SPF должна разрешать все серверы, которые будут отправлять почту для соответствующего имени хоста. Если вы используете example.comу тебя есть это на example.com. TXT, для www.example.com. на www.example.com. TXT. Рекомендуется использовать ip4 и ip6 механизмы, когда это возможно, так как при проверке SPF требуется меньше DNS-запросов. Это приведет к:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
www.example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
б) Для доставки входящей почты, scheduler.example.com. A не имеет значения, если он не использовался в качестве почтовый обменник например example.com. MX scheduler.example.com., но, вероятно, есть только mail.example.com. если вы используете его как HELO имя хоста, у вас должно быть A запись, чтобы избежать Несоответствие баннера SMTP.
в) HELO имя хоста соответствует параметру конфигурации Postfix smtpd_banner. По умолчанию он имеет myhostname как переменная, т.е. такая же, как у вас myhostname. В mydestination не имеет к этому никакого отношения, и ничто не выбирает случайное имя хоста из этой настройки: оно предназначено для доставки почты, а не для ее отправки.
В HELO имя хоста требуется для соответствия A запись и рекомендуется быть таким же, как PTR для IP-адреса. Не обязательно совпадать отправитель конверта домен, ни From: адрес заголовка. На многодоменном почтовом сервере это тоже было бы невозможно.
Для проблем со здоровьем почтового домена рекомендуется использовать реальный домен, чтобы мы могли проверить, что происходит. Этот вопрос широкий и неопределенный: дать точный или общий ответ невозможно.