Vsevolod Stakhov wrote:
>> с CRM114 вообще отдельный разговор. демона нет. сканер написать на своем
>> же языке. для испльзования libcrm114 нужно писать обертку такой
>> сложности, что проще использовать готовый контент сканер. вот как раз
>> RSPAMD таким и является.
>
> Ну crm114 пишется математиком, оттого и такие странности :)
если оне ошибаюсь, автор CRM114 из Массачусетского технологического. с
другой стороны - Хазель профессор, но при этом его разработка вышла
далеко за рамки академической.
>> в SA свои правила можно оформлять, не разнося описания правил и
>> соответствующие баллы в разные файлы. поэтому если мне нужно что-то
>> отключить, я могу или файл просто убрать из соответствующего каталога,
>> или закомментировать несколько подряд идущих строк.
>>
>> в RSPAMD для отключения метрики мне нужно кроме правки
>> /usr/local/etc/rspamd.xml еще найти все описания правил и
>> закомментировать их.
>>
>
> Сейчас можно использовать dynamic rules:
> [
> {
> "rule": "file:///test/rP",
> "symbol": "R_TMP_1",
> "factor": 1.1,
> "networks": ["!192.168.1.0/24", "172.16.0.0/16"],
> "enabled": false
> }
> ]
это вариант. но на сколько я понимаю, для каждого символа придется
создавать отдельный файл. я предполагаю создание достаточно большого
количества правил. порядка нескольких сотен как минимум.
компромиссным на мой взгляд вариантом была бы возможность при проверке
корректности синтаксиса выводить предупреждения о том, что есть
описанные символы без упоминания их в метриках, и наоборот, что в
описании метрики есть символы, для которых не сделаны описания. ну и,
естественно, такие символы нужно игнирировать.
самим лучшим решением вообще было бы сделать такое поведение
опциональным. т. е. в процессе отладки системы и наполнения ее правилами
можно было игнорировать такие ситуации с символами, просто выводя
предупреждения. а в случае перевода системы в рабочий режим можно было
бы выключить игнорирование таких ситуаций.
> Кроме того, можно в lua добавить поддержку метрик в каком-то таком виде:
> conf['module']['symbol'] = 'rule'
> metrics['name']['symbol'] = <weight>
т. е. по сути можно в rspamd.xml просто описать метрику, а привязку к
ней символов с опреденными весами делать в lua?
вот этот вариант очень даже подходит. тогда для выключения какого-либо
текстового блока правил можно просто закомментировать включение файла с
этими правилами без правки rspamd.xml.
>> т. е. интересует что-то типа такого:
>>
>> local MAILMAN_MSGID =
>> 'From,Message-ID=/<([^\\@]+\\@[^>]+)>,<mailman\\.\\d+\\.\\d+\\.\\d+\\.\\1>$/'
>
> Опять же сделать это функцией на lua должно быть весьма просто (функции
> могут писаться прямо в правилах).
тогда этот вопрос мне придется отложить до изучения работы с регулярными
выражениями в lua. да и нужно будет разобраться с использованием
>> временно я отбился заменой условия сравнения адресов на следующее:
>> string.find(string.lower(mr), string.lower(sr), 1, true)
>
> Ага, спасибо!
на самом деле это решение тоже корявое.
если в RCPT TO будет [email protected], а в header To будет
[email protected], то правило FORGED_RECIPIENTS не сработает.
так что нужно или сравнивать адреса с помощью регулярных выражений, либо
писать функциою (если таковой еще нет) для извлечения адреса(ов) из
header To (вернее из произвольного поля) и сравнивать адрес из RCPT TO с
этими извлеченными адресами. т. е. я имею ввиду аналог эксимовской
конструкции ${address:<string>}
>> документация касается в основном администрирования того, что можно
>> получить из коробки. в ней мало что есть о том, как допилить систему под
>> себя.
>
> Документация по lua API на подходе.
отлично
>> 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
