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

DNS и PTR для SMTP: общие IP-адреса и поддомены

Этот вопрос похож на другие вопросы о PTR и DNS для SMTP, но остался без ответа один конкретный аспект: что, если одна машина выполняет SMTP и HTTP на одном IP-адресе. Например:

SMTP на mail.example.com, также HELO. (1.2.3.4) HTTP на www.example.com (1.2.3.4) общий доступ, например ssh на example.com (1.2.3.4)

Каковы требования, чтобы PTR-запись на адресе 1.2.3.4 принималась спам-фильтрами? «Основное» имя хоста для 1.2.3.4 - example.com, но если обратный поиск DNS требует точного совпадения, я должен установить его на mail.example.com. Это глупо. Я имею в виду, что обратный поиск 66.102.13.106 не приводит к mail.google.com.

Или достаточно, если обратный поиск находит на нем example.com и mail.example.com как записи MX? Другими словами, должен ли я установить PTR на example.com?

Можно было бы возразить, что я должен сделать доступ SMTP и HELO example.com, но это вызывает негибкость, потому что тогда я никогда не смогу перенести SMTP на другую машину, просто изменив запись A.

Изменить: кажется неясным, что я имею в виду, поэтому позвольте мне уточнить:

Рассматриваемый сервер содержит DNS, SMTP, WWW и многое другое. У него есть собственный DNS. Example.com указывает на этот компьютер, скажем, 1.2.3.4. Поскольку почта не является его основным делом, я не хочу, чтобы 1.2.3.4 отменяла преобразование в mail.example.com

На сервере работает postfix, а его HELO - mail.example.com, что также указывает на 1.2.3.4. Чтобы PTR соответствовал, 1.2.3.4 должен преобразовать разрешение в mail.example.com, но, как я уже сказал, я хочу, чтобы он разрешался в example.com, потому что почта не является основной задачей сервера.

Означает ли это, что мне нужно изменить имя почты на example.com, и наличие его на mail.example.com приведет к тому, что некоторые спам-фильтры отклонят его, даже если почта является mx-записью example.com?

  • Вы можете иметь столько записей A RR, сколько хотите, чтобы указать на 1.2.3.4.
  • У вас должна быть одна точка PTR на имя.
  • Поэтому все, что вам нужно, это убедиться, что PTR указывает на желаемое имя, а это имя указывает на 1.2.3.4.

Это означает, что у вас может быть:

example.com. IN A 1.2.3.4

example.com. В MX 10 mail.example.com.

server.example.com. IN A 1.2.3.4

www.example.com. IN A 1.2.3.4

mail.example.com. IN A 1.2.3.4

и:

4.3.2.1.in-addr.arpa. В PTR server.example.com.

Почему это требование? Потому что, когда ваш SMTP-сервер подключается к удаленному SMTP-серверу для доставки почты, SMTP-сервер знает только адрес вашего сервера, а не имя. Имея под рукой адрес (1.2.3.4), он запрашивает DNS и получает ответ PTR (server.example.com). Теперь удаленный сервер снова спросит DNS: «Какой адрес server.example.com?» И ожидает, что ответ будет 1.2.3.4.

То, что вы отправляете в строке HELO, не должно вас пугать. Вы можете прочитать о цель SMTP HELO и узнайте об исключениях, в которых разрешена блокировка на основе того, что указано в строке HELO.

HTTP-сервисам не обязательно иметь соответствующий PTR запись. SMTP работает, и он всегда должен соответствовать ответу прямого разрешения.

Ваш A запись для домена не обязательно должна соответствовать записи MX, например:

@     IN A   1.2.3.4
      IN MX  10 mail
mail  IN A   1.2.3.5

Совершенно верно.

По дизайну приложений постарайтесь найти ваш MX записи, но если он не установлен, они возвращаются к вашему A запись. Это та часть, где играет роль гибкость, как вы ее называете. Ошибка не указать MX запишите, если вы действующий SMTP.

Спам-фильтры обычно всегда отбрасывают вам почту (или присваивают большое значение / тег), если ваш PTR не совпадает с вашим именем хоста для вашего исходящего SMTP-сервера. Вы должны установить его на mail.example.com, если ваш MX относится к mail.example.com.

Обычно ваш вертолет должен также относиться к вашему PTR/MX так как это еще один тест для вашего сервера, чтобы получить низкий балл в фильтрах спама и не быть помеченным как спам.

ИЗМЕНИТЬ:

После вашего редактирования не имеет значения, какова его основная цель. Важно то, что вам нужно, чтобы не получить высокий рейтинг спама на вашем MX.

Тем не менее, ваш MX не должен указывать на mail.example.com, вы могли бы сказать:

@ IN A 1.2.3.4 IN MX example.com.

Это синтаксис Bind, и обратите внимание, что у example.com в конце есть точка. Вы можете попробовать это, если отчаялись и вам нужно зарегистрировать свой PTR как example.com и быть согласованным с HELO.

Обычно вы отделяете HTT от SMTP / сети.

  • При необходимости добавляются домены для HTTP. Все, что они делают, это указывают на сервер или CNAME имя сервера и настраивают соответствующий заголовок хоста для IIS.
  • У сервера есть собственное имя хоста в основном в домене хостера (server1.thehoster.com). Как и в первом ответе, www.customerdomain.com может быть CNAME для server1.thehoster.com.
  • Для SMTP важно, чтобы указатели вперед и назад были идентичны. Таким образом, при подключении SMTP сервер будет идентифицироваться как server1.thehoster.com (ВОЗМОЖНО ТОЛЬКО ОДНО ИМЯ), а запись PTR будет преобразована в server1.thehoster.com. Домены, используемые для доступа в Интернет, сюда вообще не входят.

Вам не требуется предоставлять запись MX для своего домена. Если запись MX отсутствует, MTA должен использовать запись A вашего домена для доставки почты.

Однако это приведет к тому, что значительное количество спам-фильтров будет отмечать почту, исходящую из вашего домена, как возможную спам.

Так что, даже если почта не является вашей «основной задачей», вы, вероятно, все равно хотите, чтобы спам-фильтры были довольны. Для этого ваша зона должна выглядеть так:

@                      IN A     1.2.3.4
                       IN MX 10 mail
mail                   IN A     1.2.3.4
1.2.3.4.in-addr.arpa.  IN PTR   mail