Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Andrey N. Oktyabrski 

On 02/13/11 02:46, Victor Ustugov wrote:

p. s. нас сейчас погонят отсюда за оффтопик (и будут правы).
так что нужно бы перебираться или в личку или в другой лист.

Не надо в личку, мне тоже интересно :-)

___
Exim-users mailing list
Exim-users@mailground.net
http://mailground.net/mailman/listinfo/exim-users

Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Victor Ustugov 
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

вполне приемлемый вариант. позволит для разных символов в разных
метриках делать отличающиеся описания. не знаю, пригодится ли это, но
тем не менее...

>> синтаксис регексповых правил отдаленно напоминает используемый в
>> SpamAssassin, вплоть до того, что можно написать конвертор.
>>
>> в регекспах не работают конструкции \1, \2 и т. д.
>> моих знаний п

Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Vsevolod Stakhov 

On 12.02.2011 22:43, Victor Ustugov wrote:

t...@irk.ru wrote:

а есть что-нибудь некоммерческое к чему exim может ходить через
spamd_address?


http://bitbucket.org/vstakhov/rspamd/

разработчик из России, работает в Рамблере


Так как я также подписан на эту рассылку, то прокомментирую некоторые 
моменты.



баги сабмитит в основном один пользователь, плюс несколько анонимусов,
т. е. пока rspamd скорее всего мало кем используется


Увы, да - rspamd получился довольно сложным в развертывании, что 
зачастую отталкивает пользователей.



что касается интеграции с exim, то есть как минимум три способа:
1. работа по протоколу SpamAssassin'а RSPAMC (не пробовал)


Протокол SpamAssassin'а - это все-таки spamc, а не rspamc.


2. работа по протоколу RSPAMC через одну из двух предлагаемых функций
local_scan (пробовал, работает, но local_scan для меня неприемлем)
3. на основе штатных local_scan функций легко можно написать свою dlfunc
(в том числе благодаря простоте протокола RSPAMC, см. выше)


Кроме этого, начиная с 0.3.5 можно использовать библиотеку 
librspamdclient. Или же приложенный патч.



уровень false positives и false negatives выше, чем у SpamAssassin,
правда ситуация немного выравнивается после дообучения местного Bayes
фильтра.


Думаю, что статистика SA, использующая униграммы (то есть, одиночные 
слова) намного хуже, чем статистика rspamd, которая использует алгоритм 
OSB на окне из 5-ти слов (то есть, анализируются не только слова, но и 
их сочетания). Похожие алгоритмы используются также, например, в dspam 
или в crm114.



свои правила писать не то чтобы сложнее, скорее неудобней. само правило
лежит в одном месте, его подключение и вес в другом, проверка
корректности синтаксиса считает синтаксис некорректным, если
правило описано, а вес не указан. и если приходится использовать
несколько метрик, при этом в тестовых целях нужно одну закомментировать,
то нужно в других файлах закомментировать и все правила, которые
используются только в этой метрике.


На самом деле такой подход появился в результате следования логике 
разбиения правил в SA. Кроме того, была потребность повесить на 
некоторое правило функцию lua (например, правило EMPTY_IMAGE в примере 
конфигурации).



для правил нет строки описания, как в SpamAssassin, т. е. в ответе
демона фигурируют лишь названия правил, без весов и описания. как в этом
отношении ведет себя rspamd работая по протоколу SPAMC, я не проверял,
т. к. работа по протоколу SPAMC подразумевает, что контент сканер сам
получает информацию об адресе клиента, HELO, адресе отправителя и адресе
получателя из заголовков письма. а в случае использования протокола
RSPAMC эти данные передаются демону в явном виде.


Вообще, добавить описания к правилам - хорошая, годная, а главное - 
легко реализуемая идея, например, сделав в описании правил атрибут 
description:

SYMBOL


синтаксис регексповых правил отдаленно напоминает используемый в
SpamAssassin, вплоть до того, что можно написать конвертор.

в регекспах не работают конструкции \1, \2 и т. д.
моих знаний программирования на C не хватило, чтобы понять, виноват
rspamd или pcre.


Просто для ускорения работы отключены capture group. Опять же можно 
добавить крыжик в конфигурацию, чтобы их можно было включать.



плагины написаны на LUA. в принципе, синтаксис получается более
компактным, чем в плагинах на Perl для SpamAssassin.

