Ип почтового сервера заблокирован гуглом, яндексом и даже мейлом.

Просто подожди еще

Корпорасты подмяли под себя 98% SMTP-трафика, а всю шалупонь нагло отфутболивают - ты же в уважаемые кланы и семьи не вписываешься со своим пролетарским сервачком :)

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

Самое интересное, что входящая почта на сервер идёт, именно исходящую не хочет

Ничего интересного: это совсем не связанные процессы. У тебя самого исходящий tcp по 25-ому порту не перекрыт? Пошерсти произвольные домены на предмет MX и попробуй на 25-ый порт телнетом зайти с сервера.

Гугл блокирует твой мэйлсервак, как недоверенный и потенциальный источник спама. Практически не лечится.

Проверьте что вы арендовали, нет ли «криминала» не только вам выделенного ip, но и в подсети. Прогните прова на предмет чистого ip или даже подсети (нормальный пров всё это делает бесплатно).

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

И правильно делают! Добавили бы они ещё хотя бы фильтр по hostname. У сайтодельных эникейщиков сразу паника будет )))

Кустари со своими наколенными почтовыми поделками мало чем от спамеров отличаются.

Ты уверен, что это не провайдер блокирует исходящий трафик 25/tcp? За ними я такое замечал неоднократно, а за мажорными ЕСП - никогда.

Ну вот, раб корпорации высказал своё почтение Хозяину. Молодец, прогиб засчитан. Давай ещё похвали Гугл! «И правильно блокируют эти самодельные почтари! Ишь чего вздумали!». Голос!

Проверь, не закрыт ли порт 25 наружу.

Тролльдетектед DROP

Мне кажется, что странно всё это как-то. Блокировать доступ всего лишь из за некорректной PTR. Тем более что я ничего с этого сервера ещё не посылал, это была первая попытка послать письмо после настройки. Плюс частенько сталкивался, когда ptr вовсе нельзя было настроить как требовалось и он ссылался на совсем другой домен и работало, даже в спам не попадало...

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

проверил на smtp от этого форума))) donkey.linux.org.ru, не работает, т.е даже сюда перекрыто. С другого сервера всё отлично.

Красавчик )

Проверил внаглую на smtp своего хостера и неожиданно тоже не работает. Написал в конце концов им приложив всё это, косяк с их стороны.... Всем спасибо за ответы)

этот «косяк» обычно описан в ToS.
если конекшн таймаут - точно проблемы со связью, в случае блокировки (спам или корявая настройка) придет ответ от smtp с кодом и кратким описанием претензии

//мимо-10лет-почта-на-локалхосте

Кустари со своими наколенными почтовыми поделками мало чем от спамеров отличаются.

Если всё настроено (spf, ptr, dkim, dmarc, dane tlsa (с dnssec), mta-sts,smtp-tlsrpt), если tls на почтовом сервере настроен на соответствие hipaa, pci dss, nist, если на mail-tester 10/10 ecли рассылка не попадает в спам ни у гугла, ни у яндекса, ни у мейл.ру то чем это хуже чем например глючный Коннект от Яндекса.

Гугл блокирует твой мэйлсервак, как недоверенный и потенциальный источник спама. Практически не лечится.

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

IMHO, очень похоже на сетевые проблемы (кривая конфиграция firewall?).

Кустари со своими наколенными почтовыми поделками мало чем от спамеров отличаются.

Что за глупость? Совершенно нормальное желание - контролировать собственную почту, а не доверять ее непонятно кому... Чем лично Вам «наколенные» серверы мешают?

Сейчас сижу думаю куда проверить 25 порт

А чего думать-то? Любой smtp-сервер подойдет. Даже если сервера нет - можете соединиться с любой машиной - в случае, если исходящие соединения на 25 порт открыты, получите сообщение connection refused (если там нет почтового сервера). А вот если соединения перекрыты, то связь просто не установится.

проверил на smtp от этого форума))) donkey.linux.org.ru, не работает, т.е даже сюда перекрыто.

Обращайтесь к провайдеру. Вообще говоря, это нормальная практика - открывать исходящие соединения на 25 порт только по запросу. Минимизирует риски попадания подсетей провайлера в спам-базы.

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

криво настроенные почтовые сервера, которые опенрелеем смотрят наружу.

Это какие-то истории из 80-х - первой половины 90-х годов. Я уже и не помню последнюю версию sendmail'а, где опенрелей был по умолчанию включен. Остальные почтовики никогда и не имели таких настроек по умолчанию...

Это я к тому, что настроить open relay сегодня - это отдельная работа. Случайно получить такую конфигурацию практически невозможно...

Блокировка была со стороны хостера, когда этим ип пользовался другой клиент. Хостер об этом почему-то забыл)

Что за бред?

Процентов 20 кустарей забивают на hostname, записи ptr для них фантастика, а dkim и spf это предел их возможностей только потому, что гугломейлояндекс без них не петрит.

Про iptables и fail2ban они узнают только когда их ломанут и забанят везде.

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

Про iptables и fail2ban они узнают только когда их ломанут и забанят везде

