Dmitry Zubov описал (http://dz.dn.ua/spam/antispam.html) достаточно жесткую схему фильтрации спама на почтовом сервере работающем под управлением sendmail (FreeBSD).
Схема предусматривает блокировку хостов без обратной зоны или несовпадении "PTR" и "A" записей, подключение проверки в DNSBL системах, обратную проверку существования адреса через milter-sender.
URL: http://dz.dn.ua/spam/antispam.html
Новость: http://www.opennet.me/opennews/art.shtml?num=5368
Блин, стрелял бы, тех кто отлупает по не совпадению ДНС-информации!!!На одном и том же хосте может быть пачка адресов из одной и той же сетки, плюс за каждым из них может числиться набор имен. И резолвер у сендмыла, да и не только у него, это прощелкивает на счет раз :(
Уважаемый! Вы как давно делали такую фильтрацию?
В курсе ли Вы что Yandex, etc не говорят Вам действительную информацию о пользователях?...
>Блин, стрелял бы, тех кто отлупает по не совпадению ДНС-информации!!!Стрелял, а затем добивал бы прикладом тех,
кто у себя это настроить не может. Ненавижу!ИМХО: политика отлупа на стадии соединения,
наиболее верная ... Главное при этом соблюдать
осторожность при выборе "черных списков".
Всякие там спам-ассасины - штука конечно полезна,
но на бабки ты уже попал ... Письмо, то сервак получил. А когда этих писем 20-30 тысяч ...
dig ns.catalysis.ru
dig caty.catalysis.ru
dig -x 193.124.35.68Что здесь неправильно??? Однако, отбивали, когда эта машина была МХом в свое время. Еще раз повторюсь, резолверы на таких вещах рушатся.
Отлуп на стадии соединения, правда, самое верное решение. Вот только реализация этого отлупа может быть разной.
>Что здесь неправильно??? Однако, отбивали, когда эта машина была МХом в свое
Неправильно, то что в RFC[2]821 нет _четкого_ описания что является "main hostname" для multi-homed хостов.
Зато в 2821 четко сказанно:
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 строем и песнями идут в сад.>время. Еще раз повторюсь, резолверы на таких вещах рушатся.
Шутите?
>Зато в 2821 четко сказанно:
> 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 строем и песнями идут в сад.Полностью согласен. Однако вопрос в том как резать.
Можно проверять валидность предоставленного helo (например не домен получателя), можно проверять чтобы это был не ip-адрес, а [ip-адрес], как требует RFC. В таких случаях смело можно рубить.
Дальнейшая проверка (горячо обсуждаемые здесь совпадения по обратной зоне , черные списки и т.д. ) должна использоваться не для разрыва связи, а для применения задержек в ответах. Большинство спамеров отвалится за нарушение последовательности команд. Валидные сервера (пусть и криво настроенные) будут слать одно собщение минуту, но вот это уже их проблемы. Хочу отметить что задержки должны быть не для всех, а только для подозрительных клиентов.
При такой схеме процентов 50 спама отваливается, а процент потери "правильных" писем равен нулю.
>Валидные сервера (пусть и криво настроенные) будут слать одно собщение минуту,
>но вот это уже их проблемы. Хочу отметить что задержки должны
>быть не для всех, а только для подозрительных клиентов.
>При такой схеме процентов 50 спама отваливается, а процент потери "правильных" писем
>равен нулю.
Тут есть одно большое, но - это замечательно работает на не больших релеях, а тяжелый релей из-за этих пауз в моменты спамерской активности моментально упрется в собственный лимит на количество одновременных сессий.
>>Валидные сервера (пусть и криво настроенные) будут слать одно собщение минуту,
>>но вот это уже их проблемы. Хочу отметить что задержки должны
>>быть не для всех, а только для подозрительных клиентов.
>>При такой схеме процентов 50 спама отваливается, а процент потери "правильных" писем
>>равен нулю.
>Тут есть одно большое, но - это замечательно работает на не больших
>релеях, а тяжелый релей из-за этих пауз в моменты спамерской активности
>моментально упрется в собственный лимит на количество одновременных сессий.Максимальное число открытых соединений - настраиваемый параметр. По большому счету он оказывает влияние на требования к аппаратному обеспечению сервера. Если одного сервера недостаточно, можно поставить дополнительные и прописать их в MX. Основной сервер при достижении определенного уровня нагрузки начинает рубить соединения. По идее в таком случае клиент ищет следующий MX и шлет почту через него. Я такую схему лично не проверял, но вроде бы в этом и заключается смысл MX записей.
У меня и так четыре frontend'a на MX вы предлагаете мне поставить еще 4.
Дело в самом способе - вместо того, что бы быстренько послать клиента нафиг/ принять его почту, вы предлагаете висеть и нифига не делать.
Повторюсь: pre-gretting и прочие паузы для нагруженных релеев не приемлемы, на маленьких - работают очень хорошо.
>У меня и так четыре frontend'a на MX вы предлагаете мне поставить
>еще 4.
>Дело в самом способе - вместо того, что бы быстренько послать клиента
>нафиг/ принять его почту, вы предлагаете висеть и нифига не делать.
>
>Повторюсь: pre-gretting и прочие паузы для нагруженных релеев не приемлемы, на маленьких
>- работают очень хорошо.Основное преимущество метода - возможность отсеять большое количество спама с гарантией нулевой потери валидной почты. Если у вас получается отсеять спам с приемлемой эффективностью без этой меры и такой подход приводит к снижению затрат на оборудование/содержание/трафик, тут и спорить не стану.
Отмечу только что для меня при фильтрации спама основное требование - полное отсутствие потерь валидной почты по вине моего сервера. Сервер действительно слабонагруженный, поэтому метод вполне устраивает.
так у вас возможны точно те же проблемы, что и у меня, только вероятность их возникновения существенно ниже :)
Плюс требуется очень небольшое изменение спамерского софта, для обхода
пауз - им пофиг, что зомби загнется от тысяч параллельных конектов...
>Плюс требуется очень небольшое изменение спамерского софта, для обхода
>пауз - им пофиг, что зомби загнется от тысяч параллельных конектов...
Пока что легче для спамеров оказывается не обходить задержки, а терять небольшой процент успешно отправленного спама от полной рассылки.
Вводить реакцию на задержки в расылочный софт имеет смысл когда процент серверов с задержками станет достаточно большим. Но в этом случае упадет количество писем, отсылаемое спамером (или его затрояненной жертвой) в единицу времени. Это не может не радовать :-)
Боюсь нам с вами от этого легче не будет - число зомбированных сетей растет как на дрожжах, они возьмут свое количеством. Но пока работает - грех не использовать любую возможность :)
>Боюсь нам с вами от этого легче не будет - число зомбированных
>сетей растет как на дрожжах, они возьмут свое количеством. Но пока
>работает - грех не использовать любую возможность :)Предлагаю на этом закончить дискуссию, налить по кружечке пива и выпить за кончину спамерского дела. Которой все равно не произойдет, но уж очень хочется )
За это и водки можно :)
>За это и водки можно :)
Тогда придется закуску искать, а мне сегодня обед не привезли )
Пойду найду в спаме рассылку про пиццу ))))))))
>Основное преимущество метода - возможность отсеять большое количество спама с гарантией нулевой
>потери валидной почты.И вам не попадались отсылающие скрипты с небольшим таймаутом или MTA админ которых по незнаю или злому умыслу баловался настройками таймаутов ?
Встречал сервер который обрабатывает сотни списков рассылки, там таймаут на HELO несколько секунд, непрошло десяток писем - автоотписка, ибо в рассылке заинтересованы получатели, а серверу важнее успеть разослать все письма как можно скорее.
>>Основное преимущество метода - возможность отсеять большое количество спама с гарантией нулевой
>>потери валидной почты.
>
>И вам не попадались отсылающие скрипты с небольшим таймаутом или MTA админ
>которых по незнаю или злому умыслу баловался настройками таймаутов ?Если админ по незнанию, а тем более по злому умыслу балуется таймаутами, согласитесь, это полностью его право и его ответственность. Если клиент (будь то скрипт или некорректно настроенный MTA) нарушает требования протокола, я не чувствую своей вины в том что такому клиенту будет отказано в обработке почты.
>Встречал сервер который обрабатывает сотни списков рассылки, там таймаут на HELO несколько
>секунд, непрошло десяток писем - автоотписка, ибо в рассылке заинтересованы получатели,
>а серверу важнее успеть разослать все письма как можно скорее.Опять же, речь идет о нарушении протокола, в соответствии с которым клиент должен ожидать ответа сервера в течение нескольких минут. Я на своем сервере использую задержку в 20 секунд (обращаю внимание на то что задержка включается только для клиента с подозрительным именем или попавшего в черные списки, для остальных клиентов задержка отсутствует). На мой взгляд это достаточно небольшое время с точки зрения корректного МТА с одной стороны, и вполне достаточное для того чтобы вызвать ошибку синхронизации в работе некорректно натсроенного клиента.
to unk:
А какими вы методами пользуетесь против спама?
reject клиента и MX/NS домена из MAIL по "мягким" RBL, greylisting + встречная проверка по "жестким" rbl, reject на высокие баллы антиспама после DATA
>reject клиента и MX/NS домена из MAIL по "мягким" RBL, greylisting +
>встречная проверка по "жестким" rbl, reject на высокие баллы антиспама после
>DATAантиспам после DATA - какой ?
>антиспам после DATA - какой ?
spamassassin без Байеса + человек пишущий под него правила
>dig ns.catalysis.ru
>dig caty.catalysis.ru
>dig -x 193.124.35.68
>
>Что здесь неправильно??? Однако, отбивали, когда эта машина была МХом в свое
>время. Еще раз повторюсь, резолверы на таких вещах рушатся.
>
>Отлуп на стадии соединения, правда, самое верное решение. Вот только реализация этого
>отлупа может быть разной.
А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или caty.catalysis.ru
>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или
>caty.catalysis.ru
Какая разница, как был прописан MX, когда проблемы с эмитером???
Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя...
>>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или
>>caty.catalysis.ru
>Какая разница, как был прописан MX, когда проблемы с эмитером???
>Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя...
>
Я нормально спросил. Хамить необязательно.
У вас там caty.catalysis.ru описан как CNAME.
Соответственно нельзя ставить caty.catalysis.ru в качестве MX-а.
Это говорят даже на дешевых курсах по сетевому администрированию.
Но больше всего удивляет наличие PTR записи кторая указывает на имя описаное как CNAME. Такой фокус вместо одного запроса к ДНС заставляет делать два.
Второй как раз на преобразование CNAME записи.
Вы сами себе придумали грабли. А если быть точным, то это напоминает установку костыля там где не надо.
Для MX-а должно совпадать прямое и обратное преобразование ДНС.
Даже при наличии двух и больше интерфейсов с разными ИП адресами.
>>>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или
>>>caty.catalysis.ru
>>Какая разница, как был прописан MX, когда проблемы с эмитером???
>>Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя...
>Я нормально спросил. Хамить необязательно.
Где вы хоть каплю грубости увидели?>У вас там caty.catalysis.ru описан как CNAME.
Не у меня, но не суть. (Ваши высказывания верны, но к делу не относятся)
Прочитайте внимательно - у Андрея была проблема с _исходящей_ почтой.
Причем тут MX?
>>>>А когда машина была MX-ом, в IN MX что стояло? ns.catalysis.ru или
>>>>caty.catalysis.ru
>>>Какая разница, как был прописан MX, когда проблемы с эмитером???
>>>Из-за любителей резать все подряд использовать multi-homed хост как исходящий релей нельзя...
>>Я нормально спросил. Хамить необязательно.
>Где вы хоть каплю грубости увидели?
Сорри, среагировал на "любителей резать все подряд".>
>>У вас там caty.catalysis.ru описан как CNAME.
>Не у меня, но не суть. (Ваши высказывания верны, но к делу
>не относятся)
>Прочитайте внимательно - у Андрея была проблема с _исходящей_ почтой.
>Причем тут MX?
Он отправлял почту со своего домена, но сам в собственном домене был прописан неправильно. Ибо тот, кому он отправлял почту, иного способа проверки валидности почтового сервера и домена, с каторого отправляется почта, кроме как через ДНС не имеет.
Вот тут и проблема.
Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не прошел элементарную проверку.
Не совсем понятно назначие этого CNAME в качестве MX-а когда есть прекрасная запись типа ns.catalysis.ru. Этого хватило бы на что угодно.
Даже на multi-homed в качестве релея.
>Вот тут и проблема.
>Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не
>прошел элементарную проверку.
Ну раскройте секрет чем CNAME мешает проверке совпадения gethostbyaddr() и gethostbyname()
>>Вот тут и проблема.
>>Андрей описал свой почтовый сервер как CNAME в ДНС и соответственно не
>>прошел элементарную проверку.
>Ну раскройте секрет чем CNAME мешает проверке совпадения gethostbyaddr() и gethostbyname()
Только не обижайтесь.
---
Удаленный хост получает соединение на 25 порт и получает команду
mail from: vasya@catalysis.ru
Почтовый сервер делает проверку типа dig catalisys.ru MX
Получает ответ elm.catalysis.ru
Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71
Получаем elm.catalysis.nsk.su
Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su
Обрываем соединение.
---
Какие с этим алгоритмом проблемы?
>Удаленный хост получает соединение на 25 порт и получает команду
>mail from: vasya@catalysis.ru
>Почтовый сервер делает проверку типа dig catalisys.ru MX
>Получает ответ elm.catalysis.ru
>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71
>Получаем elm.catalysis.nsk.su
>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su
>Обрываем соединение.
>---
>Какие с этим алгоритмом проблемы?
Простите, но это не алгоритм, а бред вашего воображения.
(объяснять почему не буду - похоже все очень запущенно)
>>Удаленный хост получает соединение на 25 порт и получает команду
>>mail from: vasya@catalysis.ru
>>Почтовый сервер делает проверку типа dig catalisys.ru MX
>>Получает ответ elm.catalysis.ru
>>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71
>>Получаем elm.catalysis.nsk.su
>>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su
>>Обрываем соединение.
>>---
>>Какие с этим алгоритмом проблемы?
>Простите, но это не алгоритм, а бред вашего воображения.
>(объяснять почему не буду - похоже все очень запущенно)
Взаимно.
>>>Удаленный хост получает соединение на 25 порт и получает команду
>>>mail from: vasya@catalysis.ru
>>>Почтовый сервер делает проверку типа dig catalisys.ru MX
>>>Получает ответ elm.catalysis.ru
>>>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71
>>>Получаем elm.catalysis.nsk.su
>>>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su
>>>Обрываем соединение.
>>>---
>>>Какие с этим алгоритмом проблемы?
>>Простите, но это не алгоритм, а бред вашего воображения.
>>(объяснять почему не буду - похоже все очень запущенно)
>Взаимно.
Вы понимаете, что этот "алгаритм" режет все почтовики класса mail.ru?
>>>>Удаленный хост получает соединение на 25 порт и получает команду
>>>>mail from: vasya@catalysis.ru
>>>>Почтовый сервер делает проверку типа dig catalisys.ru MX
>>>>Получает ответ elm.catalysis.ru
>>>>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71
>>>>Получаем elm.catalysis.nsk.su
>>>>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su
>>>>Обрываем соединение.
>>>>---
>>>>Какие с этим алгоритмом проблемы?
>>>Простите, но это не алгоритм, а бред вашего воображения.
>>>(объяснять почему не буду - похоже все очень запущенно)
>>Взаимно.
>Вы понимаете, что этот "алгаритм" режет все почтовики класса mail.ru?
Прекрасно.
Вот чего я не понимаю, так это почему почтовики класса mail.ru или назовем их freenail, не могут позволить себе приделать авторизацию для релея через себя с любых адресов. Тогда и SPF можно будет запустить в более жестком режиме.Главноя проблема состоит даже не в этом алгоритме или любом другом.
А в том, что никого на сегодняшний день не заботит возможность отправки спама третьими лицами с использованием обратных адресов из домена, защищаемого от приема спама, сервера. На мой почтовый сервер ежеминутно приезжает около 10-20 писем с подделаными адресами под известные freemail-ы типа mail.ru, yahoo.com, и.т.
>>>>>Какие с этим алгоритмом проблемы?
>>>>Простите, но это не алгоритм, а бред вашего воображения.
>>>>(объяснять почему не буду - похоже все очень запущенно)
>>>Взаимно.
>>Вы понимаете, что этот "алгаритм" режет все почтовики класса mail.ru?
>Прекрасно.
Вы ничего не понимаете, дело не в free, и не в их объемах, не в SPF и авторизации, а в том, что MX и эмиттер могут быть совершенно разными машинами и сравнивать адрес MX-а из "MAIL" c адресом клиента - малограмотный бред.
Смотрите ваш алгоритм:
petya@mail.ru
1) dig +short mail.ru MX: mxs.mail.ru
2) (клиент mx7.mail.ru) dig +short 194.67.23.27: mx7.mail.ru
3) mxs.mail.ru != mx7.mail.ru: REJECT, пинки от начальства, плевки коллег, вылетаете с работы, занавес.
>Удаленный хост получает соединение на 25 порт и получает команду
>mail from: vasya@catalysis.ru
>Почтовый сервер делает проверку типа dig catalisys.ru MX
>Получает ответ elm.catalysis.ru
>Зная ИП адрес с которого идет письмо, проверяем dig -x 193.124.35.71
>Получаем elm.catalysis.nsk.su
>Сравнением стрингов получаем elm.catalysis.ru<>elm.catalysis.nsk.su
>Обрываем соединение.
>---
>Какие с этим алгоритмом проблемы?Вот теперь смотрите:
1 у меня есть 2 домена catalysis.ru и catalysis.nsk.su, за которыми стоит одна и таже сеть.
2 письма на xxx@catalysis.ru и xxx@catalysis.nsk.su должны попадать одному и тому же юзеру.
3 юзер сам по собственному желанию выбирает, с какого адреса он шлет почту: xxx@catalysis.ru или xxx@catalysis.nsk.su
4 я должен иметь 2 PTR записи для адреса 193.124.35.71 -- по одной для каждого домена. В противном случае один из доменов перестает работать. Это эмпирический факт.
Имеем:
1 при не правильной организации проверки на принимающей стороне ~25% писем будет отбиваться.
2 если заставить постфикс на моем серваке всегда говорить только один домен, то перестает работать второй (отдельные умельцы проверяют строку из HELO и домен адресата, блин!, давил бы.)
3 единственный разумный вариант проверки по обратному резолвингу:
а) видим, что мейл фром: user@domain.com
б) проверяем список МХов для domain.com
в) составляем список IP: для _каждого_ МХа выбираем _все_ его IPшники и добавляем к списку
г) проверяем, есть ли IP, с которого идет коннект, в этом списке. Если есть принимаем письмо, если нет, отбриваем.Все бы ничего, да только шаг В никто не выполняет :( Берут первый попавшийся адрес и считают что это единствено возможный вариант.
>3 единственный разумный вариант проверки по обратному резолвингу:
> а) видим, что мейл фром: user@domain.com
> б) проверяем список МХов для domain.com
> в) составляем список IP: для _каждого_ МХа выбираем _все_ его IPшники
>и добавляем к списку
> г) проверяем, есть ли IP, с которого идет коннект, в этом
>списке. Если есть принимаем письмо, если нет, отбриваем.
У вас та же проблема, что и у предыдущего господина. Почему вы так упорно хотите что бы MX и эмиттер были одной машиной? Ваш алгоритм точно так же обламывает все крупные релеи - в сад.
>>3 единственный разумный вариант проверки по обратному резолвингу:
>> а) видим, что мейл фром: user@domain.com
>> б) проверяем список МХов для domain.com
>> в) составляем список IP: для _каждого_ МХа выбираем _все_ его IPшники
>>и добавляем к списку
>> г) проверяем, есть ли IP, с которого идет коннект, в этом
>>списке. Если есть принимаем письмо, если нет, отбриваем.
>У вас та же проблема, что и у предыдущего господина. Почему вы
>так упорно хотите что бы MX и эмиттер были одной машиной?
>Ваш алгоритм точно так же обламывает все крупные релеи - в
>сад.Я этого не хочу. Просто конкретно в моей ситуации, этого хватило бы :)
Но даже в моей ситуации, масса почтовиков отбивает...
>>У вас та же проблема, что и у предыдущего господина. Почему вы
>>так упорно хотите что бы MX и эмиттер были одной машиной?
>>Ваш алгоритм точно так же обламывает все крупные релеи - в
>>сад.
>Я этого не хочу. Просто конкретно в моей ситуации, этого хватило бы
>:)
Если не хотите, и понимаете, то зачем пишете, да еще называете "единственно правильным"...
Все что можно проверить в плане DNS из "MAIL FROM" - это сам факт существования MX или A для этого домена. Все.>Но даже в моей ситуации, масса почтовиков отбивает...
Я вам уже говорил - использовать multi-homed хост в качестве эмиттера опасно т.к. фактически существующие почтовые RFC этого не предусматривают.
>Вот теперь смотрите:
>
>1 у меня есть 2 домена catalysis.ru и catalysis.nsk.su, за которыми стоит
>одна и таже сеть.
>
>2 письма на xxx@catalysis.ru и xxx@catalysis.nsk.su должны попадать одному и тому же
>юзеру.
>
>3 юзер сам по собственному желанию выбирает, с какого адреса он шлет
>почту: xxx@catalysis.ru или xxx@catalysis.nsk.sunsk.su - устаревшая зона
Поэтому выход такой:
Оставляешь адреса только xxx@catalysis.ru
Почта на xxx@catalysis.nsk.su пересылается на xxx@catalysis.ru
У пользователя НЕТ ВЫБОРА - его адрес xxx@catalysis.ruПредупреждаешь всех пользователей,
чтобы они сообщили всем своим абонентам
что адреса xxx@catalysis.nsk.su устарели и
больше не стоит их использовать.
Всячески это дело рекламируется.Через год вставляешь автоматический redirect.
Это когда почта автоматически не пересылается,
а абонент получает сообщение, что слать почту нужно
на xxx@catalysis.ruДелал переезд с одного домена в другой В СПЕШНОМ ПОРЯДКЕ
Можно сказать в соседнем институте кстати :)
И ничего - все живы
Дмитрий,>Я нормально спросил. Хамить необязательно.
во-первых, хамящий анонимус к моему Институту отношения не имееет, и со мной ничего общего не имеет так же :)>У вас там caty.catalysis.ru описан как CNAME.
>Соответственно нельзя ставить caty.catalysis.ru в качестве MX-а.
>Это говорят даже на дешевых курсах по сетевому администрированию.
В те далекие времена caty было именем хоста, а ns был CNAME'ом.>Но больше всего удивляет наличие PTR записи кторая указывает на имя описаное
>как CNAME. Такой фокус вместо одного запроса к ДНС заставляет делать
>два.
>Второй как раз на преобразование CNAME записи.
>Вы сами себе придумали грабли. А если быть точным, то это напоминает
>установку костыля там где не надо.
>Для MX-а должно совпадать прямое и обратное преобразование ДНС.
>Даже при наличии двух и больше интерфейсов с разными ИП адресами.
Поверьте на слово, плс, изначально так и было сделано. Гарантировано работает только один вариант, понятно даже какой :)Любой другой вариант, приводит к тому, что какой-нибудь удаленный хост перестает принимать почту, прибегает юзверь и начинает жалабно голосить.
Полный перебор всех возможных комбинаций в настройках ДНСа, показывает, что для _любой_ конфигурации, найдется хотя бы один хост, который будет гнусно отказываться принимать почту.
вот если бы статью опубликовали типа "Блокирование спама на этапе создания письма" как бы было замечательно :)
greylist рулит :)
Надо - дошлешь через часок.
Если бы один процент получателей спама один раз в день звонил бы по одному из спам-писем и посылал бы заказчика спама на пенис, в вульву, в анус и т.п., то спам бы скоро прекратился как явление.
то он умер бы с голоду - не хватило бы веремени на еду.
Ув. Dmitry U. Karpov, если каждому звонить ты попадёшь на ещё одни бабки, плюс испортишь себе нервы. Нафига это надо? А статья хорошая.
Я делаю один звонок в день (ну, три, если хочется поругаться). Звонок местный (подавляющее большинство русскоязычного спама рекламирует московские фирмы). Неужели остальным спамополучателям трудно повторить мой подвиг?
>Звонок местный
Отучаемся говорить за всю сеть.
>(подавляющее большинство русскоязычного спама рекламирует московские фирмы).
Вот именно. Буду я каждому дерьму из Питера в Москву звонить.
To Zerg
>ИМХО: политика отлупа на стадии соединения,
>наиболее верная ...
---
Так и до геноцида недалеко:)
Типа, расстреливать всех с карими глазами, и не нужно тратится на дальнейшую проверку личности...
Отбрасывать на основе отсутствия обрятной зоны - неправильно. Мы обратную зону и провайдера выбиваем уже месяц, и дело двигается со скрипом. А провайдера поменять не можем. Никак.А по поводу отсылать к создателям списков - вы когда нить пробовали из http.dnsbl свой адрес вытащить? У меня не получилось, хотя никаких проксей с момента моего прихода на работу не осталось. Проблема решилась только пивом админу, чтоб он отдал нам незабаненный ip из пула провайдера.
В общем хуже спама может быть только антиспам - я (как пользователь) предпочитаю получить 50 писем спама и 1 нужное письмо, чем не получить ничего. А все проблемы у пользователей от того, что локальный bayes в клиенте настроить не могут. А проблемы админов (перегрузка серваков, большой трафик) пользователей касаться не должны :)
>bayes в клиенте настроить не могут. А проблемы админов (перегрузка серваков,
>большой трафик) пользователей касаться не должны :)
Вы знаете, если отключить вирус/спам фильтры, то нагрузка на сервера упадет в разы, а за трафик заплатите вы как пользователь...
> провайдера выбиваем уже месяц,
???????????? Это супер! Святопевздевевский Узел Электрической Связи?
Модемы на педальной тяге?
И кизяке в дежурном режиме в темное время суток?> вы когда нить пробовали
> из http.dnsbl свой адрес вытащить?
30 минут на любой случай.> 50 писем спама и 1 нужное письмо,
> чем не получить ничего.
Деловые письма теряются значительно реже. Напрмер - никогда.> А проблемы админов (перегрузка серваков,
> большой трафик) пользователей касаться не должны :)
У админов нет проблем. Проблемы с потерей рабочего времени у юзеров.
Пользователи ТРЕБУЮТ быть избавленными от гавна, которое ты, скот, валишь им в ящики.> хуже спама может быть только антиспам
Похоже ты тот самый спамер и есть? Убил бы!!!
Блокирование на этапе соединения - правильная вещь, но пользоваться ею надо с умом.Наличие обратной зоны (без разницы что там записано) - практически обязательное условие для почтового сервера. А если какой-то провайдер не может этого обеспечить - это проблема провайдера и его клиента. И ее надо решать, а не ссылаться на трудности.
Совпадение А и PTR - это было бы замечательно хорошо, но уж слишком много проблем с этим. Лучше проверять HELO и существование домена указанного в HELO в принципе (неважно куда этот домен глядит). Процент ошибочных срабатываний из-за неправильной настройки оправляющего сервера небольшой, и проблема обычно решается достаточно быстро, т.к. зависит только от админа сервера.
Кроме того можно отбрасывать соединения с PTR-ами явно сделаными для DIALUP-ов, ADSL-ей и проч. Хотя и тут случаются ошибки, но их можно занести в исключения.DNSBL - это гадость. Неоднократно сталкивался с неадекватным поведением.
Думаю, что отсеивание 80% спама на этапе содинения - это хороший показатель. Далее должен работать спамассассин.
>Блокирование на этапе соединения - правильная вещь, но пользоваться ею надо с
>умом.
Абсолютно согласен.
Не понимаю админов, которые пихают все подряд списки без разбора. Например админы mtu-net.ru :)>Наличие обратной зоны (без разницы что там записано) - практически обязательное условие
>для почтового сервера. А если какой-то провайдер не может этого обеспечить
>- это проблема провайдера и его клиента. И ее надо решать,
>а не ссылаться на трудности.
Как её решить, если интеренет дает арендатор помешения, и других провайдеров в здании нет и не будет никогда? Сменить офис? (варианты радио этзернета и АДСЛ не катят) Или поместить сервер на площадку и настраивать SMTP relay?
К тому же с обратными зонами всегда гимор - как правило их держат первичные провайдеры провайдеров (во загнул!), а нашему провайдеру (да и любом провайдеру средней руки) ради клиента списываться с саппортом первичного прова накладно (время его работников - эт тоже деньги).
Хотя своего мы уговорили, он отписался, теперь ждем что ответят. Судя по всему ждать долго придется, такие запросы обычно в посл. очередь обрабатывают. Наверно придется звонить :)
>Совпадение А и PTR - это было бы замечательно хорошо, но уж
>слишком много проблем с этим. Лучше проверять HELO и существование домена
>указанного в HELO в принципе (неважно куда этот домен глядит). Процент
>ошибочных срабатываний из-за неправильной настройки оправляющего сервера небольшой, и проблема обычно
>решается достаточно быстро, т.к. зависит только от админа сервера.
Согласен.
>Кроме того можно отбрасывать соединения с PTR-ами явно сделаными для DIALUP-ов, ADSL-ей
>и проч. Хотя и тут случаются ошибки, но их можно занести
>в исключения.
Тоже вариант. Только следить тщательно надо.>DNSBL - это гадость. Неоднократно сталкивался с неадекватным поведением.
Можно использовать, только очень осторожно, следить за логами, разрешать нужные сервера... И ни в коем случае не посылать к создателям списка, ибо это как правило бесполезно (если обращаются к нам, значит с создателями списка скорее всего уже ничего не вышло)>Думаю, что отсеивание 80% спама на этапе содинения - это хороший показатель.
Я согласен и на 70%, лишь бы нужная почта ходила :)>Далее должен работать спамассассин.
Я склоняюсь к тому, чтоб дальнейшая фильтрация была на стороне и под контролем клиента.
>В общем хуже спама может быть только антиспам - я
>(как пользователь) предпочитаю получить 50 писем
>спама и 1 нужное письмо, чем не получить ничего. А
>все проблемы у пользователей от того, что локальный
>bayes в клиенте настроить не могут. А проблемы
>админов (перегрузка серваков, большой трафик)
>пользователей касаться не должны :)Конечно не должны ... если пользователь платит за траффик. Но обычно почему то оной пользователь
начинает возмущаться!>Так и до геноцида недалеко:)
> Типа, расстреливать всех с карими глазами,
> и не нужно тратится на дальнейшую проверку
>личности...ну тут не карие глаза, а шрам во всю морду,
да еще оная морда и небритая :)а если серьезно, то я пробовал, обходиться без
"черных списоков" ... пипец полный!!!! ...
абсолютный ...
Когда адреса можно взять с сайта, и при этом сами пользователи ведут себя не осторожно ...
Топ 10 у меня - не менее 500 на человека в день.
Траффик+нервы+ресурсы(из проверки на спам и вирус)
улетают в трубу.
ИМХО ОСНОВНAЯ ПРОБЛЕМА: это то, что держатели
некоторых черных список уроды ... И выписаться
от туда не практически не возможно :(.
Даже если ты все исправил, то все равно тебя
оттуда не выпишут. Такое часто бывает в отношениях
заруб. черный список <-> русский "штрафник".
Причем даже зачастую причину отказываются назвать.ЗЫ: все идет по грифом "ИМХО"
Zerg, ты не прав. Нельзя по несовпадению ДНС-информации отшибать.
Похоже, автор держит маленький почтовый сервер для себя одного в своей полностью администрируемой подсети, проблемы пользователей его не волнуют, и переписывается только со своими 10(100) знакомыми.
Т.е. поддержка сервером нескольких почтовых доменов или получение почты с серверов мелких контор, не могущих прописать обратную зону - исключаются.
>Похоже, автор держит маленький почтовый сервер для себя одного в своей полностью
>администрируемой подсети, проблемы пользователей его не волнуют, и переписывается только со
>своими 10(100) знакомыми.
>Т.е. поддержка сервером нескольких почтовых доменов или получение почты с серверов мелких
>контор, не могущих прописать обратную зону - исключаются.грубовато сказано! если не сказать по хамски ...
по крайней мере мне так показалось ... извините если ошибся.
Если контора не может прописать себе обратную зону ... то пошли они в зад!
Простите за грубость, но это правильно ...
Давайте принимать без реверса, далее не пользоваться черными списками, далее не сканировать на вирусы (а вдруг важное письмо), и прочее ...
Прописание реверса - это всего лишь правильно оформленное письмо к провайдеру, и все.
Мля! слов нету !!! Что такое 40 000 писем в день ?!
из них 99% спам ? так фигня ... зато серди них обязательно одно
и супер важное ! Ну ладно я понимаю : кривые "черные списки" ...
ну элементарные вещи, то можно делать ? реверс например!
ИМХО: обязательно надо использовать
"черные списки" , проверка реверса, milter-sender, spamassassinКак мне кажется - это оптимальная комбинация.
Народ, поверьте плиз, личный пример, насчет рекламного агенства:
spamassin далеко не всегда помогает, а поток дерьма без
использования первых 3 ступенек просто колоссален!
Если вы претендуете на должность администратора в приличной конторе, а не эникейщика по-быстрому клепающего сервера то извольте соблюдать правила. RFC не просто так пишут. Не правы и те кто отшивает по hello и те чьи кривые сервера правильно это hello сказать не могут. Почитав логи почтовика сразу видно в какой конторе какой ламер работает. И не надо тут орать что реверс у прова не выбить и это все они, а я хороший. В RFC четко сказано "The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name and supplemental information provided that will assist in identifying the client." поэтому если ваш сервак имеет статический IP, то извольте настроить его ТАК что бы он отвечал hello соответственно реверсу этого IP, либо отвечал самим ip адресом если адрес динамический, а иначе это не smtp сервер - а так... порождение вашей криворукости. Если нет возможности выбить "обратку" держите сервера у тех кто это может обеспечить. Сейчас практически любой платный хостинг в довесок к сайту дает бесплатно почту, чаще всего нормально настроенную. Тогда можно будет со спокойной совестью заявить что я сделал все что возможно чтобы отправлять легитимную почту и спокойно обсирать тех кто режет по helo за то что уже они нарушают RFC какими бы мотивами это не было вызвано. Но это уже означает что им эта почта просто не нужна.
Дело, видимо, не в чьей-то криворукости, узколобости, any'кейности и т.п. Вопрос в том - какие задачи ставятся перед тем или иным администратором(и кем ставятся). Если кого-то ни разу на денежку не сажали за входящий офигенный почтовый трафик, значит ему просто повезло. В этом деле никакой spamassassin не спасет (конечно, если на почтовом сервере не 100 полумертвых ящиков). С другой стороны, администраторы почтовых серверов больших сетей, где клиент платит денежку и хочет(вынужден) сам разбираться с почтой, могут смело попивать пиво и говорить о RFC, о массовых расстрелах или просто помогать детям закрыть popup-окна. Как правило, именно такие сети попадают в черные списки первыми и, честно говоря, я мало представляю себе как с этим бороться(взять тот же СТРИМ - уже тама).
Отшивание по hello у нас вынужденная мера. Но за год с момента введения правил фильтрации случаи отшивания "правильной" почты были единичны. А у нас работают журналисты, редакторы и т.п. которым нужна постоянная связь с регионами, с буржуями. Будь иначе - меня давно уволили ли. С черными листами чуть сложнее - взять тот же СТРИМ. Он никогда не вылезет из черных списков. Тут приходится использовать собственные списки позволяющие пустить клиента до проверки в черных листах.
># greylist рулит :)
>удостоверится в существовании E-Mail адреса отправителяПрименение этих методов - плохое решение.
Они действительно иногда эффективны, но лишь потому, что используются относительно редко, и спамерам просто не охота связываться с этими "исключениями". Понятно, что обход серых списков осуществить очень просто.
Что же касается проверки реальности адреса отправителя, то представтьте, что было бы если бы все её у себя ввели: господа чесные спамеры использовали бы реальные адреса.
Так что, те кто используют эти методы, на мой взгляд, не честно играют.Про статью, что сказать... Похвально стремление автора изучать sendmail. А что будут жертвы, так на ошибках учатся.
А вот не новая статейка, вдруг кто не читал: http://www.armory.com/~spcecdt/spamware/
Почему бы, например, не использовать критерии из обсуждаемой статьи не для того, чтобы почту отвергнуть сразу, а заставить подождать побольше?
Исключительно безвредно и где-то даже эффективно, сам проверял-с
>Исключительно безвредно и где-то даже эффективно, сам проверял-с
pre greeting delay эффективен только при маленьких объемах почты, для больших сайтов это DOS устроенная самому себе - во время пиков спамерской активности мы мгновенно упремся в лимит одновременных сессий.
>pre greeting delay эффективен только при маленьких объемах почты
>для больших сайтов это DOS устроенная самому себе
Не любой ли расход ресурсов, с которым не справляется оборудование - DOS cамому себе? Пусть "Большим сайтам" будет всегда достаточно своих ресурсов, и пусть не бурут, если им не хватает, из ресурсов тех, кого они обслуживают.
>>pre greeting delay эффективен только при маленьких объемах почты
>>для больших сайтов это DOS устроенная самому себе
>Не любой ли расход ресурсов, с которым не справляется оборудование - DOS
>cамому себе? Пусть "Большим сайтам" будет всегда достаточно своих ресурсов, и
>пусть не бурут, если им не хватает, из ресурсов тех, кого
>они обслуживают.
Одно дело когда вас DOS'ят или действительно не хватает мощей железа, а другое когда вы роете яму для себя самостоятельно...
Или вы знаете хоть один MTA заточенный на удержание >1k клиентов одновремено?
> Или вы знаете хоть один MTA заточенный на удержание >1k клиентов одновремено?Exim, CommuniGatePro
Хех, было бы только памяти достаточно. :) Гигабайт скажем. :)
>Хех, было бы только памяти достаточно. :) Гигабайт скажем. :)
Опять врете, память для MTA не критична
>> Или вы знаете хоть один MTA заточенный на удержание >1k клиентов одновремено?
>
>Exim, CommuniGatePro
Врете
>>Исключительно безвредно и где-то даже эффективно, сам проверял-с
>pre greeting delay эффективен только при маленьких объемах почты, для больших сайтов
>это DOS устроенная самому себе - во время пиков спамерской активности
>мы мгновенно упремся в лимит одновременных сессий.Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сессий?
>Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сессий?
Поясняю - Никак.
Протираем глаза и читаем "pre-greeting" с "greylisting" это не имеет ничего общего.
>>Поясните пожалуйста, как связан greylisting и количество одновременных SMTP-сессий?
>Поясняю - Никак.
>Протираем глаза и читаем "pre-greeting" с "greylisting" это не имеет ничего общего.
>Сори. Осмотрелся.
1) То что автор пионер, видно по приводимым конфигам.
2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не пробъется и стало быть никто о проблемах не скажет. В приличном месте таке не катит.
Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP, на каждом их которых 10 имен. Но автор об этом не слышал.
Отбой по проверке существования отправителя не катит, ибо например Яху тебя за такой номер в момент заблокирует, и все -- вешайся. Но автор об этом тоже не знает...В общем обсуждать нечего -- очередное творение уровня админа конторы из 10 человек.
--
ZULU-UANIC,
Почтовый поток ~200 000 принятых писем в сутки, ~80 000 почтовых пользователей, ~10 отбитых писем в секунду в штатном режиме.
>1) То что автор пионер, видно по приводимым конфигам.
>2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не
>пробъется и стало быть никто о проблемах не скажет. В приличном
>месте таке не катит.
Ну может не отбой, а Service Unevailable.
>Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP,
>на каждом их которых 10 имен. Но автор об этом не
>слышал.
Позвольте поинтересоваться, а зачем на одном ИП 10 имен?>Отбой по проверке существования отправителя не катит, ибо например Яху тебя за
>такой номер в момент заблокирует, и все -- вешайся. Но автор
>об этом тоже не знает...
А может как раз Яху и не прав.>
>В общем обсуждать нечего -- очередное творение уровня админа конторы из 10
>человек.
>
>--
>ZULU-UANIC,
>Почтовый поток ~200 000 принятых писем в сутки, ~80 000 почтовых
>пользователей, ~10 отбитых писем в секунду в штатном режиме.
>1) То что автор пионер, видно по приводимым конфигам.
>2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не
>пробъется и стало быть никто о проблемах не скажет. В приличном
>месте таке не катит.
>Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP,
>на каждом их которых 10 имен. Но автор об этом не
>слышал.
>Отбой по проверке существования отправителя не катит, ибо например Яху тебя за
>такой номер в момент заблокирует, и все -- вешайся. Но автор
>об этом тоже не знает...
>
>В общем обсуждать нечего -- очередное творение уровня админа конторы из 10
>человек.
>
>--
>ZULU-UANIC,
>Почтовый поток ~200 000 принятых писем в сутки, ~80 000 почтовых
>пользователей, ~10 отбитых писем в секунду в штатном режиме.
Ну уж тогда поделись с нами о великий и ужасный ZULU секретами своего необъятного мастерства.
>>1) То что автор пионер, видно по приводимым конфигам.
>>2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не
>>пробъется и стало быть никто о проблемах не скажет. В приличном
>>месте таке не катит.
>>Отбой по несовпадению PTR-A не катит, ибо есть хосты с 10 IP,
>>на каждом их которых 10 имен. Но автор об этом не
>>слышал.
>>Отбой по проверке существования отправителя не катит, ибо например Яху тебя за
>>такой номер в момент заблокирует, и все -- вешайся. Но автор
>>об этом тоже не знает...
>>
>>В общем обсуждать нечего -- очередное творение уровня админа конторы из 10
>>человек.
>>
>>--
>>ZULU-UANIC,
>>Почтовый поток ~200 000 принятых писем в сутки, ~80 000 почтовых
>>пользователей, ~10 отбитых писем в секунду в штатном режиме.
>
>
>Ну уж тогда поделись с нами о великий и ужасный ZULU секретами
>своего необъятного мастерства.Парень... Возможно это ты автор и я тебя обидел выше -- тогда прости. Но подумай о том, что я написал выше. Не катят советы из статьи для применения в широких масштабах. Пользователи съедят.
>>>2) Отбой на этапе соединения -- некошерно, ибо на postmaster@ никто не
>>>пробъется и стало быть никто о проблемах не скажет. В приличном
>>>месте таке не катит.Следуя этой логике надо признать, что структура sendmail.cf разработана пионерами. Ведь если хост забанен в access.db, то на postmaster ему никакими судьбами не пробиться. И с DNSBL тоже самое, проверка происходит в Basic_check_relay на этапе соединения, т.е. еще до того как известен получатель.
>Следуя этой логике надо признать, что структура sendmail.cf разработана пионерами. Ведь если
>хост забанен в access.db, то на postmaster ему никакими судьбами не
>пробиться. И с DNSBL тоже самое, проверка происходит в Basic_check_relay на
>этапе соединения, т.е. еще до того как известен получатель.Man sendmail.mc /FEATURE(`delay_checks').
Существуют капитальные и систематизированные разработки в этой области от Виктора Устугова.Все, кто с пеной у рта кричат против вряд ли видели их в глаза. Очень небольшая их часть была включена в один из дистрибутивов линукс.
Степень проверки каждого параметра и различные исключения там прописываются в настройках.
Поскольку автор не склонен светить их в инете - ссылку не привожу.
Так и нахрена он такой умный нужен, если не хочет показывать свое творение? Жаба душит? И нахрена вы тут рекламируете то, что показыать не стремитесь?Я бы с удовольствием почитал умного человека, который может дать действительно полезный совет по больбе со спамом, а не пионЭров коих нынче на опеннете развелось как собак нерезаных.
>Так и нахрена он такой умный нужен, если не хочет показывать свое
>творение? Жаба душит? И нахрена вы тут рекламируете то, что показыать
>не стремитесь?Вот то, что сделано публично:
http://rpm.pbone.net/index.php3/stat/4/idpl/1799678/com/send...
См. /usr/share/sendmail-cf/README.corvax.rus
>Я бы с удовольствием почитал умного человека, который может дать действительно полезный
>совет по больбе со спамом, а не пионЭров коих нынче на
>опеннете развелось как собак нерезаных.Все когда то были "пионЭрами". Вы - в том числе...
Есть ещё хак, где можно выставлять проверку реверс DNS поюзерно (хочу принимать спам / не хочу принимать спам :-) ):http://www.cs.niu.edu/~rickert/cf/hack/require_rdns.m4
Ну - и ещё кое что:
Я думаю, что наш форум читают не только праведные админы, но и програмеры спама, которым очень интересна наша дискуссия. А что касается фильтрации по HELO, то у меня примерно 90 проц. фильтруется по HELO моим-же доменом, моим IP, cablemodem и тд.
http://www.opennet.me/tips/info/813.shtml
попробовал такую схему
возник вопрос
возможно ли вначале анализировать access а потом уже проверять соответствие PTR А?
а то получается что access потом только просматривается
>Dmitry Zubov описал (http://dz.dn.ua/spam/antispam.html) достаточно жесткую схему фильтрации спама на почтовом сервере
>работающем под управлением sendmail (FreeBSD).
>
>
>Схема предусматривает блокировку хостов без обратной зоны или несовпадении "PTR" и
>"A" записей, подключение проверки в DNSBL системах, обратную проверку существования адреса
>через milter-sender.Я у себя попробовал то что написано в статье буквально вчера, мне очень понравилось. Весь спам отрезало как и не было (раньше не менее 1000 писем в день), нормальные письма вроде доходят. Но похоже что-то и резануло сгоряча из того, что должно проходить (типа 3453.houston.hp.com) . В связи с этим вопрос, как реализовать то что пишет автор:
" в самом начале SLocal_check_relay вставить для них обход всех проверок."..??
Простите, если вопрос покажется для кого-то глупым, но документация у Sendmail очень тяжелая...
>[оверквотинг удален]
>
>Я у себя попробовал то что написано в статье буквально вчера, мне
>очень понравилось. Весь спам отрезало как и не было (раньше не
>менее 1000 писем в день), нормальные письма вроде доходят. Но похоже
> что-то и резануло сгоряча из того, что должно проходить
>(типа 3453.houston.hp.com) . В связи с этим вопрос, как реализовать то
>что пишет автор:
>" в самом начале SLocal_check_relay вставить для них обход всех проверок."..??
>Простите, если вопрос покажется для кого-то глупым, но документация у Sendmail очень
>тяжелая...SLocal_check_relay
R$* $: < $&{client_addr} >
R<IP клиента> $@OK
SLocal_check_relay
R$* $: < $&{client_addr} >
R<IP клиента> $@OK
>SLocal_check_relay
>R$* $: < $&{client_addr} >
>R<IP клиента> $@OKАдрес клиента вписывать вместо "<IP клиента>" и все ? А "{client_addr}" так и оставялем?
Именно так.