On Wed, Feb 19, 2003 at 06:49:23PM +0200, vladimir.sharun@ukr.net wrote:
Paul Arakelyan wrote:
Кстати - интересно просто - сколько писем в сутки проезжает в ukr.net (десятки тысяч/сотни/миллионы?). При большой куче
сотни Уже можно пытаться играть в статистику. "Спам - это закон больших чисел" (c) мой. Шоправда, какие-такие числа у нас... И чё тут эти спамеры забыли...
можно играть в статистические закономерности. Только мощи на это надо немало. Но yahoo.com в такое "играет" - причём успешно.
Вот интересно как... Ну из того чего видно было "с другой стороны" ;) - "velocity check": Берём и в несколько десятков smtp сеесий отсылаем одно и то же письмо, в каждой сессии каждые N писем отсылаем на "контрольные адреса". Первые N (число практиески вполне конкретное) писем попадают "куда надо", далее - "introducing junk mail folder!". То есть - не 100% фильтрация, но против реального "industrial grade" спама (такого тут нет, правда...) процент практиески 100%. Но в yahoo также есть немерянные white lists. Это то, его у наших ISP практически нет (а ведь было кому-то "весело", прийти на работу и увидеть то он от своих клиентов почту не принимает из-за relays.osirusoft).
Вопрос к аудитории: что потенциально можно сделать против этого дела ? Каким образом можно закрываться/фильтроваться ? Из идей - как-нибудь "более осторожно" относиться к хостам с бэк-резолвом содержащим кучу цифр. Далее из идей есть что-то типа тыкания сабжей и длин писем в базу - эдакая эвристика для бедных. Причём длины считать неточно.
Что понимается под "более осторожно" ? Дефер им ставить или сразу лесом/полем посылать ? BTW: идея дохлая изначально, это я еще Нет - "посылать" у нас конечно любят, но за что ж так? Хотя сделать defer, внести в базу "позволим этим в следующий раз", и таки позволить. Хотя если решить, что ukr.net==украинский hotmail.com, то можно получить специально под такое mailer...
пару лет назад проходил. Нет - если это чего-то с эвристикой - то добавлять весовой коэфициент/ тщательнее проверять на предмет спам/не спам. Ибо та же база - не резиновая. Поэтому добавлять туда вагон всего - наверно не стоит. То есть - наличие более чем N цифр/слов ppp/dsl/comcast/bellsouth - это триггер для внесения в базу.
А вот по HELO фильтровать (когда в HELO и DNS написано разное) - эт садизм (кроме "фирменных" HELO - их по идее для того и делали (ну постёбаться мож ещё), хотя может я неправ).
Ничего наглого нет. Когда моему mx-1.ukr.net говорят HELO mx-1.ukr.net я потом на RCPT To: так и отвечаю: 550 Wrong HELO/EHLO given. Это понятно. В моём случае было "HELO public" - и потом две недели неожиданного гемороя ;) с одним отдельно взятым юзером.
Главное - почему не сказать ясно "5xx мне ваш хело не нравится - идите отдохните"?
Так и есть. От 3 до 12к RCPT в сутки отбивается по фэйканым хэло. Это я к тому, что тот раз юзеру пришлось куда-то в ваш саппорт писать и выяснять "то собственно не так" - ибо из отлупов это было непонятно.
PS: а где солюшн или дополнительные вопросы ? К чему вообще был твой риплай ? Анализ сабжектов и длин говоришь ? А что, если subject & message length - пожалуй единственное, что можно быстро и ненапряжно достать из письма и ненапряжно хранить - ну ещё количество rcpt to сказанное при посылке этого письма(но это надо наверно точить MTA). При этом "не персонализирующие" спамилки сразу летят лесом. mail lists тоже могут туда улететь, правда :).
посылающий хост - это smtp-out12.k00l-p4ov1der.net и его подставили Да - возможно. Для "подставить с попаданием в spamcop" вообще много не надо. Особенно, если творчески подойти.
таким образом (на 25-м порту mail-out'ы не слушают - это и так ясно) ? Каким - таким? Идея в том, что есть база в которую о каждом письме вносим хост/тема/размер тела. Я бы сделал несколько(порядок опустим ;)) таблиц - e.g. письма размером 100-110 байт в одну таблицу/111-120 - в следующую &so on. (Тут я хочу сказать, то спец по БД из меня шо пуля из пластилину - меня этому не учили - посему я мало о чём кроме disk i/o задумываюсь). В таблице в строке держим subject, size (точный), количество совпадающих по subject&size, ip, время получения, количество rcpt в envelope. Записи должны expire через разумный промежуток времени. таким образом, если набирается N messages одинакового размера (или "почти одинакового" размера и с одинаковым subject) - делаем defer. С сабжами - аналогично. Поскольку у нас есть expire - "рано или поздно" норамльное мыло дойдёт. Кроме того, можно пробовать сделать закономерности на времени прибытия/отправки письма. Я не знаю о существовании spamware, умеющего разумно на такое реагировать (на defered). В итоге "нормальная" пота дойдёт. На мелком провайдере такое реализовывать наверно тяжеловато будет, но на крупном с кучей мыла - статистиеские методы могут себя показать, даже без "супер-наворотов" с неёткой логикой &co.
Спамить с помощью sendmail&co... Ну - наверно можно. Но "спотривных достижений" не получится. Таким образом - твои юзера получат какое-то колиество спама. Но меньшее. Либо его посылку "растянут" во времени. Теория красивая - вот только что будет с ней в праздничные дни - при таком раскладе "С новым годом!" к концу года мож дойдёт, ежели чего не подкрутят ;)... -- 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