dns ptr

причина такая - отправитель писем @domain.ru не имеет PTR и некоторые получатели ругаются

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

Ты не сможешь прописать это у себя. Обращайся к провайдеру, выдавшему айпишник.

И прописывать нужно имя почтового сервера. Т.е. mx.domain.ru, а не просто domain.ru.

Строго говоря, у себя ты можешь прописать что угодно, просто это никак не отразится на реальности. Обратная зона контролируется владельцем ip. Ну и да, 2024 год, вы спокойно почтой пользуетесь без ptr?)))) Чудны дела.

mx - у нас в зоне нашей 11.11.11.in-addr.arpa PTR для mx есть

1 PTR mx.domain.ru.

надо PTR для домена - на это получатели ругаются иногда

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

надо PTR для домена - на это получатели ругаются иногда

PTR прописывается не для домена, а для ip-адреса. И должно совпадать с именем почтового сервера, которым он представляется. Если почтовый сервер представляется как mx.domain.ru, то и PTR должно соответствовать mx.domain.ru. Разумеется, у домена domain.ru должна быть запись MX, которая резолвится в mx.domain.ru

PTR прописывается у провайдера.

Либо провайдер по клиентскому запросу (это целый квест местами) делегирует обратную зону на арендованную клиентом подсеть клиенту и он прописывает сам :)

На самом деле с этим стало полегче. Недавно в одном линуксовом чате зашёл разговор об этом, я просто интереса ради тут же написал заявку в оба своих провайдера. Мне прописали обратку в течении 10-ти минут в первом и в течении полутора часов во втором. :)

Мне прописали обратку

Прописали или делегировали управление? Я про второе.

почему у провайдера? мы сами управляем 11.11.11.in-addr.arpa

я щас понял - надо сайт у себя domain.ru. и

11.11.11.1 prt domain.ru.

а с сайта редирект на 22.22.22.22

тогда все будет норм

Ааа... Понял теперь, да. Мне именно прописали. Просто раньше даже для этого нужно было чуть ли не по буквам рассказывать, чего я хочу.

мы сами управляем 11.11.11.in-addr.arpa

Для управления надо, чтобы провайдер явно сделал делегирование. Он сделал?

мы сами управляем 11.11.11.in-addr.arpa

Really?

а с сайта редирект на 22.22.22.22

Сайт и его редиректы не имеют отношения к почтовому домену.

т.е у тебя щас домен и mx в разных подсетях? и как @получатели - не ругаются на это? вроде у постфикса на такой случай есть проверка..

это наши адреса - whois domain.ru если глянуть там будет

org: "ООО «domain.ru»

Когда от тебя приходит письмо, твой сервер представляется как mx.domain.ru(например), принимающий сервер резолвит mx.domain.ru, получает айпишник, резолвит PTR этого айпишника и ожидает там получить mx.domain.ru. Если всё ок, письмо проходит на следующий этап фильтрации.

При этом твой почтовый сервер может обслуживать сколько угодно доменов. Хоть @domain.ru, хоть @foobar.com. Это уже другая история. На этапе проверки PTR проверяется только соответствие доменного имени сервера его айпишнику.

У постфикса есть множество разных проверок на все случаи жизни. Но мы же тут говорим сейчас про то, как работает SMTP, а не то, что можно сделать с постфиксом.

Третий раз повторяю. Домен ваш. Айпи-адрес - не ваш. Провайдер выдал айпишник, он и прописывает для него PTR. Или даёт возможность им управлять.

почему у провайдера? мы сами управляем 11.11.11.in-addr.arpa

Следующая команда возвращает ваши ns серверы?

nslookup -query=ns  11.11.11.in-addr.arpa 8.8.8.8

ip диапазон наш, купили его в RIPE, ну или может в аренду взяли, факт тот что мы сами PTR в своей подсети назначаем,,

а вот для почтовика - нужен ли ptr домена ?

щас пришел отлуп 554 5.0.0, вот и вопрос почему, подозрение только на то что нет ptr домена

конечно возвращает, у нас в зоне 11.11.11.in-addr.arpa вписаны ns, мы же нашими зонами управляем

