ehlo fqdn в исходящей сессии почтовика

1.1.1.1.in-addr.arpa. in ptr fqdn

fqdn in a 1.1.1.1

org-site.ru. in mx 10 fqdn

fqdn = mail.org-site.ru

Спасибо за ответ, а можно чуть подробнее и менее техническим языком?

если реверс уже прописан, надо прописать имя почтового сервера в его настройках mail.domain и прописать прямой алиас mail.domain в своей прямой зоне и мх проверить.

Скажите а что подразумевается под своей прямой зоной, это имеется ввиду локальный DNS сервер организации?

mail.org-site.ru in a 1.1.1.1

во внешнем днс.

Скажите а что подразумевается под своей прямой зоной, это имеется ввиду локальный DNS сервер организации?

Ну примерно так должно:

root@mail:~# resolveip mail.org-site.ru
IP address of mail.org-site.ru is 111.111.111.111
root@mail:~# resolveip 111.111.111.111
Host name of 111.111.111.111 is mail.org-site.ru
root@mail:~#

Host name of 111.111.111.111 is eklmn-site.ru

У Вас с rDNS все в порядке. Нужно просто правильно заполнить MX-записи в Вашей прямой DNS-зоне.

resolveip показывает как раз то что нужно

resolveip mail.org-site.ru IP address of mail.org-site.ru is 111.111.111.111 resolveip 111.111.111.111 Host name of 111.111.111.111 is mail.org-site.ru

а MX выглядит следующим образом: org-site.ru MX mail.org-site.ru

Могут ли это быть некорректные настройки принимающей стороны?

Не понятна откуда это:

и некоторые почтовые сервера выдают «550 Sender IP reverse lookup rejected (in reply to RCPT TO command)»

Пошли письмо-тест например на mail.ru. Там посмотри исходный текст принятого. Вполне проблема в настройках почтовика.

И еще: resolveip или nslookup желательно проверять не с почтовика Он может подсунуть данные из своего файла host.

«550 Sender IP reverse lookup rejected (in reply to RCPT TO command)» это ошибка которую выдал сервер получатель

полный текст с исправлением имени реального на условное выглядит так

This is the mail system at host mail.org-site.ru.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<получатель@сервер_получателя.com>: host barracuda.chinookwebs.com[74.3.176.190] said:
    550 Sender IP reverse lookup rejected (in reply to RCPT TO command)



Reporting-MTA: dns; mail.org-site.ru
X-Postfix-Queue-ID: 3F7BC542174D
X-Postfix-Sender: rfc822; worstpilot@org-site.ru
Arrival-Date: Wed, 15 Aug 2018 14:28:53 +0300 (MSK)

Final-Recipient: rfc822; получатель@сервер_получателя.com
Original-Recipient: rfc822;получатель@сервер_получателя.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; barracuda.chinookwebs.com
Diagnostic-Code: smtp; 550 Sender IP reverse lookup rejected

затем сайт переехал на внешний хостинг, и теперь org-site.ru имеет условный адрес 222.222.222.222 а почтовый сервер теперь имеет DNS имя вида mail.org-site.ru который указывает на 111.111.111.111 и почтовый домен @org-site.ru

Reverse DNS 111.111.111.111 сейчас указывает на mail.org-site.ru

Вот если как написано, то точно всё хорошо, как уже написали.

Другой вопрос, так ли это видно снаружи? Надо через какой-нибудь 8.8.8.8 проверить. Ну и в helo отдаваться должен mail.org-site.ru, хотя в ошибке про helo не написано, на самом деле.

а MX выглядит следующим образом: org-site.ru MX mail.org-site.ru

Не уверен, что это значимо, но попробуйте приоритет добавить в MX-запись:

MX 10 mail.org-site.ru

Входящая почта, кстати, нормально доходит?

Короче. Пускай потестируют вас: https://mxtoolbox.com

Remote-MTA: dns; barracuda.chinookwebs.com

$ dig -t MX @8.8.8.8 chinookwebs.com. +short
10 barracuda.chinookwebs.com.
100 ice-42.chinookwebs.com.
20 mailsf.chinookwebs.com.

$ resolveip $(dig -t MX @8.8.8.8 chinookwebs.com. +short | sed 's/.* //')
IP address of mailsf.chinookwebs.com. is 74.3.176.71
IP address of barracuda.chinookwebs.com. is 74.3.176.190
resolveip: Unable to find hostid for 'ice-42.chinookwebs.com.': no_data

Не резолвится ice-42.chinookwebs.com.