в плагине check_forged_headers есть ошибки, из-за чего правило
FORGED_RECIPIENTS ложно срабатывает время от времени.


Был бы признателен за подробности: в каких случаях оно ложно срабатывает?


я наткнулся уже на пару писем, при обработке которых возникаются
проблемы при описании более одной метрики в rspamd.xml.
демон пишет в сокет ответ с данными по первой метрике и начинает
потреблять около 90% процессорного времени.
тестирование проводилось в виртуалке, на физической машине может меньше
начнет отжирать, но от этого не легче. после этого приходилось демона
убивать по kill -9.
пока отложил проблему в сторону, т. к. вторая метрика была создана в
тестовых целях и для штатной работы пока вполне хватит одной метрики.


Спасибо за репорт, я попробую создать такую конфигурацию.

Ну и в целом, я всегда готов рассмотреть пожелания по улучшению rspamd 
или же по устранению багов, в нем обнаруженных :)


--
Vsevolod Stakhov
--- src/spam.c.orig 2011-01-20 19:29:51.179597017 +0300
+++ src/spam.c  2011-01-20 19:40:42.818516872 +0300
@@ -21,6 +21,9 @@
 int spam_ok = 0;
 int spam_rc = 0;
 
+/* push formatted line into vector */
+static int push_line(struct iovec *iov, int i, const char *fmt, ...);
+
 int spam(uschar **listptr) {
   int sep = 0;
   uschar *list = *listptr;
@@ -211,14 +214,26 @@
   }
 
   /* now we are connected to spamd on spamd_sock */
-  (void)string_format(spamd_buffer,
-   sizeof(spamd_buffer),
-   "REPORT SPAMC/1.2\r\nUser: %s\r\nContent-length: %ld\r\n\r\n",
-   user_name,
-   mbox_size);
+  int r, request_p = 0;
+  const char *helo;
+  struct iovec request

Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Victor Ustugov 
Andrey N. Oktyabrski wrote:

>> интерфейс демона достаточно просто, нужно просто залить в сокет одним
>> блоком заголовок со служебной информацией (тип запроса, размер письма,
>> queue id, адрес отправителя, количество адресов получателей, адреса
>> получателей, HELO и IP клиента) и текст письма. ответ также приходит
>> одним блоком. т. е. проверить письмо можно вообще скриптом, заливающим
>> эти данные в сокет через nc.
>>
>> что касается интеграции с exim, то есть как минимум три способа:
>> 1. работа по протоколу SpamAssassin'а RSPAMC (не пробовал)
>> 2. работа по протоколу RSPAMC через одну из двух предлагаемых функций
>> local_scan (пробовал, работает, но local_scan для меня неприемлем)
>> 3. на основе штатных local_scan функций легко можно написать свою dlfunc
>> (в том числе благодаря простоте протокола RSPAMC, см. выше)

> readsocket не пробовал?

нет, не пробовал

мне нужно вливать демону все заголовки письма по состоянию на начало
работы acl_smtp_data, за исключением удаленных с помощью remove_header,
также влить заголовки, добавленные в acl_smtp_data с помощью add_header,
учитывая позицию, куда добавляется заголовок. ну и потом влить тело письма.

я не уверен, что соберу эти данные внутри конфига, чтобы влить демону
через readsocket. поэтому я просто dlfunc написал. лежит в той же куче,
где и остальные.

на самом деле тут вопрос не в том, как отдать данные демону и получить
их обратно. вопрос в том, чтобы поднять эффективность фильтрации rspamd
до нынешней эффективности фильтрации spamd, сохранив преимущество в
производительности.

-- 
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

Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Роман Николенко 

А если посмотреть не в сторону  spamd_address, а в сторону смтп прокси?
Я у себя использую http://www.magicvillage.de/~Fritz_Borgstedt/assp/ 
 настройка 
полностью простая через веб.
Будут вопросы без проблем обращайтесь. (обслуживает 11 доменов, трафик 
более 30к полезных писем в месяц )



12.02.2011 21:43, Victor Ustugov пишет:

t...@irk.ru wrote:

а есть что-нибудь некоммерческое к чему exim может ходить через
spamd_address?

http://bitbucket.org/vstakhov/rspamd/

разработчик из России, работает в Рамблере

