приветствую скатились мы с Севолодом таки в личку. но все те две сотни писем, которыми мы обменялись вряд ли были бы тут всем интересны.
теперь о результатах >>> баги сабмитит в основном один пользователь, плюс несколько анонимусов, >>> т. е. пока rspamd скорее всего мало кем используется >> >> Увы, да - rspamd получился довольно сложным в развертывании, что >> зачастую отталкивает пользователей. > > на самом деле из портов FreeBSD ставится почти без проблем. правда порт > нормальный в официальном дереве появился только второго февраля. до > этого приходилось свой делать из тех обломков, что есть в рипозитарии > исходников. худо-бедно, но развернуть можно было. при установке rspamd из порта FreeBSD настройки дефолтового конфига согласованы с дефолтовыми настройками стартового скрипта. в стартовый скрипт добавлена переменная rspamd_flags для указания доп. параметров демона в /etc/rc.conf так что из коробки rspamd уже вполне юзабелен. нужно только обучить статистический фильтр. >>> уровень false positives и false negatives выше, чем у SpamAssassin, >>> правда ситуация немного выравнивается после дообучения местного Bayes >>> фильтра. >> >> Думаю, что статистика SA, использующая униграммы (то есть, одиночные >> слова) намного хуже, чем статистика rspamd, которая использует алгоритм >> OSB на окне из 5-ти слов (то есть, анализируются не только слова, но и >> их сочетания). > > в данном случае я совсем не сравнивал статистику статистических > фильтров. в SA реализация Bayes мне нравится меньше всего. как и ожидалось, эффективность статистического фильтра выше, чем у Bayes фильтра SpamAssassin. больше напоминает работу DSPAM и Mailreaver из состава CRM114. впечатления чисто субъективные, специальных сравнительных тестов я не проводил. >>> свои правила писать не то чтобы сложнее, скорее неудобней. само правило >>> лежит в одном месте, его подключение и вес в другом, проверка >>> корректности синтаксиса считает синтаксис некорректным, если >>> правило описано, а вес не указан. и если приходится использовать >>> несколько метрик, при этом в тестовых целях нужно одну закомментировать, >>> то нужно в других файлах закомментировать и все правила, которые >>> используются только в этой метрике. >> >> На самом деле такой подход появился в результате следования логике >> разбиения правил в SA. Кроме того, была потребность повесить на >> некоторое правило функцию lua (например, правило EMPTY_IMAGE в примере >> конфигурации). > > в SA свои правила можно оформлять, не разнося описания правил и > соответствующие баллы в разные файлы. поэтому если мне нужно что-то > отключить, я могу или файл просто убрать из соответствующего каталога, > или закомментировать несколько подряд идущих строк. благодаря возможности описывать привязку правил к метрикам прямо в lua теперь можно правила полностью оформлять в отдельных файлах, не трогая rspamd.xml. также можно в lua переопределять описание и вес правил, описанных в rspamd.xml. > в RSPAMD для отключения метрики мне нужно кроме правки > /usr/local/etc/rspamd.xml еще найти все описания правил и > закомментировать их. > > спасет только генерация и rspamd.xml и инклудов для > /usr/local/etc/rspamd/lua/rspamd.lua из предопределенных блоков. с > помощью чего-нибудь типа m4. поэтому для меня это менее критично. я не нашел, как в lua получить список файлов по маске. можно было бы реализовать подключение правил из всех файлов из определенного каталога. пока же в файл /usr/local/etc/rspamd/lua/rspamd.lua опционально включается содержимое файла /usr/local/etc/rspamd/lua/rspamd.local.lua а уже в файл /usr/local/etc/rspamd/lua/rspamd.local.lua можно включать свои правила и другие файлы с правилами. >>> для правил нет строки описания, как в SpamAssassin, т. е. в ответе >>> демона фигурируют лишь названия правил, без весов и описания. как в этом >>> отношении ведет себя rspamd работая по протоколу SPAMC, я не проверял, >>> т. к. работа по протоколу SPAMC подразумевает, что контент сканер сам >>> получает информацию об адресе клиента, HELO, адресе отправителя и адресе >>> получателя из заголовков письма. а в случае использования протокола >>> RSPAMC эти данные передаются демону в явном виде. >> >> Вообще, добавить описания к правилам - хорошая, годная, а главное - >> легко реализуемая идея, например, сделав в описании правил атрибут >> description: >> <symbol weight="1.0" description="Some symbol">SYMBOL</symbol> > > вполне приемлемый вариант. позволит для разных символов в разных > метриках делать отличающиеся описания. не знаю, пригодится ли это, но > тем не менее... описания правил можно указывать или в rspamd.xml или в файлах lua в /usr/local/etc/rspamd/lua/ >>> синтаксис регексповых правил отдаленно напоминает используемый в >>> SpamAssassin, вплоть до того, что можно написать конвертор. >>> >>> в регекспах не работают конструкции \1, \2 и т. д. >>> моих знаний программирования на C не хватило, чтобы понять, виноват >>> rspamd или pcre. >> >> Просто для ускорения работы отключены capture group. Опять же можно >> добавить крыжик в конфигурацию, чтобы их можно было включать. > > _очень_ нужно. у меня для SA достаточно много правил строится не только > на поиске повторений фрагментов строк в полях, но и на поиск повторений > в комбинациях полей. использование capture group включено > для SA мне пришлось писать патч для проверки комбинаций полей заголовков. > надеюсь, что для RSPAMD писать самому не придется, раз автор на связи ;-) > > т. е. интересует что-то типа такого: > > local MAILMAN_MSGID = > 'From,Message-ID=/<([^\\@]+\\@[^>]+)>,<mailman\\.\\d+\\.\\d+\\.\\d+\\.\\1>$/' > > т. е. интересует проверка наличия адреса из header From внутри header > Message-ID. > > запятая в качестве разделителя имен полей заголовков для примера > приведена (в SA я использую "|"), а значения полей лучше и не запятой > разделять. запятая опять же для примера приведена. > > конечно, можно писать плагины на LUA для каждого такого случая. но тогда > количество плагинов может быстро увеличиться до неразумого количества. для проверки комбинаций полей заголовков можно использовать pcre в функциях на lua. синтаксис получается более громоздким, чем при проверке одного поля простым регекспом. но т. к. в непатченном SpamAssassin'е такого функционала вообще нет, то особым недостатком это не является. также в lua фукциях можно использовать родной для lua поиск по pattern'ам. он не такой гибкий, как поиск с помощью перловых регекспов, но для не особо сложных случаев вполне приемлем. и как и в случае использования функций pcre, с помощью pattern'ов можно проверять комбинации полей заголовков. в функциях lua также можно использовать функцию rspamd_regexp.match. годится для проверки регекспом одного поля (является полным аналогом простых правил rspamd). преимущества использования rspamd_regexp.match в кешировании выражений и результатов сравнения. фактически данный механизм можно применять тогда, когда правило зависит от нескольких критериев, у каждого есть свой вес, правило сратывает, если суммарный вес критериев достигнет определенного уровня. >>> плагины написаны на LUA. в принципе, синтаксис получается более >>> компактным, чем в плагинах на Perl для SpamAssassin. >>> >>> в плагине check_forged_headers есть ошибки, из-за чего правило >>> FORGED_RECIPIENTS ложно срабатывает время от времени. >> >> Был бы признателен за подробности: в каких случаях оно ложно срабатывает? > > проблемное письмо сейчас возможно и не найду. > > если в двух словах, то функция string.find(mr, sr) не всегда срабатывала > при поиске адреса получателя из envelope RCPT в строке header To/Cc. > было это из-за разного регистра символов или из-за симвлов пунктуации, > присутствующих в адресе, сейчас уже не скажу. недоработка в этом плагине исправлена, адреса сравниваются корректно >>> я наткнулся уже на пару писем, при обработке которых возникаются >>> проблемы при описании более одной метрики в rspamd.xml. >>> демон пишет в сокет ответ с данными по первой метрике и начинает >>> потреблять около 90% процессорного времени. >>> тестирование проводилось в виртуалке, на физической машине может меньше >>> начнет отжирать, но от этого не легче. после этого приходилось демона >>> убивать по kill -9. >>> пока отложил проблему в сторону, т. к. вторая метрика была создана в >>> тестовых целях и для штатной работы пока вполне хватит одной метрики. >> >> Спасибо за репорт, я попробую создать такую конфигурацию. > > я завтра или послезавтра выложу на mta.org.ua и пример конфигурации и > проблемные письма. вышеописанные проблемы также исправлены также добавлена возможность сравнивать поля заголовков с регкспами с учетом регистра символов в имени полей, т. е. добавлена возможность отличить Content-Transfer-Encoding: 8bit от Content-transfer-encoding: 8bit также добавлена фукнция get_header_strong для получения в функциях lua значения поля заголовка с учетом регистра символов. для исключения из простых правил можно использовать функцию string.format (это и раньше было). для исключения из правил, вычисляемых с помощью фукнций lua, можно исключение делать или внутри функции (что весьма неудобно), либо использовать вместо локальных функций глобальные, а уже их использовать в качестве параметров для string.format для исключения из правил, вычисляемых с помощью плагинов, можно использовать композитные символы. теперь их можно описывать не только в rspamd.xml, но и в коде lua. также изменена логика использования правил, входящих в композитные правила. если раньше при срабатывании композитного правила игнорировались все правила, из которых состоял композит, то сейчас можно указать исключения. т. е. часть правил, из которых состоит композит, можно оставить в наборе сработавших правил, со своим описанием и весом. также есть механизм проверки разделителей между именами полей заголовков и их значениями. сейчас уже добавлены правила для поиска пустых разделителей и разделителей в виде символов табуляций. в общем и целом сейчас функционал rspamd доведен до уровня, полностью пригодного для портирования любого набора правил SpamAssassin. проблемы могут возникнуть только при портировании сложных плагинов. еще есть неудобства при сравнении с регекспами нескольких экземпляров поля. т. е. если в письме есть два поля Cc, то сравнить комбинацию этих двух полей одним регекспом штатными средствами нельзя. придется писать функцию на lua, получать значение всех полей Cc, сцеплять в строковую переменную и уже ее значение сравнивать с регекспом. правил мы тоже немного добавили. так что вполне можно ставить rspamd и пробовать. -- Best wishes Victor Ustugov mailto:vic...@corvax.kiev.ua public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc ICQ UIN: 77186900, 371808614 nic-handle: CRV-UANIC _______________________________________________ Exim-users mailing list Exim-users@mailground.net http://mailground.net/mailman/listinfo/exim-users