Дык это же чина. :) Походу он и проводит обратную проверку сендера. Которую давно уже нормальные люди отключили на своих почтовиках. (Этой проверкой активно пользовались спамерюги.) Кстати прозвоните этих китайцев в https://mxtoolbox.com

Тоесть получается ice-42.chinookwebs.com виноват?

Тоесть получается ice-42.chinookwebs.com виноват?

При чём тут chinookwebs.com? Тебя дважды уже спросили, что про твой 111.111.111.111 говорит гугледнс? Который 8.8.8.8.

helo отдаваемый вашим почтовым сервером должен быть равен nslookup 222.222.222.222(реверс днс) и nslookup helo должен разрешаться в 222.222.222.222

Reverse DNS

у тебя не будет работать, это работает ТОЛЬКО у хостера/провайдера

у тебя не будет работать, это работает ТОЛЬКО у хостера/провайдера

хостер/провайдер уже мог ему это сделать. Надо же проверить.

Мог, да. Однако, практика показывает, что люди обычно про это попросту не в теме и поднимают реверс зону у себя. А потом ищут почему не работает.

google dns про 111.111.111.111 nslookup org-site.ru Adress 111.111.111.111

А вот запрос на IP Возвращает другое доменное имя nslookup 111.111.111.111 Возвращает домен отличный от org-site.ru

Но на 111.111.111.111 только сайт организации а нас интересует

222.222.222.222 который mail.org-site.ru у которого в обе стороны nslookup ится все корректно, или я чего-то не понимаю?)

helo при коннекте Telnet по smtp выводит mail.org-site.ru как положено, который резолвится как положено в 222.222.222.222

что-то ты запутал... Так. Гугль говорит, что mail.org-site.ru - это 222.222.222.222, а 222.222.222.222 - это mail.org-site.ru ? И в helo сервер отдаёт mail.org-site.ru ? Если так, то всё правильно настроено.

Только в начале написано, что mail.org-site.ru - это 111.111.111.111. Где правда?

Вы скорее всего зациклились. То, что rDNS возвращает адрес не mail.org.ru — это нормально. IP адресов заметно меньше, чем даже не хостов, а даже доменов. Главное, чтобы проходила проверка: вы представились хостом в hello, этот хост резольвят, на полученный IP находят ptr, и вот он уже должен резольвится снова в этот IP.

а что отдает nslookup 222.222.222.222 и резольвится-ли в адрес отдаваемое? helo должно быть равно nslookup 222.222.222.222

Система правил для отправки почты следующая

nsookup на результат nslookup ip адрес сервера = ip адрес сервера. helo = nslookup ip адрес сервера.

Для приема почты нужны dns записи типа MX. таких записей может быть несколько, каждая со своим приоритетом и именем сервера. MX запись указывает на имя сервера-получателя. Имя сервера для приема почты может быть любым, оно должно разрешаться в адрес сервера получателя.

Например

exampe.com. mx 10 srv.example.com. 
exampe.com. mx 20 serv.mydom.com.

srv.example.com. in a 1.1.1.1

И в домене mydom.com

 
serv.mydom.com. in a 2.2.2.2

Да вы правы, я запутал себя и вас, подтупил: mail.org-site.ru ссылается на 111.111.111.111 и резолвится в mail.org-site.ru и имеет на себе @org-site.ru

А вот org-site.ru резолвится в 222.222.222.222 а обратно резолвится в другое имя отличное от org-site.ru

Обратная зона была заменена звонком провайдеру в день переезда сайта на другой IP. Таким образом как описано в первом посте чтобы обратная зона резолвила mail.org-site.ru в обе стороны

Помогите пожалуйста сообразить как это должно выглядеть в моём случае применительно к моему первому посту?

Краткая иструкция по настройке имен для почтового сервера.

Вот понабирают по объявлению.

1) Выбираем героическое имя в своем домене(mydom.ru) для почтового сервера. например mysupermail.mydom.ru

2) Настраиваем smtp сервер , чтоб отдавал это в helo.

3) Идем к владельцу ip адреса и уговариваем его сделать ptr запись

 
выданный вам ip     ptr      mysupermail.mydom.ru.

4) Чтоб принимать почту лезем в настройки dns для mydom.ru делаем записи

mydom.ru.  mx 10 mysupermail.mydom.ru.

mysupermail.mydom.ru. in a выданный вам ip

5) Инструкции по настройке SPF, DKIM, DMARC искать самостоятельно.(уменьшает вероятность попадания в спам на gmail, mail и тд)

А вот org-site.ru резолвится в 222.222.222.222 а обратно резолвится в другое имя отличное от org-site.ru

Это никого не волнует, если он нигде не упоминается. Хоть вообще его не будет. А упоминаться он нигде не должен. Не зацикливайся на этом.