ip диапазон наш, купили его в RIPE, ну или может в аренду взяли, факт тот что мы сами PTR в своей подсети назначаем,,

Странно, что денег на айпишники хватило, а на админа - нет... Ну, не важно.

Выше я уже написал, что нужно прописать. Доменное имя почтового сервера(не домена, не сайта, не ещё какой-нибудь лабуды) должно соответствовать айпишнику, а айпишнику это имя.

Проверить можно, например, тут: https://mxtoolbox.com/

Тогда всё номрально. Запись MX указывает на домен, этот домен резолвится в IP, этот IP резолвится в домен из MX записи. Они указывают друг на друга. Самая простая и очень распространённая проверка.

какраз нетак,, вот как щас -

mx.domain.ru A 11.11.11.1

11.11.11.1 PTR mx.domain.ru.

domain.ru A 22.22.22.22

а PTR domain.ru - нету

Host 22.22.22.22.in-addr.arpa. not found: 3(NXDOMAIN)

mx.domain.ru A 11.11.11.1

11.11.11.1 PTR mx.domain.ru.

Остальное лишнее. В данном контексте не имеет значение.

Проверка:

nslookup -query=mx  domain.ru  8.8.8.8
nslookup mail.domain.ru  8.8.8.8
nslookup 11.11.11.1 8.8.8.8

что денег на айпишники хватило, а на админа - нет..

а я там дворник

Нет. То, куда резолвится ваш domain.ru, или mx.domain.ru, или ещё какой-нибудь ваш поддомен не имеет прямого отношения к доставке вашей почты от вас к получателю.

Да, конкретный получатель может у себя навертеть проверок произвольной степени строгости и абсурдности, но может и не навертеть. А вот проверять бек-резолвинг IP-адреса отправителя почты он будет почти наверняка. В большинстве случаев он просто должен существовать.

Собственно, насколько я понимаю, в этом и проблема: IP, с которого вы отправляете почту, не имеет PTR. И нет, если рулите теми адресами не вы, то алиасами/редиректами ничего не достичь. Можете перенести почтовый сервер на свои адреса (11.11.11.) и прописать PTR. Либо просите владельцев адресов.

То, куда резолвятся ваши A- и MX-записи, — это дело десятое, так как влияют они на доставку почты к вам, а не от вас.

Да, это пожалуй ключевой вопрос: отправка и приём идут через один адрес или разные?

whois domain.ru если глянуть там будет

Это не имеет значения. Значение имеет, что показывает
whois 11.11.11.in-addr.arpa -h whois.ripe.net
Чьи там DNS?

MX-записи, — это дело десятое,

Это если они вобще резолвятся. ТС пока не разу ни показал, что у него MX запись есть, и что она правильная. Да и текстовые сообщения об ошибках ТС тоже не приводит, откуда все взяли, что проблема в PTR?

С этого надо было начинать.

Я тут с 2022 года у одного из провайдеров, с покрытием от ЮФО до СФО и не самыми маленькими ритейлерами в клиентах на сайте, не могу добиться PTR — «пока нет технической возможности», а тебя удивляет что где-то организации существуют где почтовый домен настроен не полностью.

у одного из провайдеров, с покрытием от ЮФО до СФО и не самыми маленькими ритейлерами в клиентах на сайте, не могу добиться PTR — «пока нет технической возможности»

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

щас пришел отлуп 554 5.0.0, вот и вопрос почему
554 5.0.0

Только это? Подробностей в ответе нет?

подозрение только на то что нет ptr домена

Только по номеру ошибки гадать на кофейной гуще можно долго, но корректная PTR нужна.

Не тот случай. Они пока адреса у магистральщика арендовали, всё нормально было. А тут себе адресов купили, перевели абонентов.. и абзац.

И класть я хотел на его «почему». Я деньги заплатил — окажи услуги качественно. Он же мне скидку на «мы то и это не умеем» не делает. Знает только Вася — пни Васю, он сделает. Это мелкому какие-то огрехи можно простить, ибо он физически не вывезет.

