Exim не принимает почту

В итоге почта отправляется, правда гугл её не пускает, жалуется на PTR
но не суть

...

но вроде она у меня правильная.

Продолжайте наблюдения.

Понятен Ваш посыл, но такая проблема у меня впервые, и раньше не приходилось работать с mx-записями. Сейчас запись имеет вид MX @===>domain.ru.

и раньше не приходилось работать с mx-записями
но такая проблема у меня впервые

Логично что впервые.

Сейчас запись имеет вид MX @===>domain.ru.

MX должна указывать на хост который примет почту.

А подробней, с примером можно?

ты вообще понимаешь хоть примерно как это работает??

ну НАЗВАНИЕ компа с почтовиком твоим там должно быть что же еще

1. PTR должна быть корректной
2. MX указывать на ваш почтовый сервак.
Что ещё не понятно?

Я не пойму, где в данный момент я допустил ошибку. По второму пункту, разве запись, которую я выше обозначил не указывает на сервак?

По второму пункту, разве запись, которую я выше обозначил не указывает на сервак?

мы понятия не имеем, ты же скрываешь

По второму пункту, разве запись, которую я выше обозначил не указывает на сервак?

Телепаты в отпуске.

Вам адрес домена написать? Если я неверно написал MX, то подскажите как нужно, сложно это что ли. Сервак с почтой крутится на локальной машине, и что в MX указывать, если не домен я не пойму.

Смотри, когда тебе отправляют письмо, чужой smtp сервер должен понять куда ему это письмо передать. для этого он смотрит на mx запись твоего домена и резольвит ее в ip твоего smtp сервера. Если ip некорректный, процедура не работает. Что и куда у тебя настроено мы не знаем.

Кажется понял, в MX надо прописать @===>mail.domen.ru, что собственно и отражено в ISPmanager. Прописал, но письма так и не ходят, как и раньше, нужные порты при этом проброшены.

Дядь, ты через слово читаешь?

1. PTR должна быть корректной

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

Если у тебя почтовые адреса вида test@твой_домен то для проверки набери (заменив домен на свой)

nslookup -type=MX твой_домен 8.8.8.8

он ответит среди прочего чем-то типа

твой_домен	mail exchanger = 0 mail.твой_домен

Потом пиши

nslookup mail.твой_домен 8.8.8.8

Потом проверь

telnet mail.твой_домен 25

Он должен подключиться к твоему серверу и показать какое-то приветствие. Если не получается подключиться - ищи почему закрыт порт.

Для приёма почты PTR не нужно и не влияет вообще.

Согласен, посыпал голову пеплом.

подожди пока она обновится, это может занять до нескольких часов.

Не «до нескольких часов», а по значению TTL, что бы точно. Если у вас ttl на «пару суток» то вы не можете точно сказать, что если один нс в виде гули ответил, то другой нс ответит тоже самое.

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

Ну да. Хотя по опыту почему-то обычно при суточном TTL через часов 6 уже везде новые данные видны, а то и быстрее - как повезёт. Может быть изредка можно и сутки прождать, но видимо очень редко - реже, чем просто рандом (учитывая что мы не знаем когда кеш начал храниться).

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

Если никак то остаётся только вариант с арендой где-то реверсного прокси (у которого открыт 25 порт и который будет все коннекты пересылать тебе на какой-то другой), но такая схема несколько обесценивает суть именно локального сервера.

Хотя по опыту почему-то обычно при суточном TTL через часов 6 уже везде новые данные видны

Зависит от этого «везде».

как повезёт.

Я об этом же.

Может быть изредка можно и сутки прождать, но видимо очень редко - реже,

Встречались больше одного раза плюющие на TTL указанное в зоне. У себя в зоне указали 30 мин, а «принимающие» резолверы могут четверо суток держать.

Мне пров аж ссылку дал на страницу на оф.сайте, где перечислены закрытые порты и 25 там в списке. До этого лет 7 назад я поднимал локальный сервер и никаких проблем с почтой не было, может это у провайдера новшество, хз. Арендовать ещё и прокси будет дорого, а иначе никак, я правильно понимаю?

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

Наоборот, это норм практика не первый десяток лет. Имхо уже писал здесь, белый статик != что у вас на нем что-то крутится.

Мне пров аж ссылку дал на страницу на оф.сайте, где перечислены закрытые порты и 25 там в списке.

Звоните и простите открыть. Возможно потребуется заявление, во всяком случае с юриками случается что только по заявлению.

Мне кажется поддержка морозиться будет, но попробую. Я вот ещё не пойму почему в таком случае исходящие письма уходят, а вот входящие нет, знаний не хватает.

а вот входящие нет