Главное, чтобы проходила проверка: вы представились хостом в hello, этот хост резольвят, на полученный IP находят ptr, и вот он уже должен резольвится снова в этот IP.

Это кто такое придумал? А почитать RFC 1123, раздел 5.2.5 HELO Command?

Это кто такое придумал?

Это кто проверяет валидность hello.

А почитать RFC 1123

И давно на антиспам пишут RFC?

Помогите пожалуйста сообразить как это должно выглядеть в моём случае применительно к моему первому посту?

Похоже вам можно помочь только если вы напишите свой реальный домен. Ибо всё что вы тут спрашиваете — путанный бред, либо описание того, что именно и должно быть и работать.

И давно на антиспам пишут RFC?

Антиспам не должен приводить к нарушению рекомендаций. А уж, тем более, стандартов. Для справки: RFC 1123 является частью STD 3. А то ещё по mail from:<> блокируют некоторые «антиспаммеры»...

Антиспам не должен приводить к нарушению рекомендаций. А уж, тем более, стандартов.

Уже давно стандарты диктуют реализаторы антиспама. Может вы уже забыли, но когда-то hello вообще не проверяли.

Может вы уже забыли, но когда-то hello вообще не проверяли.

Когда-то вообще ничего не проверяли и ограничивать smtp-релей своими сетями и авторизацией тоже не нужно было.

Уже давно стандарты диктуют реализаторы антиспама.

Нет. Они могут идти лесом, если их реализация явным образом нарушает RFC.

Когда-то вообще ничего не проверяли

Именно. Намёк был о том, что таки в конце конков пришлось писать RFC на формат hello.

И вообще, тема борьбы с антиспамом мне не интересна, можете записывать себе победу или что там у вас принято, но это бесконечное пережевывание одинх и тех же аргументов давно вызывает только скуку и верчение пальца у виска.

Намёк был о том, что таки в конце конков пришлось писать RFC на формат hello

Он был написан практически сразу, ну или, как минимум, в тёплые ламповые доспамовые времена. И ничего там не менялось в формате: это или FQDN, или address literal.

И вообще, тема борьбы с антиспамом мне не интересна

Вообще-то я не про борьбу с антиспамом, а про следование RFC/STD. Антиспам - это отдельная тема. Хотя антиспаммеры часто забывают про RFC, это да. И ориентируются на «с гуглем же работает, значит у меня всё правильно». Впрочем, и просто настраивальщики якобы почтовых серверов - тоже.

Хорошо, давайте работать с реальными данными, лишь бы разобраться На IP 213.33.234.85 был сайт scan-neva.ru и почтовый домен @scan-neva.ru

Теперь сайт scan-neva.ru находится на 141.8.192.11

А почтовый сервер @scan-neva.ru теперь находится в поддомене mail.scan-neva.ru но сохранил 213.33.234.85 и резолвится в обе стороны

В отличие от сайта

А вот это: «550 Sender IP reverse lookup rejected (in reply to RCPT TO command)» выдают какому smtp серверу? Который отправляет от адреса scan-neva.ru или от mail.scan-neva.ru ?

dig всё отрезолвил, и прямые и обратные для обеих адресов. Вы чего-то недоговариваете, или сами не понимаете чего хотите.

С mail.scan-neva.ru с ящика @scan-neva.ru уходит письмо серверу @darktickle.com в ответ от MAILER-DAEMON@mail.scan-neva.ru приходит отлуп 550 Sender IP reverse lookup rejected (in reply to RCPT TO command

У меня есть конкретная задача понять почему с нашего сервера не уходит письмо на вполне конкретный адрес, и устранить проблему)

Проверить резолв PTR записей для вашего адреса, занося вывод команд в файл, с разных Днс серверов(гуголь, яндекс). Если на них нормально отправить файло админу почты получателя. Пусть свой днс сервер чинит.

У меня есть конкретная задача понять почему с нашего сервера не уходит письмо на вполне конкретный адрес, и устранить проблему)

Есть подозрение, что у вас то как раз всё нормально, а срабатывает жесткий антиспам: оно хочет чтобы reply-to было с IP доменного, а не текущего mail.домен. :( В RCPT TO не пробовали user@mail.scan-neva.ru ?

Проверить резолв PTR записей для вашего адреса, занося вывод команд в файл, с разных Днс серверов(гуголь, яндекс). Если на них нормально отправить файло админу почты получателя. Пусть свой днс сервер чинит.

Да нормально у него с ptr всё, он же дал реальные адреса, мог и сам проверить. В сообщении там не на ptr ругается, а на обратную проверку отсылателя :(