Мой сервер исходящей почты не может связаться с некоторыми получателями. Это произошло после того, как мы изменились Интернет-провайдер для нашего выделенного IP-адреса. Я думаю, это могло быть из-за PTR записи, но я не могу быть уверен.
Мой назначенный IP-адрес x.y.z.112/29. Когда я делаю nslookup на x.y.z.114 (WANлицом к публичному IP-адресу), он дает 114.x-y-z.myisp.com. Правильно ли я говорю, что для моего IP-адреса действительно существует запись PTR, только она не соответствует моему MX mail.mycompany.com. (x.y.z.115)? **
Я также узнал, что степень, в которой почтовые серверы проверяют записи PTR, варьируется. Некоторые только проверяют, что обратный поиск DNS (rDNS) имя хоста существуют, в то время как некоторые идут до конца, гарантируя, что MX и имя хоста rDNS совпадает. Так что я должен делать? Должен ли я по-прежнему указывать своему интернет-провайдеру устанавливать записи PTR для mail.mycompany.com?
Итак, теперь моя запись PTR разрешается 114.x-y-z.myisp.com чья А разрешается в тот же IP-адрес, что и запись PTR. Так что же это говорит об адресе электронной почты отправителя?
Сначала ответьте на ваш новый вопрос: нет, PTR ничего не говорят вам о домене отправителя. См. Объяснение ниже.
Теперь вернемся к исходному вопросу:
Принимающие почтовые серверы не проверяют ни одно, ни одно, многие или все из следующего:
Приемные почтовые серверы, которые проверяют, является ли отправляющий сервер также сервером MX, плохо настроены и должны быть удалены из Интернета.
Редактировать: PTR абсолютно ничего не доказывает о домене электронной почты. Это никогда не доказывает. Тысячи доменов размещены в Google, Amazon, AOL и других. Но ни один из них не соответствует имени хоста или PTR Google, Amazon, AOL и других. У всех есть имена серверов провайдеров. И в этом нет ничего плохого.
PTR только подтверждает подлинность сервера, но не идентичность размещенных доменов. Точка.
2-е редактирование: Хорошим примером рабочей среды может быть
Теперь у вас есть общая запись PTR, но все же имеет смысл изменить ее на имя вашего сервера.
Зачем?
Вы правы в том, что вам назначена запись PTR, и многие почтовые системы сегодня отклоняют электронную почту из источников без обратных записей PTR. Вы пропустили одно условие: большое количество почтовых хостов / спам-фильтров имеют тенденцию отклонять трафик от отправляющих серверов, чьи обратные записи PTR являются «слишком общими». Сюда входят хосты, у которых обратный PTR in-addr.arpa... формат или содержит IP-адрес в имени. Ваш последний случай в этом 114.x-y-z.myisp.com это просто заполнитель, установленный вашим интернет-провайдером. Вам не нужно, чтобы ваше обратное совпадение совпадало с названием вашей компании (хотя вы также можете сделать это совпадением, если сможете). Это просто должно быть полное доменное имя (FQDN).
Из Руководство AOL Postmaster:
Обратный DNS - это способ связать IP-адрес с его именем хоста. Обратный идентификатор DNS содержится в части PTR файла зоны IP. Файл зоны IP содержит все способы, которыми могут быть связаны ваш IP-адрес и доменное имя; каждая ассоциация обслуживает разные потребности.
Это доказывает, что вы такой, какой вы себя называете.
Вот сценарий. Допустим, я пытаюсь рассылать спам под видом Gmail. Я не Gmail, я просто какой-то убогий с VPS, с контролем моего собственного DNS.
Я могу установить PTR любого IP-адреса, принадлежащего мне mail.google.com. Но делая A смотреть на mail.google.com не будет отображать мой IP-адрес, он будет отображать IP-адреса Google. Несоответствие означает, что вы лжете.
Обновить: Немного истории и пояснения.
Вы должны знать, что ничего из этого не сработает.
Электронная почта была изобретена в 1961 году. Это произошло вскоре после того, как было подсчитано, что всему миру нужно всего пять компьютеров.
Популярность электронной почты резко возросла в начале 80-х с появлением в UNIX стека TCP / IP. В то время каждый хост в Интернете был либо правительством США, либо университетом, либо очень большой корпорацией. Тогда все были друзьями. Первый червь был создан только в 1988 году. Никто не думал, что кто-нибудь когда-либо сделает что-нибудь злонамеренное, потому что это было чрезвычайно (по сегодняшним меркам) небольшое сообщество, и почти все знали всех.
Было создано много протоколов, которые нас смущают сегодня. Среди них ftp, telnet, rsh, rlogin, nfs и smtp. SMTP, как и многие другие протоколы, был создан с никакой безопасности. Предполагалось, что все, что вы сказали, было правдой, потому что зачем кому-то лгать?
Однажды какой-то предприимчивый чмо решил написать письмо кучке людей, которые этого не хотели, и спам был рожден. С тех пор мы ведем постоянно проигрышную битву со спамом.
Проблема спама настолько серьезна, что любой и все тактика, которая снизит спам даже на малейшую долю процента, означает, что нагрузка на наши почтовые серверы упадет значительно. Однажды я проверил свой почтовый сервер, и сообщения, которые он обрабатывал, были на 99% спамом.
Администраторы отчаянно нуждаются в что-нибудь что поможет даже малейший степень. Все, что кто-либо слышал, помогало «на тот раз», становится стандартной практикой в борьбе со спамом. Не то чтобы какая-то одна тактика особенно эффективна. Но в наши дни мы устанавливаем как можно больше ограничений на ретрансляцию почты в надежде укрепить позиции в борьбе со спамом.
Панацеи от спама не существует. Но даже такая простейшая проверка может означать разницу в количестве отправленных сообщений на миллионы меньше.
Вы все правильно поняли. Запись PTR для IP-адреса вашего почтового сервера не соответствует имени хоста, под которым ваш почтовый сервер идентифицирует себя. Было бы хорошо, если бы провайдер изменил запись PTR, чтобы она соответствовала исходящей FQDN вашего почтового сервера.
Не совсем верно то, что принимающие серверы проверяют соответствие записей PTR и MX, потому что это глупый поступок. Запись MX указывает, куда идет электронная почта, а не откуда она приходит. An SPF запись обозначает, откуда приходит электронная почта. Любой почтовый сервер, проверяющий соответствие записи PTR записи MX перед приемом электронной почты с этого сервера, делает это неправильно.
Хотя это и не обязательно, рекомендуется настроить запись PTR для отправляющего почтового сервера, которая соответствует DNS пересылки для отправляющего почтового сервера. Это дает некоторое представление о том, что отправляющий сервер является надлежащим хостом своего домена (вы можете указать DNS-запись на любом хосте), и что администратор не беспечен или невежественен.
Если у вас начались проблемы после смены IP-адресов, вы можете убедиться, что IP-адрес вашего почтового сервера не включен ни в какие RBL (черные списки в реальном времени). Чтобы проверить наиболее распространенные списки, вы можете ввести IP-адрес почтового сервера в поле RBL чекер на anti-abuse.org.
Все эти люди правы. Нравится ли вам или понимаете почему, если вы хотите надежно отправлять электронную почту, вы убедитесь, что имя helo / A / PTR одинаково для всех. Неважно, с какого домена вы отправляете почту, но хост, отправляющий электронную почту, должен иметь свой DNS-дом, так сказать.
HELO name = имя, которое почтовый сервер сообщает о себе при приветствии удаленного SMTP-сервера:
[spork@hc1:/tmp]$ telnet example.com 25
Trying 127.0.0.1...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Postfix <<<--- remote server
HELO someserver.jake.com <<<--- your server using it's HELO name
250 example.com <<<--- remote server answering
Запись = опубликованное DNS-имя вашего почтового сервера (не обязательно совпадать с доменом, с которого вы отправляете электронную почту). пример: jake.com = 10.10.10.2
Запись PTR = должна соответствовать записи A сервера. пример: 10.10.10.2 = jake.com
Вы проделаете долгий путь к лучшей доставляемости, убедившись, что эти три вещи совпадают.
Имейте в виду, что фильтрация спама в значительной степени зависит от оценки общей скрытности хоста, который подключается к mxer. Несоблюдение общепринятой практики - это довольно большой красный флаг. Если системный администратор не может правильно настроить DNS, что еще может быть не так с сервером, который собирается отправить вам электронное письмо? В наши дни достаточно критической массы, поэтому не стоит бороться с тем, что сейчас является BCP, даже если для вас это не совсем понятно.
Что касается отклонения электронной почты с IP-адресов с «общими» PTR, это тоже не редкость, даже если ваша тройка конфигураций, связанных с DNS, упомянутых выше, все согласна. Опять же, удаленный хост смотрит на этот общий DNS и предполагает, что общий означает «случайный домашний пользователь», что, в свою очередь, означает, что вы скорее разговариваете с ботом, чем с реальным почтовым сервером.
Я знаю, что это старый разговор, я просто хотел добавить свои итоги на два цента ... Большинство обратных проверок имеют это общее: они проверяют что-то как из прямого домена DNS, так и из обратного домена (например, IP подсеть). Эти два домена обычно не контролируются одним и тем же объектом, особенно когда кто-то пытается маскироваться под другой домен. -Поэтому одному объекту сложно согласовать записи в обоих доменах друг с другом, поскольку они, как правило, будут владеть только обратным доменом или прямым, но не обоими одновременно. В то время как в допустимых ситуациях вы можете попросить другого администратора домена также внести соответствующие изменения на своей стороне.