Потому что серверные порты закрыты.

знаний не хватает.

Имхо не тем делом вы занялись.

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

А зачем он ещё нужен?

Например завязать на него доступы к другим вашим же белым статикам расположенных в других геолокациаях, не?

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

Доступы по айпи имеют смысл только в полностью контролируемой локалке.

«Полностью контролируемая локалка» это вообще что? И чем оно от инета отличается?

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

Способы организации безопасной локалки разные бывают, общие направления такие:

1) на механическом уровне - запереть всё железо под замок, чтобы посторонние люди не могли куда-нить воткнуть патч-корд или ещё как-то подключиться

2) на уровне сетевого железа - фильтровать все пакеты, у которых айпи-адрес отправителя не соответствует разрешённому для данного физического порта

3) на уровне ОС - операционная система не даст приложению слать пакеты с незапланированными для данного приложения адресами отправителя (настройкой интерфейса, файрволлом по uid или контейнеру если айпи-адресов у компа несколько, главное чётко разграничить урезанные права пользовательских процессов от административных прав настройки сети)

Ну если только первый пункт «под замок». Ирл мы такое делали на пром объектах. Но это был вариант а-ля «киоск» одна софтина ( по интерфейсу одна) в которой пользаки работали. Железо в железном ящике, наружу только провода до моника, клавы и принтера.

Я так понял почта у тебя публичная, ну так озвучь свой домен то, а мы проверим, ну или сам проверь предположим mail.ru и сравни со своим. Хотя firkax вроде тебе уже все разжевал и в рот положил.

Для приёма почты PTR не нужно и не влияет вообще.

Теоретически да, я давно почту свою поднимал и тогда если обратная зона не совпадала с прямой, некоторые могли посчитать ( и считали) меня спамером, просил прова прописать и никогда не получал отказ.

25 порт оказалось, что закрыт провайдером, открывать он отказывается, …

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

Нет, он у него закрыт только входящий. Теоретическая причина закрывания - чтобы клиент провайдера, установив себе почтовый сервер с дефолтными или плохими настройками, не получил open relay. На практике по-моему это уже не особо актуально, но на всякий случай закрывают. А 80-й - чтобы клиенту дырявый роутер не взломали.

Спамером тебя считают когда ты что-то отправляешь, а тут речь про приём.

Спамером тебя считают когда ты что-то отправляешь, а тут речь про приём.

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

Возможно, тех-персонал провайдера просто что-то недопонял слизывая у «старших товарищей» и запретил не в том направлении)

Тут речь идет об установке у себя почтового сервера

Та нить беседы, на которую ты ответил - конкретно про «PTR для приёма почты», а не про почтовый сервер вообще. И не про закрытые порты.

Возможно, тех-персонал провайдера просто что-то недопонял слизывая у «старших товарищей» и запретил не в том направлении)

Возможно. Если провайдер хочет просто защитить свои айпи-адреса от попадания в спам базы, и больше его ничего не интересует - то да, логичнее закрыть исходящий 25. Но есть и другой вариант: провайдер не хочет лишать своих клиентов возможности пользоваться 25 портом (через него не только межсерверное SMTP работает, но иногда, в основном у старых сервисов, и клиент-серверная первичная отправка на свой почтовик с авторизацией по паролю), но опасается, что эти самые клиенты по своей глупости (без злого умысла) установят себе open relay и через них будут спамить третьи лица. Вот в таком случае надо закрывать именно входящий. И в таком случае, когда клиент подтвердит свою компетентность в нежелании устраивать open relay, порт можно и открыть.

Сегодня ещё по поводу PTR прову написал, в итоге получил короткий ответ, что добавить не могут, без объяснения, почему собственно. Крупный провайдер, а такая лажа…

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

Люто нет! Прямая не обязательно должна совпадать с обратной. Обратная должна быть корректной, но не более того.

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

Поперхнулся. А 80-ый и 443-ий и другие они тоже закрывают на всякий случай? Не ну а че, вдруг вы в какойнидь мордокниге гадость напишите.

В AWS и Azure, к примеру, просто так собственный почтовый сервер не поднять - могут пойти на встречу только «солидным» клиентам )

Пример:
https://learn.microsoft.com/en-us/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

C HTTP/HTTPS портами таких ограничений, естественно нет)
Не - ну реально российские спамеры вконец оборзели. Так что провайдеров понять можно.

Сегодня ещё по поводу PTR прову написал, в итоге получил короткий ответ, что добавить не могут

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

В AWS и Azure

Это другое. В топике про локальный.

Это другое. В топике про локальный.

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

AWS и Azure это считай хостинг, а не вариант «поддиванного».