Публикуется с разрешения обоих собеседников, отцензурированы
IP адреса и доменные имена рассматриваемого домена.
Случай хрестоматийный, человек, которому давались объяснения - думающий,
просто не очень знающий. Надеюсь, что этот текст прибавит ясности кому-нибудь...
#####> Дано: есть почтовый юниксовый сервер Postfix, который имеет хамскую манеру не доставлять письма на @mail.ru или доставлять со значительной задержкой.
#####> Вопрос: что может быть причиной этого ( само собой кроме настроек фильтров)?
qkowlew> 1. смотреть логи - что говорит в логах сервер mail.ru
qkowlew> 2. 99% за то, что это - грейлистинг. на сервере mail.ru
qkowlew> 3. минимизировать это можно правильным backresolv и правильными записями в ДНС для твоего домена
qkowlew> домен какой?
#####> О как! А на стороне местного тоже самое? Хуже ведь не будет?
#####> Домен ######.###
#####> До логов mail.ru добраться как-то сложно, мне кажется.
qkowlew> в логах твоего постфикса есть ответ мейлрушного сервера
#####> Вот и я об этом.
#####> Что должен быть какой-то ответ от сервера.
qkowlew> ну вот и смотри какой он там
#####> Угу. Как только доберусь до него: я там еще не работаю.:-D
qkowlew> да - настоятельно рекомендуется почитать что такое SPF и как правильно прописывать TXT записи с SPF
qkowlew> если совсем будет непонятно - ну дашь мне логин на нём, посмотрю в логи. :))))
qkowlew> но прежде всего - читать логи.
qkowlew> Потом - файл зоны DNS
qkowlew> Потом - конфиг postfix'a
#####> Понимаешь, какая штука, этот сервер доживает последние месяцы: его будут менять на MS Exchange 2010.
#####> Так что в наилучшем ( для меня случае) самым тяжелым будет перенос п/я с Postfix на Exchange.
#####> Угу, в общем, неверные/некорректные настройки самого сервера. Спасибо.:-)
qkowlew> НЕТ
qkowlew> если просто перейдёте на ексчендж - это НЕ решит проблем
qkowlew> правильная последовтальность действий помимо логов:
qkowlew> whois ######.###
qkowlew> получил адреса ДНСов
#####> Здрасьте! Это еще почему? Exchange будет ставиться с нуля по всем правилам. С проверкой всех записей домена.
qkowlew> щас увидишь
#####> ХЗ кто там что написал в этих записях, я что должен всему верить?=-O
qkowlew> ХА ХА ХА
qkowlew> ns4.nic.ru red.######.### 194.186.##.###
qkowlew> далее - надо спросить host ######.### с каждого из этих серверов
qkowlew> то есть - host ######.### ns4.nic.ru
qkowlew> host ######.### red.######.###
qkowlew> и убедиться в том, что red.######.### в самом деле 194.186.##.###
qkowlew> nslookup red.######.###
#####> Угу, и что мы видим?
qkowlew> со всех трёх получили список почтовиков:
qkowlew> ######.### mail is handled by 10 black.######.###.
qkowlew> ######.### mail is handled by 20 grey.######.###.
qkowlew> ######.### mail is handled by 30 mx1.######.###.
qkowlew> далеее по каждому из почтовиков набираем nslookup black.######.###.
#####> Чума!
qkowlew> получаем IP адрес 213.234.###.###
qkowlew> теперь набираем nslookup 213.234.###.###
qkowlew> чтобы этот сервер ПРАВИЛЬНО ОТСЫЛАЛ почту во внешний мир - в результате его nslookup IP должен быть его символьный адрес:
qkowlew> nslookup 213.234.###.###
qkowlew> ###.subnet-###.###.234.213.in-addr.arpa name = black.######.###.
qkowlew> это - правильно
qkowlew> А вот для ТРЕТЬЕГО сервера:
qkowlew> nslookup mx1.######.###
qkowlew> Address: 194.186.##.###
qkowlew> nslookup 194.186.##.###
qkowlew> ** server can't find ###.215.186.194.in-addr.arpa.: NXDOMAIN
#####> То есть, для ######.### левая MX-запись?
qkowlew> НЕТ
qkowlew> MX запись честная
qkowlew> но для данного IP адреса НЕТ ОБРАТНОЙ записи.
qkowlew> есть "прямая запись" - из символьного имени в IP
#####> А, нет обратной зоны?
qkowlew> есть "обратная запись" - из IP в символьное имя
qkowlew> отсутствие обратной записи - повод считать данный сервер подозрительным и грейлистить а то и блеклистить его нахрен
#####> Ну, это понятно - resolve name by IP
#####> Все, понял. Большое человеческое спасибо.*OK*
qkowlew> в чём ХУМОР ситуации - в том, что имея контроль над ДОМЕННЫМ ИМЕНЕМ, ты НЕ имеешь контроля над обратной зоной
#####> Это почему еще?=-O Что мешает прицепить обратную зону?
qkowlew> и от применяемого софта (sendmail/postfix/exchnge) это не зависит
qkowlew> поддержка обратной зоны осуществляется НЕ со стороны домена
qkowlew> поддержка обратной зоны может осуществляться только владельцем соответствующего пространства IP адресов.
#####> А со стороны регистратора?
qkowlew> И он МОЖЕТ делегировать тебе конкретные IP адерса на твой собственный ДНС сервер
qkowlew> так, например.
qkowlew> У меня есть домен GFNS.NET
qkowlew> и у меня есть серер на IP адресах, принадлежащих компании Ринет
qkowlew> пространство 195.91.162.192-207 делегировано МНЕ ринетом на мой ДНС сервер
qkowlew> и именно на моём сервере лежит соответствующая зона в которой я прописываю, например, строку:
qkowlew> 194 IN PTR mail.gfns.net
qkowlew> в результате, когда кто-то набирает:
qkowlew> nslookup 195.91.162.194
qkowlew> он получает ответ
qkowlew> 194.192-207.162.91.195.in-addr.arpa name = mail.gfns.net.
qkowlew> но подчеркну - это НЕ в домене gfns.net
qkowlew> Это именно делегирована реверсная зона
qkowlew> Да - на ######.### скорее всего что произошло:
qkowlew> ранее провайдер, дававший соотв IP адреса, для 194.186.##.### имел прописанный у себя бекрезолв правильный. По просьбе старого админа. Это типично, если старый админ просил у провайдера "сетку с делегированием зоны и ещё хотя бы один сервер в другой сетке"
qkowlew> потом админы сменились (а домен существует ДАВНО, что хорошо видно по хуизу)
qkowlew> и у провайдера админ сменился на более тупого.
qkowlew> Который не знает, как и для чего нужен бекрезолв
#####> И у него не хватает мозгов не трогать то, что работает.
qkowlew> и снёс непонятную ему запись из соотв зоны (а то и всю зону)
qkowlew> да
qkowlew> потом прошло ещё время - и из-за буйства спамеров на почтовиках ужесточиллись правила проверок не спамер ли пришёл
#####> Угу, понятно.
qkowlew> и почта С ЭТОГО сервера стала ходить плохо.
#####> Это нормально.
qkowlew> А новый админ конторы тоже не знает зачем нужен бекрезолв и не умеет читать логи.
qkowlew> потому сейчас ты его, скорее всего, заменишь на себя, тоже не совсем исправного. :))))
#####> Ясно. То есть, первым делом нужно дотрещаться с провайдером об обратной зоне.
qkowlew> Развитие событий по этому сценарию я наблюдаю за последние 4-6 лет примерно на половине как-то поддерживаемых мной доменов и локальных сетей.
qkowlew> По минимуму - чтобы nslookup 194.186.##.### давал ответ mx1.######.###
qkowlew> Для этого не обязательно делегировать тебе твой диапазон IP адресов, достаточно чтобы админ провайдера прописал строку IN PTR для этого твоего IP в ту "реверс-зону", что он контролирует.
qkowlew> как это будет сделано - в течение примерно 2-4 дней почта на многие домены СТАНЕТ ходить лучше.
#####> Так что, если возьмут на работу в эту банку - прорвемся.
qkowlew> прошу разрешения опубликовать сей лог "в назидание потомкам", с "забитыми" доменом, IP и твоим именем.
#####> Да ради бога. Если это кому-то будет полезно.