баги сабмитит в основном один пользователь, плюс несколько анонимусов,
т. е. пока rspamd скорее всего мало кем используется

в портах rspamd появился совсем недавно, там версия 0.3.5. порт из
архива исходников использовать нельзя - там какие-то старые обломки,
смесь 0.2.9 и 0.3.0

интерфейс демона достаточно просто, нужно просто залить в сокет одним
блоком заголовок со служебной информацией (тип запроса, размер письма,
queue id, адрес отправителя, количество адресов получателей, адреса
получателей, HELO и IP клиента) и текст письма. ответ также приходит
одним блоком. т. е. проверить письмо можно вообще скриптом, заливающим
эти данные в сокет через nc.

что касается интеграции с exim, то есть как минимум три способа:
1. работа по протоколу SpamAssassin'а RSPAMC (не пробовал)
2. работа по протоколу RSPAMC через одну из двух предлагаемых функций
local_scan (пробовал, работает, но local_scan для меня неприемлем)
3. на основе штатных local_scan функций легко можно написать свою dlfunc
(в том числе благодаря простоте протокола RSPAMC, см. выше)

работает rspamd быстрее, чем spamd, ресурсов требует меньше. ощущения
субъективные. сравнительные тесты не проводились, т. к. к SpamAssassin у
меня прикручено очень большое количество своих правил и несколько
плагинов. а у rspamd и штатный набор правил ощутимо меньше, чем у
SpamAssassin, да и своих правил я портировал на rspamd считанные единицы.

уровень false positives и false negatives выше, чем у SpamAssassin,
правда ситуация немного выравнивается после дообучения местного Bayes
фильтра.

свои правила писать не то чтобы сложнее, скорее неудобней. само правило
лежит в одном месте, его подключение и вес в другом, проверка
корректности синтаксиса считает синтаксис некорректным, если
правило описано, а вес не указан. и если приходится использовать
несколько метрик, при этом в тестовых целях нужно одну закомментировать,
то нужно в других файлах закомментировать и все правила, которые
используются только в этой метрике.

для правил нет строки описания, как в SpamAssassin, т. е. в ответе
демона фигурируют лишь названия правил, без весов и описания. как в этом
отношении ведет себя rspamd работая по протоколу SPAMC, я не проверял,
т. к. работа по протоколу SPAMC подразумевает, что контент сканер сам
получает информацию об адресе клиента, HELO, адресе отправителя и адресе
получателя из заголовков письма. а в случае использования протокола
RSPAMC эти данные передаются демону в явном виде.

синтаксис регексповых правил отдаленно напоминает используемый в
SpamAssassin, вплоть до того, что можно написать конвертор.

в регекспах не работают конструкции \1, \2 и т. д.
моих знаний программирования на C не хватило, чтобы понять, виноват
rspamd или pcre.

плагины написаны на LUA. в принципе, синтаксис получается более
компактным, чем в плагинах на Perl для SpamAssassin.

в плагине check_forged_headers есть ошибки, из-за чего правило
FORGED_RECIPIENTS ложно срабатывает время от времени.

я наткнулся уже на пару писем, при обработке которых возникаются
проблемы при описании более одной метрики в rspamd.xml.
демон пишет в сокет ответ с данными по первой метрике и начинает
потреблять около 90% процессорного времени.
тестирование проводилось в виртуалке, на физической машине может меньше
начнет отжирать, но от этого не легче. после этого приходилось демона
убивать по kill -9.
пока отложил проблему в сторону, т. к. вторая метрика была создана в
тестовых целях и для штатной работы пока вполне хватит одной метрики.





___
Exim-users mailing list
Exim-users@mailground.net
http://mailground.net/mailman/listinfo/exim-users

Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Andrey N. Oktyabrski 

On 02/12/11 22:43, Victor Ustugov wrote:

интерфейс демона достаточно просто, нужно просто залить в сокет одним
блоком заголовок со служебной информацией (тип запроса, размер письма,
queue id, адрес отправителя, количество адресов получателей, адреса
получателей, HELO и IP клиента) и текст письма. ответ также приходит
одним блоком. т. е. проверить письмо можно вообще скриптом, заливающим
эти данные в сокет через nc.

