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

Как мне настроить обратный DNS для 2 почтовых серверов?

У меня есть интересный вопрос о DNS (по крайней мере, интересный для меня).

Я только что установил сервер hmail в нашем удаленном офисе, чтобы он работал как резервная копия MX на случай, если наш сервер обмена выйдет из строя.

Два имени хоста:

mail.campbellsurvey.com mail2.campbellsurvey.com

mail указывает на адрес 98.XXX.91.XXX mail2 указывает на адрес 70.XXX.190.XXX

Как мне настроить запись PTR на стороне провайдера, чтобы отразить оба имени хоста?

ОБНОВИТЬ

Я действительно узнал от своего интернет-провайдера, что у меня не может быть резервного MX в офисе, где я хотел. Причина в том, что у нашего соединения в офисе динамический IP, и они не назначают PTR адресу. Так что этот вопрос был полезен с точки зрения информации, но в физическом смысле он провален. В любом случае спасибо всем.

Должен ли PTR указывать ТОЧНО на mail.campbellsurvey.com или может указывать только на campbellsurvey.com?

потому что сейчас все, что проходит через основной статический адрес в нашем пуле (тот, который используется для стандартного Интернета), идентифицируется как mail.campbellsurvey.com. Моя единственная идея исправить это состояла в том, чтобы переместить почтовый сервер на следующий доступный адрес и дать ему только имя mail.campbellsurvey.com, но я хотел посмотреть, есть ли другой способ.

Заранее спасибо.

Хотя в этом нет ничего страшного, ваши записи PTR не должен точно соответствовать (или даже отдаленно напоминать) имя вашего почтового домена. Конечно, на принимающих серверах нет причин, чтобы они что-то совпадали. Отправители будут подключаться к IP-адресам, определенным вашими записями MX, по порядку. PTR не входят в это.

Если оба эти сервера принадлежат вам, настройте их с помощью PTR, который идентифицирует их имена хостов; ничего более. Если у этих хостов есть другие обязанности или один из них является вашим основным шлюзом, то тот факт, что они называются bert.campbellsurvey.com и ernie.campbellsurvey.com (или что-то еще) не будет проблемой. Если вы используете общий хост или другого провайдера, у которого вы не можете установить PTR, то это тоже не проблема.

Вкратце: записи PTR не имеют отношения к предоставлению почты, так что вам не о чем беспокоиться.

РЕДАКТИРОВАТЬ

Чтобы прояснить то, что я говорю, и исправить некоторые заблуждения.

Получение почты:

Вы указали две записи MX. Что-то вроде:

mail1.campbellsurvey.com          IN    MX   10    1.2.3.4
mail2.campbellsurvey.com          IN    MX   20    1.2.3.5

Отправитель будет искать эти IP-адреса и пытаться подключиться к ним в порядке предпочтения, чтобы доставить ваше сообщение.

Отправка почты:

Ваш MTA будет делать то же самое при отправке почты в другие домены. Когда он подключается к mail1.example.com первое, что он отправит, будет некий вариант:

EHLO mta.campbellsurvey.com

Он будет подключаться с IP-адреса, который является точкой выхода в вашей сети. (Возможно: gateway.campbellsurvey.com). IP-адрес этого шлюза будет иметь соответствующую запись PTR.

8.7.6.5.in-addr.arpa. 86341 IN    PTR    gateway.campbellsurvey.com

Если вы управляете этими IP-адресами, то большинство интернет-провайдеров позволят вам установить запись PTR в соответствии с основным именем вашего домена.

Имея это в виду, применяется следующее:

  • Я думаю, все согласны с тем, что PTR ваших MX вообще не влияют на вашу способность получать почту.

  • При отправке домен 2-го уровня (campbellsurvey.com) указанный на вашем EHLO приветствие должно соответствовать вашему домену электронной почты. Это разумная мера защиты от спама.

  • Обычно рекомендуется устанавливать записи PTR для любых контролируемых вами IP-адресов на первичное имя хоста машины, на которой находится этот IP-адрес.

  • Записи SPF (если вы их публикуете) должны указывать PTR-запись и / или IP-адрес всех ваших отправляющих серверов. Это позволяет серверам отклонять сообщения, которые якобы принадлежат вашему домену, от всего, чего нет в этом списке.

    • Если получающий почтовый сервер находит опубликованную запись SPF для вашего домена, а отправляющий IP-адрес или его PTR не соответствуют тому, что вы указали в качестве легитимного почтового сервера, он, скорее всего, отклонит ваше сообщение. Это то, для чего нужен SPF.

  • Если принимающий сервер ищет PTR-запись вашего отправляющего IP-адреса и отклоняет ее, поскольку она не соответствует вашему почтовому домену, тогда он сломан. Эта мера отклонит законную почту.

    • Если он отклоняет, потому что PTR не именно соответствие, тогда это очень сломано. Эта мера отклонит лоты законной почты
    • Если это был допустимый метод для блокировки спама, тогда каждый общий почтовый хост (Google, Rackspace, выберите ваш выбор) должен иметь отдельный IP-адрес и настраиваемый PTR для каждого домена, который они размещают. Это было бы глупо.

@Solignis: Извините, что украл ваш исходный вопрос, который касался только ваших записей MX, но я подумал, что это нужно прояснить.

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

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

Вам нужны следующие записи PTR:

98.103.91.146     mail.campbellsurvey.com 
70.XXX.190.XXX    mail2.campbellsurvey.com

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

РЕДАКТИРОВАТЬ: Итак, если бы я отправлял почту с example.com, но PTR моего отправителя разрешился на mta532.mail.google.com или some.other.thing12.smtp.rackspace.com или canner46.blah.brightmail.com, вы бы не доверяли мое сообщение?

rDSN не распространяется на домен на адресе отправителя. Если ваш адрес конверта - something@example.com, я бы проверил запись SPF для example.com. Если на example.com была запись SPF с -all политика, я бы отказался от вашей электронной почты. В противном случае оно будет принято, если иное не помечено как спам.

Если бы ваш сервер утверждал, что это mail.example.com, это вызвало бы некоторые действия с моей стороны, предназначенные для определения, является ли ваш сервер спам-ботом, что, скорее всего, так и будет. Отсутствие действующей настройки rDNS также увеличило бы споры спама. У меня есть отдельные лимиты для радиолюбителей (вряд ли это спам) и спама. Сообщения, попадающие в эти пределы, почти полностью представляют собой электронную почту от автоматизированных систем и спам. В индивидуальных письмах, которые я получаю, почти всегда есть правильный rDNS для одного или обоих IP-адреса и имени, используемых в команде HELO.

Если DNS-серверы не отвечают ни на один из запросов DNS, необходимых для проверки статуса rDNS вашего IP-адреса, я выдаю softfail. Недавно я обнаружил, что это успешно блокирует изрядное количество спам-ботов. Еще несколько месяцев назад это правило редко срабатывало. Я полагаю, что ряд интернет-провайдеров настроили там rDNS для отказа для динамических диапазонов адресов. Если вы, я ценю их усилия по сокращению спама.

Я не совсем уверен, что SmallClanger подразумевает под «почтовым подтверждением» в заявлении «PTR-записи не имеют никакого отношения к почтовому обеспечению». Но это, безусловно, правда, что PTR-записи не должны влиять на способность ваших серверов получать почту.

Другой MTA, который пытается вам отправить, не заботится о ваших записях PTR.

Это когда ваш серверы отправляют сообщения, которые вы хотите, чтобы они соответствовали. Итак, вам нужны записи SPF, которые определяют оба ваших почтовых сервера.