On Tue, Feb 17, 2004 at 12:30:55PM -0800, Dmitry Kohmanyuk Дмитрий Кохманюк wrote:
On Tue, Feb 17, 2004 at 08:49:31PM +0200, Paul Arakelyan wrote:
В связи с успешным запуском в открытый космос шедевра програмизма, обозванного smtpshield, и даже вполне выполняющего часть поставленных задач (типа работы с blacklists, издевательств над злобными буратинами и прозрачного внедрения в существующую инфраструктуру, в коей можно голову сломать) тут "вдруг" возникли вопросы:
все эти вопросы решаются созданием smtpshield.cfg c прописаным в нем большим списком переменных ;-) Там он пока только для bindaddr:port targetaddr:port придуман :) а тулза крутая - выкладывай на sourceforge - тут тебе сразу и расскажут, как она должна работать ;) Ничего крутого - tcp proxy, разрослось до 25KB .c, из которых 5-10 можно выбросить :). Уже вот почту на диске сохранять научилось в файлы с уникальными именами (тут я обломался применить "конверсионные технологии" - генератор уникальных хэшей, проверенный генерацией ...КУЧИ оных, и решил что можно и crypt побаловаться) :). Особенно если исходники куда-нить выкладывать.
- при приёме data - эта самая DATA принимается read() кусочками типа "somebuffersize/blacklistscore" и sleep(something*blacklistscore) в промежутках. Шот-то начал я замечать что иногда отваливаются ихние DSL-ы - они вообще, конечно, и так не шибко скоростные и "от природы требуют прецизионной настройки спамвари", но всё равно подозрительно - мож я что не так сделал? А если я read() делаю "нечётными" кусочками - от этого ничего не может быть? (FreeBSD-5.2-S, gcc-3.3.3)
нечетными это как? Ну - это не делящимися на 2 (типа (int)8192/3) Вот сегодня глюк нашёл в компиляторе:
Из плохих качеств - чё-то -static приводит к полной нежизнеспособности, (libfiredns с threads + наверно что-то я не так делаю), и при "слегка разных" 5.2 (ну - месяц разницы) на "старой" бинарник с "новой" не работал. Зато с возможными глюками потоков я наверно не столкнусь - приложение получилось многопроцессным с потоками что-то только child processes делают. printf("config - port: %s:%d -> %s:%d %s\n", inet_ntoa(someaddr1), ntohs( someinp ), inet_ntoa(someaddr2), ntohs( someoutp )); Результаты inet_ntoa совпадают, при том что адреса - разные. При расписывании на два printf - всё нормально.
- Ото гляжу я на такое (stage blacklistscore ip...) и думаю, как по-умному вычислять этот самый score, и при каком посылать сразу.
перемножать вероятности, если лень; а так - можно как bayes. (ты же гипотезы строишь? :) Ну - я пока целыми числами балуюсь, и сильно большими их делать неохота. И пока что только для задержек всяких. Также никак не обрабатываются результаты "комплексных" rbl, пока что задача сваять сохранение "подозрительных" писем, отсылку уведомления и механизм "выплёвывания" к пользователю в ящик.
подбросит? Критерием для расстановки весов служит "адекватность оценки рассылки почты с заданного IP" - то есть "оттуда должны что-то нехорошее посылать". В конце расчёта нужно получить некоторое целое число, которое используется при расчёте задержек между ответами сервера ну и для "послать неглядя" его тоже использовать. Нда - трафика проверка по rbl жрёт тоже вполне.
ну типа - одна неудача по rbl = 0.9. перемножаешь их и потом результат переводишь в число - вероятность: (1 - p) * 10 (0.9 => 1, 0.8 => 2, 0.1 => 9) Тут другое немного не нравится - "природа" используемых rbl - то есть, одни описывают "вообще левые" сети - то есть места, откуда врядли прийдёт вообще какая-нибудь почта, другие - dialup/dsl, третьи - собственно "спам-ин-прогресс", при этом функциональность их может дублироваться, а результаты и совпадать, и не совпадать - то есть, для некоторых надо какой-нить OR делать...
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message