Вопросы Теги

DNS и PTR для SMTP: общий дюйм/с и субдомены

Я не знающий об этом, но это могло быть различием на как Ваш дескриптор материнской платы оба завершения работы.
Первый, нормальное завершение работы, вероятно, сохраняет контроллер Ethernet приводимым в действие, чтобы заставить его обработать пакет WOL, в то время как трудное завершение работы было бы completly непитание все устройство.

2
задан 22 October 2010 в 13:27
4 ответа

HTTP Services не должна иметь соответствия 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, Вы могли сказать:

В 1.2.3.4 В MX example.com.

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

1
ответ дан 3 December 2019 в 11:09
  • 1
    , я думаю, что Вы неправильно поняли меня. Я знаю, что у меня должна быть запись MX для входящей корреспонденции, и я знаю, что это не необходимо, чтобы HTTP имел запись PTR. Запись PTR для исходящей почты. Это просто, что реверс, разрешая IP-адрес сервера не должен приводить к mail.example.com, но к example.com, потому что иначе это предположило бы, что mail.example.com, это - основное имя хоста, где в действительности это - только одни из имен хостов, машина доступна на. Но если я делаю это, HELO и инвертирую DNS, не соответствуют. Так следовательно мой вопрос, если то совпадение должно быть точным или нет. –  Halfgaar 22 October 2010 в 13:00
  • 2
    Именно поэтому я объясняемый, что Ваш запись для example.com не имела никакого отношения записи к MX. В случае, если они тем же, быть все еще без проблем ("почта в 1.2.3.4" и "в 1.2.3.4"). Обратный поиск просто тем, в чем Вы нуждающиеся, и единственная вещь, которая требовала, чтобы Вы, чтобы иметь PTR MX. HELO указывает на это. Основное имя хоста ищет, "рыть example.com" (или nslookup query=a). Если то, что Вы имеет, многоцелевым полем (или IP) как в HTTP, SMTP, и т.д., то просто думать нем как, что сервисами, который нуждающийся в PTR, не который домен это серверы для его сервисов. –  Torian 22 October 2010 в 13:26
  • Вы можете иметь как много RRs, поскольку Вы хотите точку к 1.2.3.4.
  • У Вас должна быть одна точка PTR назад к имени.
  • Поэтому все, в чем Вы нуждаетесь, должно удостовериться, что PTR указывает на имя, которое Вы хотите и что это имя указывает назад на 1.2.3.4.

Это означает, что Вы можете иметь:

example.com. В 1.2.3.4

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

server.example.com. В 1.2.3.4

www.example.com. В 1.2.3.4

mail.example.com. В 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, не должно пугать Вас. Можно читать о цели HELO SMTP и найти об исключениях, где позволяется заблокироваться на основе того, что дано в строке HELO.

2
ответ дан 3 December 2019 в 11:09

Обычно Вы отделяете HTT от SMTP / Сеть.

  • Домены для HTTP добавляются по мере необходимости. Все, что они делают, указать на сервер или CNAME на имя сервера, и иметь соответствующий заголовок хоста, настроенный для IIS.
  • Сервер имеет свое собственное имя хоста главным образом в hoster домене (server1.thehoster.com). Как в первом ответе, www.customerdomain.com может быть CNAME на server1.thehoster.com
  • Для SMTP важно, чтобы вперед и указатели возврата были идентичны. Так, на Соединении SMTP сервер идентифицирует как server1.thehoster.com (ТОЛЬКО ОДИН НАЗЫВАЕТ ВОЗМОЖНЫМИ), и запись PTR решит на server1.thehoster.com. Домены, используемые для веб-доступа, не входят здесь вообще.
0
ответ дан 3 December 2019 в 11:09

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

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

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

@                      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
0
ответ дан 3 December 2019 в 11:09

Теги

Похожие вопросы