Кстати по поводу fail2ban для почтового сервера - если не затруднит - посмотрите пожалуйста - ничего я не забыл ?:

натройки правил fail2ban для exim

по поводу fail2ban

exim не юзаю, а вот fail2ban для всех правил вместо REJECT в DROP переключил + bantime неделя.

+ iptables по всем портам впилить, примерно так:

-A INPUT -p tcp --dport 25  -m connlimit --connlimit-above 1  --connlimit-mask 32 -j REJECT
-A INPUT -p tcp --dport 25  -m connlimit --connlimit-above 30 --connlimit-mask 0  -j REJECT

Блокировать доступ всего лишь из за некорректной PTR

Насколько я помню RFC требует чтобы PTR запись просто была, но попадаются люди которые делают

host <IP>

dig <HOST>

и отсылают если IP, выданный dig не совпадает с тем с которого соединялись.

Тебе-то что с этого? Чем конкретно тебе мешают?

кустарей

fail2ban

Ясно-понятно.

Процентов 20 кустарей забивают на hostname, записи ptr для них фантастика

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

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

И что? Чем лично Вам они мешают? Спам не рассылают, так в чем проблема-то?

fail2ban

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

iptables

Iptables - это, конечно, хорошо. Только вот защиту одиночного сервера это не сильно увеличит. Ломают-то обычно через уязвимости в конкретных сервисах, выставленных наружу. А какой смысл закрывать порт, который никто не слушает? Ну получите Вы в ходе атаки ответ Connection refused - сильно Вам это поможет?

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

Вот это и хотелось бы понять - какой именно работы добавляют Вам «кустарные» почтовые серверы? Вы можете их просто игнорировать, как тот же google делает, вот и все...

Игнорировать это хорошо до того, как нужный отправитель отфильтровывается на уровне соединения. И остаётся 2 пути: искать их админа и заставлять работать или прописывать исключения. Первый путь уже надоел )))

Вот поэтому и буду радоваться, когда почтовые гиганты введут полный набор фильтрации, а пока что рабство.

Это все до первой попытки отправить письмо корреспонденту, использующему gmail

С охинеей в hostname свободно работают гугл, мейл и даже яхо.

Спам не рассылают, так в чем проблема-то?

Да из-за них исключения приходится регулярно писать.

Iptables защиту одиночного сервера это не сильно увеличит.

Но вполне достаточно для среднего бизнеса ;) Даже дешёвый ддос держит.

Да из-за них исключения приходится регулярно писать.

Ага и обычно это корп. почты компаний. :) А вообще вам «везет». По моей практике, не то что бы очень часто такое происходит.

Да из-за них исключения приходится регулярно писать.

Можно и не писать, просто в отлупе указывать причину отказа в приеме почты. В конце концов, это проблема отправителя, вот пусть он и выносит мозг своему админу ;).

Но вполне достаточно для среднего бизнеса ;)

Я про другое - и без iptables все нормально с безопасностью будет, если лишние сервисы не запускать на сервере.

Даже дешёвый ддос держит.

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

Очень многие настраивают open relay просто чтобы не париться. Типа все равно никто не узнает. Все приходит с опытом.

искать их админа и заставлять работать

Единственное, что я не понимаю, так это то, почему это является Вашей проблемой. Как-то админы того же gmail не занимаются такой благотворительностью и нормально существуют :).

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

Очень многие настраивают open relay просто чтобы не париться. Типа все равно никто не узнает. Все приходит с опытом.

Я про другое - уже очень давно надо специально париться, чтобы open relay настроить. Да, было время, когда тот же sendmail по умолчанию работал как open relay. Но сейчас-то все по-другому. Если Вы просто, не парясь, по любому HowTo сконфигурируете почтовый сервер, open relay не получится.

Это да, но многие сильно борзеют, особенно в госсекторе. А нашел - сразу хацкер. Так что сидят они так годами с опенрелеем. А sendmail шибко давно по умолчанию был open relay, странно что кто-то это еще помнит.

А sendmail шибко давно по умолчанию был open relay

Так и я об этом. А остальные почтовики вроде и не были им (open relay) никогда.

странно что кто-то это еще помнит.

Я застал это время ;). Первые мои почтовые серверы так и работали. И, как ни странно, без всяких проблем - помню, еще удивлялся, когда эту опцию отменили...

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

Видимо вам начальство ни разу не говорило: «Делай что хочешь, но что бы от них мне почта проходила! Надо и точка!»

Именно так, но это лавинно происходит. Тишина месяц, а потом десяток-другой, они как сговариваются )))

у меня на mail.ru все ящики заблочили - требуют номер телефона для привязки, отказался от их услуг и пересел на gmail.com - так эти суки с mail.ru не пропускают письма с gmail.com

и без iptables все нормально с безопасностью будет

iptables придумали трусы )))

Или из области я успею вынуть)

Гугл блокирует твой мэйлсервак, как недоверенный и потенциальный источник спама. Практически не лечится.

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

Меня так на Арубе один IP достался в куче блеклистов. Через полгода (наверное) уже был чист со всех сторон.

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

Всегда пользуюсь iptables. Что я делаю не так?...

по жалобам недоброжелателей

А почему они так?