Vsevolod Stakhov wrote: >>> а есть что-нибудь некоммерческое к чему exim может ходить через >>> spamd_address? >> >> http://bitbucket.org/vstakhov/rspamd/ >> >> разработчик из России, работает в Рамблере > > Так как я также подписан на эту рассылку, то прокомментирую некоторые > моменты.
отлично. возможно тогда время, потраченное мной в последние несколько вечеров, не продет даром, раз разработчик откликнулся быстро. >> баги сабмитит в основном один пользователь, плюс несколько анонимусов, >> т. е. пока rspamd скорее всего мало кем используется > > Увы, да - rspamd получился довольно сложным в развертывании, что > зачастую отталкивает пользователей. на самом деле из портов FreeBSD ставится почти без проблем. правда порт нормальный в официальном дереве появился только второго февраля. до этого приходилось свой делать из тех обломков, что есть в рипозитарии исходников. худо-бедно, но развернуть можно было. >> что касается интеграции с exim, то есть как минимум три способа: >> 1. работа по протоколу SpamAssassin'а RSPAMC (не пробовал) > > Протокол SpamAssassin'а - это все-таки spamc, а не rspamc. согласен. вписывал название протокола уже потом, в первоначальной формулировке было просто "по протоколу SpamAssassin'а" >> 2. работа по протоколу RSPAMC через одну из двух предлагаемых функций >> local_scan (пробовал, работает, но local_scan для меня неприемлем) >> 3. на основе штатных local_scan функций легко можно написать свою dlfunc >> (в том числе благодаря простоте протокола RSPAMC, см. выше) > > Кроме этого, начиная с 0.3.5 можно использовать библиотеку > librspamdclient. Или же приложенный патч. да в общем и целом протокол RSPAMC позволяет писать клиента на чем угодно на коленке достаточно быстро. хотя наличие библиотеки не помешает. >> уровень false positives и false negatives выше, чем у SpamAssassin, >> правда ситуация немного выравнивается после дообучения местного Bayes >> фильтра. > > Думаю, что статистика SA, использующая униграммы (то есть, одиночные > слова) намного хуже, чем статистика rspamd, которая использует алгоритм > OSB на окне из 5-ти слов (то есть, анализируются не только слова, но и > их сочетания). в данном случае я совсем не сравнивал статистику статистических фильтров. в SA реализация Bayes мне нравится меньше всего. > Похожие алгоритмы используются также, например, в dspam > или в crm114. они оба - чисто статистические фильтры. поэтому по сути не являются полноценными конкурентами ни для SA ни для RSPAMD. с CRM114 вообще отдельный разговор. демона нет. сканер написать на своем же языке. для испльзования libcrm114 нужно писать обертку такой сложности, что проще использовать готовый контент сканер. вот как раз RSPAMD таким и является. >> свои правила писать не то чтобы сложнее, скорее неудобней. само правило >> лежит в одном месте, его подключение и вес в другом, проверка >> корректности синтаксиса считает синтаксис некорректным, если >> правило описано, а вес не указан. и если приходится использовать >> несколько метрик, при этом в тестовых целях нужно одну закомментировать, >> то нужно в других файлах закомментировать и все правила, которые >> используются только в этой метрике. > > На самом деле такой подход появился в результате следования логике > разбиения правил в SA. Кроме того, была потребность повесить на > некоторое правило функцию lua (например, правило EMPTY_IMAGE в примере > конфигурации). в SA свои правила можно оформлять, не разнося описания правил и соответствующие баллы в разные файлы. поэтому если мне нужно что-то отключить, я могу или файл просто убрать из соответствующего каталога, или закомментировать несколько подряд идущих строк. в RSPAMD для отключения метрики мне нужно кроме правки /usr/local/etc/rspamd.xml еще найти все описания правил и закомментировать их. спасет только генерация и rspamd.xml и инклудов для /usr/local/etc/rspamd/lua/rspamd.lua из предопределенных блоков. с помощью чего-нибудь типа m4. поэтому для меня это менее критично. >> для правил нет строки описания, как в SpamAssassin, т. е. в ответе >> демона фигурируют лишь названия правил, без весов и описания. как в этом >> отношении ведет себя rspamd работая по протоколу SPAMC, я не проверял, >> т. к. работа по протоколу SPAMC подразумевает, что контент сканер сам >> получает информацию об адресе клиента, HELO, адресе отправителя и адресе >> получателя из заголовков письма. а в случае использования протокола >> RSPAMC эти данные передаются демону в явном виде. > > Вообще, добавить описания к правилам - хорошая, годная, а главное - > легко реализуемая идея, например, сделав в описании правил атрибут > description: > <symbol weight="1.0" description="Some symbol">SYMBOL</symbol> вполне приемлемый вариант. позволит для разных символов в разных метриках делать отличающиеся описания. не знаю, пригодится ли это, но тем не менее... >> синтаксис регексповых правил отдаленно напоминает используемый в >> SpamAssassin, вплоть до того, что можно написать конвертор. >> >> в регекспах не работают конструкции \1, \2 и т. д. >> моих знаний программирования на C не хватило, чтобы понять, виноват >> rspamd или pcre. > > Просто для ускорения работы отключены capture group. Опять же можно > добавить крыжик в конфигурацию, чтобы их можно было включать. _очень_ нужно. у меня для SA достаточно много правил строится не только на поиске повторений фрагментов строк в полях, но и на поиск повторений в комбинациях полей. для SA мне пришлось писать патч для проверки комбинаций полей заголовков. надеюсь, что для RSPAMD писать самому не придется, раз автор на связи ;-) т. е. интересует что-то типа такого: local MAILMAN_MSGID = 'From,Message-ID=/<([^\\@]+\\@[^>]+)>,<mailman\\.\\d+\\.\\d+\\.\\d+\\.\\1>$/' т. е. интересует проверка наличия адреса из header From внутри header Message-ID. запятая в качестве разделителя имен полей заголовков для примера приведена (в SA я использую "|"), а значения полей лучше и не запятой разделять. запятая опять же для примера приведена. конечно, можно писать плагины на LUA для каждого такого случая. но тогда количество плагинов может быстро увеличиться до неразумого количества. >> плагины написаны на LUA. в принципе, синтаксис получается более >> компактным, чем в плагинах на Perl для SpamAssassin. >> >> в плагине check_forged_headers есть ошибки, из-за чего правило >> FORGED_RECIPIENTS ложно срабатывает время от времени. > > Был бы признателен за подробности: в каких случаях оно ложно срабатывает? проблемное письмо сейчас возможно и не найду. если в двух словах, то функция string.find(mr, sr) не всегда срабатывала при поиске адреса получателя из envelope RCPT в строке header To/Cc. было это из-за разного регистра символов или из-за симвлов пунктуации, присутствующих в адресе, сейчас уже не скажу. временно я отбился заменой условия сравнения адресов на следующее: string.find(string.lower(mr), string.lower(sr), 1, true) я до RSPAMD с LUA не сталкивался. так что это первое, что в голову пришло. >> я наткнулся уже на пару писем, при обработке которых возникаются >> проблемы при описании более одной метрики в rspamd.xml. >> демон пишет в сокет ответ с данными по первой метрике и начинает >> потреблять около 90% процессорного времени. >> тестирование проводилось в виртуалке, на физической машине может меньше >> начнет отжирать, но от этого не легче. после этого приходилось демона >> убивать по kill -9. >> пока отложил проблему в сторону, т. к. вторая метрика была создана в >> тестовых целях и для штатной работы пока вполне хватит одной метрики. > > Спасибо за репорт, я попробую создать такую конфигурацию. я завтра или послезавтра выложу на mta.org.ua и пример конфигурации и проблемные письма. > Ну и в целом, я всегда готов рассмотреть пожелания по улучшению rspamd > или же по устранению багов, в нем обнаруженных :) это не может не радовать. тем более, что у меня есть еще ряд мыслей по RSPAMD. просто пока не хотелось бы их высказывать, т. к. возможно я просто не разобрался в конфигах и коде. документация касается в основном администрирования того, что можно получить из коробки. в ней мало что есть о том, как допилить систему под себя. необходимость на части серверов перейти со связки SpamAssassin+DSPAM на что-то другое назрела еще несколько лет назад. если удастся довести гибкость и функциональность RSPAMD до сравнимого уровня, будет хорошо. p. s. нас сейчас погонят отсюда за оффтопик (и будут правы). так что нужно бы перебираться или в личку или в другой лист. -- Best wishes Victor Ustugov mailto:[email protected] public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc ICQ UIN: 77186900, 371808614 nic-handle: CRV-UANIC _______________________________________________ Exim-users mailing list [email protected] http://mailground.net/mailman/listinfo/exim-users
