[motorhunter]

Добрый день, коллеги.

 

Наблюдая и отлаживая работу почтового сервера, столкнулся с непонятной для меня ситуацией. Имеем почтовый сервер на базе Axigen. В качестве защиты от спама среди прочих там предусмотрен механизм проверки существования обратного преобразования DNS для отправителя письма (в настройках этот пункт называется "Reject message if the originating IP has no reverse DNS entry"), соответственно, если обратное преобразование не проходит или же имя не совпадает с представленным в HELO/EHLO, сервер не принимает письмо. До некоторого времени я не включал эту проверку, но недавно решил попробовать в качестве защиты от спама. Сразу же посыпались жалобы пользователей на то, что они перестали получать письма из некоторых доменов. Причина (по логам) - "reverse DNS check failed". Пример куска лога:

 

06-05 16:25:48 +0400 16 mail SMTP-IN:0000DBAC: << EHLO mx.optik.ru
06-05 16:25:48 +0400 08 mail SMTP-IN:0000DBAC: [sMTP Filter Info] Reverse DNS check failed for <mx.optik.ru> connected from <79.172.59.10>
06-05 16:25:48 +0400 08 mail SMTP-IN:0000DBAC: [sMTP Filter Info] Set smtp action to REJECT

 

Действительно, адрес 79.172.59.10 преобразовывается в имя m-service.convex.ru, а не mx.optik.ru, как указано в приветствии. Соответственно, почтовый сервер не принимает письмо.

 

Для меня такая ситуация непонятна - насколько я помню, везде в мануалах по настройке почты было требование соответствия имени и адреса почтового сервера как в прямую, так и в обратную сторону. Почему же для mx.optik.ru такое требование не выполнено? Можно было бы списать это на единичный случай неправильной настройки конкретного сервера, но такая же ситуация повторяется и для некоторых других доменов, в частности, facebook.com.

 

06-05 16:25:40 +0400 16 mail SMTP-IN:0000DBAB: << EHLO mx-out.facebook.com
06-05 16:25:40 +0400 08 mail SMTP-IN:0000DBAB: [sMTP Filter Info] Reverse DNS check failed for <mx-out.facebook.com> connected from <66.220.144.167>
06-05 16:25:40 +0400 08 mail SMTP-IN:0000DBAB: [sMTP Filter Info] Set smtp action to REJECT

 

nslookup 66.220.144.167
╚ь :     outcampmail008.snc4.facebook.com
Address:  66.220.144.167

 

Очевидно, что mx-out.facebook.com != outcampmail008.snc4.facebook.com.

 

Получается, что проверка на reverse DNS неэффективна и не имеет смысла её использовать в почтовых серверах? Но она значительно снизила поток спама, не хотелось бы отказываться от неё. Собственно, вопрос в следующем - что здесь неправильно? Неправильно настроены почтовики optik.ru и facebook.com или неправильно производит проверку Axigen или я неправильно понимаю весь механизм данной процедуры? Прошу вашего совета.

[nuclearcat]

Скорее так

Reverse check:

 

centaur ~ # host 66.220.144.167

167.144.220.66.in-addr.arpa domain name pointer outcampmail008.snc4.facebook.com.

centaur ~ # host outcampmail008.snc4.facebook.com

outcampmail008.snc4.facebook.com has address 66.220.144.167

 

Тут все ок.

 

А вот другая проверка - да, если в HELO mx-out.facebook.com

 

Но там по условию (!!!!)ИЛИ. Или name резольвится в IP сервера, или IP резольвится в предоставленный HELO name

 

centaur ~ # host mx-out.facebook.com

mx-out.facebook.com has address 69.63.179.26

(совпадает, ОК)

[MATPOC]

если обратное преобразование не проходит или же имя не совпадает с представленным в HELO/EHLO, сервер не принимает письмо. До некоторого времени я не включал эту проверку, но недавно решил попробовать в качестве защиты от спама. Сразу же посыпались жалобы пользователей на то, что они перестали получать письма из некоторых доменов. Причина (по логам) - "reverse DNS check failed". Пример куска лога:

Получается, что проверка на reverse DNS неэффективна и не имеет смысла её использовать в почтовых серверах? Но она значительно снизила поток спама, не хотелось бы отказываться от неё. Собственно, вопрос в следующем - что здесь неправильно? Неправильно настроены почтовики optik.ru и facebook.com или неправильно производит проверку Axigen или я неправильно понимаю весь механизм данной процедуры? Прошу вашего совета.

Да, это малополезная проверка. С водой ребёнка выплеснули.

[motorhunter]

Действительно, в RFC2821 сказано так:

An SMTP server MAY verify that the domain name parameter in the EHLO

command actually corresponds to the IP address of the client.

However, the server MUST NOT refuse to accept a message for this

reason if the verification fails: the information about verification

failure is for logging and tracing only.

Получается, сервер может проверить (а может и не проверять) прямое преобразование имени, указанного в HELO, в адрес клиента, но даже если преобразование не пройдёт, не должен отвергать почту. Про обратное преобразование в данном RFC вообще ничего не написано. Почему же все рекомендации по настройке почтовиков утверждают, что необходимо обеспечивать обратное преобразование? Более того, помню, что когда-то, при настройке сервера, у нас как раз не было реализовано обратное преобразование, и почта на многие домены не ходила...

[nuclearcat]

Ибо спаммеры задрали :)

[azhur]

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

1) HELO/EHLO проверятеся на существование соответствующей A;

2) Src IP проверяется на существование валидной пары PTR-A.

Если A из пунктов 1 и 2 совпадают - замечательно, но не обязательно.

В таком виде оно вполне преемлемо работает.

Про обратное преобразование в данном RFC вообще ничего не написано. Почему же все рекомендации по настройке почтовиков утверждают, что необходимо обеспечивать обратное преобразование?

При обсуждении этого вопроса в Интернетах обычно ссылаются на RFC 1912, пункт 2.1.

Every Internet-reachable host should have a name.

...

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

[Abram]

Обратную зону давно уже никто не проверяет - смысла нет, false positive больше, чем пользы.

Проверяйте лучше SPF.

[NiTr0]

SPF не панацея, есть горка спам-хостов (с хетцнера и т.п. хостингов) с верными SPF. Хотя да, в блэк-лист их реально все упихать, ибо их немного...

[YuryD]

Получается, что проверка на reverse DNS неэффективна и не имеет смысла её использовать в почтовых серверах? Но она значительно снизила поток спама, не хотелось бы отказываться от неё.

Главное, что in ptr есть. А уж что там написано - дело десятое. Например что прописать для почтовика, обслуживающего десяток доменов ? Но spf лучше.

[wtyd]

Получается, что проверка на reverse DNS неэффективна и не имеет смысла её использовать в почтовых серверах? Но она значительно снизила поток спама, не хотелось бы отказываться от неё.

Главное, что in ptr есть. А уж что там написано - дело десятое. Например что прописать для почтовика, обслуживающего десяток доменов ? Но spf лучше.

 

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

 

ptr можно проверять на его наличие -- если нет "давай до свидания", если есть, то тут уже возможны варианты и в принципе можно больше не проверять :-). exim несколько запросов делает и смотрит на разные соответствия. Сам эту фичу не использую.

 

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