Это мелкому какие-то огрехи можно простить, ибо он физически не вывезет.

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

Знает только Вася — пни Васю, он сделает.

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

Не увидел причин, почему надо терпеть некачественно оказанную услугу, а не требовать нормального сервиса?

Можно вопрос? Допустим мы для подключившегося 1.2.3.4 провели обратную и прямую резолюцию, результаты сошлись, заключили, что он правомерно называет себя mail.one.com. Далее он передает нам письмо с обратным адресом @two.com и нам нужно смотреть spf two.com. Но в чем тогда был смысл обеих резолюций на первом этапе для 1.2.3.4/mail.one.com?

Еще непонятно, зачем 1.2.3.4 представляться, если всё равно проводится обратная резолюция.

Попробуйте потребовать, потом расскажите что вам рассказали.

Но в чем тогда был смысл обеих резолюций на первом этапе для 1.2.3.4/mail.one.com?

В том что вы это вы.

Еще непонятно, зачем 1.2.3.4 представляться

А вот этого как раз делать не надо.

В том что вы это вы.

Ну это не ответ. В чем удостоверился принимающий почту сервер непонятно: ну провели двустороннюю резолюцию, ну действительно он mail.one.com, и? О наличии или отсутствии права передавать те или иные письма это никак не говорит, потому что там другой домен в обратном адресе и это придется проверять по spf.

Уже давно: «Ок, под вас старый ip в аренду продолжим брать».

Или ты ждал, что будет посыл в дальнее пешее?

Или ты ждал, что будет посыл в дальнее пешее?

Легко и непринуждённо.

Даже не сомневался. Последнее время часто попадаться стали любители терпеть лишения там, где нужно просто потребовать то, что положено.

где нужно просто потребовать то, что положено.

А вам это положено? Это где-то в договоре с печатью и подписью прописано?

ну действительно он mail.one.com, и?

Это значит, что это не случайный спамбот. Такая простая проверка отшивает 90% спама.

Проверка соответствия почтового домена и почты, это уже другое.

Варианты проверок разные бывают, зависит от упоротости принимающей стороны на которую вы повлиять не можете никак от слова совсем. Могут требовать только корректность ptr, могут сверять её с приветствием…

Кстати шансы получить ip с ptr mail.какой-то-не-ваш-домен оказывается не такие невеликие.

Слышал такую историю от одного знакомого админа. Он арендовал сервер и ему выдали айпишник с чужим PTR. А ещё A и MX на него же ссылались. :)

В договоре много чего не прописано.

Например, дроп трафика на порты 25, 587, 993 и т.п. Однако это происходит по умолчанию на всех узлах.
И MTU не зафиксирован. Однако он, почему-то, 1500.
И наличие DNS у провайдера не прописано, однако…
Продолжать, или достаточно?

Как же так?

Понятно, конкретный договор я вам цитировать не могу, а значит и мотивацию рассказать. Неуходящую почту вполне можно под «не работает доступ в интернет» подвести, если задаться целью. Только проще провайдера поменять.

Я вам тайну открою: можно вообще договор «с подписями и печатями» не делать. Если обе стороны приступили к исполнению обязательств — договор заключен. Бумажка (или её электронный эквивалент) нужна только, чтобы в суде проще было, или если законом явно установлено требование наличия бумажки. И даже если что-то в договоре не прописано явно, то обязательства, не противоречащие договору, всё-равно из обстоятельств возникают. man ГКРФ

Например, дроп трафика на порты 25, 587, 993 и т.п.

Входящий или исходящий?

И MTU не зафиксирован. Однако он, почему-то, 1500.

А может быть и не 1500, но это не мешает работе инета.

И наличие DNS у провайдера не прописано

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

В договоре много чего не прописано.

В договоре скорее всего прописано «предоставление доступа к ресурсам сети интернет…» что-то в таком духе. Коренное это «к ресурсам».

Бумажка (или её электронный эквивалент) нужна только, чтобы в суде проще было, или если законом явно установлено требование наличия бумажки.

Вот! Вы сами и написали. Требовать можно только то, что прописано.