что касается интеграции с exim, то есть как минимум три способа:
1. работа по протоколу SpamAssassin'а RSPAMC (не пробовал)
2. работа по протоколу RSPAMC через одну из двух предлагаемых функций
local_scan (пробовал, работает, но local_scan для меня неприемлем)
3. на основе штатных local_scan функций легко можно написать свою dlfunc
(в том числе благодаря простоте протокола RSPAMC, см. выше)

readsocket не пробовал?

___
Exim-users mailing list
Exim-users@mailground.net
http://mailground.net/mailman/listinfo/exim-users

Re: [Exim-users] аналог spamassasin

2011-02-12 Пенетрантность Victor Ustugov 
t...@irk.ru wrote:
> а есть что-нибудь некоммерческое к чему exim может ходить через
> spamd_address?

http://bitbucket.org/vstakhov/rspamd/

разработчик из России, работает в Рамблере

баги сабмитит в основном один пользователь, плюс несколько анонимусов,
т. е. пока rspamd скорее всего мало кем используется

в портах rspamd появился совсем недавно, там версия 0.3.5. порт из
архива исходников использовать нельзя - там какие-то старые обломки,
смесь 0.2.9 и 0.3.0

интерфейс демона достаточно просто, нужно просто залить в сокет одним
блоком заголовок со служебной информацией (тип запроса, размер письма,
queue id, адрес отправителя, количество адресов получателей, адреса
получателей, HELO и IP клиента) и текст письма. ответ также приходит
одним блоком. т. е. проверить письмо можно вообще скриптом, заливающим
эти данные в сокет через nc.

что касается интеграции с exim, то есть как минимум три способа:
1. работа по протоколу SpamAssassin'а RSPAMC (не пробовал)
2. работа по протоколу RSPAMC через одну из двух предлагаемых функций
local_scan (пробовал, работает, но local_scan для меня неприемлем)
3. на основе штатных local_scan функций легко можно написать свою dlfunc
(в том числе благодаря простоте протокола RSPAMC, см. выше)

работает rspamd быстрее, чем spamd, ресурсов требует меньше. ощущения
субъективные. сравнительные тесты не проводились, т. к. к SpamAssassin у
меня прикручено очень большое количество своих правил и несколько
плагинов. а у rspamd и штатный набор правил ощутимо меньше, чем у
SpamAssassin, да и своих правил я портировал на rspamd считанные единицы.

уровень false positives и false negatives выше, чем у SpamAssassin,
правда ситуация немного выравнивается после дообучения местного Bayes
фильтра.

свои правила писать не то чтобы сложнее, скорее неудобней. само правило
лежит в одном месте, его подключение и вес в другом, проверка
корректности синтаксиса считает синтаксис некорректным, если
правило описано, а вес не указан. и если приходится использовать
несколько метрик, при этом в тестовых целях нужно одну закомментировать,
то нужно в других файлах закомментировать и все правила, которые
используются только в этой метрике.

для правил нет строки описания, как в SpamAssassin, т. е. в ответе
демона фигурируют лишь названия правил, без весов и описания. как в этом
отношении ведет себя rspamd работая по протоколу SPAMC, я не проверял,
т. к. работа по протоколу SPAMC подразумевает, что контент сканер сам
получает информацию об адресе клиента, HELO, адресе отправителя и адресе
получателя из заголовков письма. а в случае использования протокола
RSPAMC эти данные передаются демону в явном виде.

синтаксис регексповых правил отдаленно напоминает используемый в
SpamAssassin, вплоть до того, что можно написать конвертор.

в регекспах не работают конструкции \1, \2 и т. д.
моих знаний программирования на C не хватило, чтобы понять, виноват
rspamd или pcre.

плагины написаны на LUA. в принципе, синтаксис получается более
компактным, чем в плагинах на Perl для SpamAssassin.

в плагине check_forged_headers есть ошибки, из-за чего правило
FORGED_RECIPIENTS ложно срабатывает время от времени.

я наткнулся уже на пару писем, при обработке которых возникаются
проблемы при описании более одной метрики в rspamd.xml.
демон пишет в сокет ответ с данными по первой метрике и начинает
потреблять около 90% процессорного времени.
тестирование проводилось в виртуалке, на физической машине может меньше
начнет отжирать, но от этого не легче. после этого приходилось демона
убивать по kill -9.
пока отложил проблему в сторону, т. к. вторая метрика была создана в
тестовых целях и для штатной работы пока вполне хватит одной метрики.



-- 
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