Анонсирован (https://rspamd.com/news/2015/05/15/rspamd-0.9.html) выпуск комплексной системы фильтрации спама Rspamd 0.9 (https://rspamd.com/), предоставляющей средства для оценки сообщений по различным критериям, включая правила, статистические методы и чёрные списки. В результате различных проверок формируется итоговый вес сообщения, на основании которого принимается решение о необходимости блокировки. Код системы написан на языке Си и распространяется (https://github.com/vstakhov/rspamd) под лицензией BSD. Проект развивается Всеволодом Стаховым, одним из основных разработчиков пакетного менеджера pkg (https://github.com/freebsd/pkg), используемого в проекте FreeBSD.Система построена с использованием событийно-ориентированной архитектуры (Event-driven) и изначально рассчитана на применение в высоконагруженных системах, позволяя обрабатывать сотни сообщений в секунду. Правила для выявления признаков спама отличаются высокой гибкостью и в простейшем виде могут содержать регулярные выражения, а в более сложных ситуациях могут оформляться на языке Lua. Кроме явных правил в Rspamd реализованы и статистические методы обнаружения спама, основанные на использовании баесовского классификатора.
Расширение функциональности и добавление новых типов проверок реализуется через модули, которые могут создаваться на языках Си и Lua. Например, доступны модули для проверки отправителя с использованием SPF, подтверждения домена отправителя через DKIM, формирования запросов в списки DNSBL. Для интеграции Rspamd с postfix и sendmail применяется rmilter, для exim предлагается специальный патч, dlfunc или local_scan. Для упрощения настройки, создания правил и отслеживания статистики предоставляется административный web-интерфейс.
<center><a href="https://rspamd.com/img/webui.png"><img src="https://www.opennet.ru/opennews/pics_base/0_1431635055.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
В новом выпуске была переработана или полностью переписана большая часть кодовой базы с целью улучшения архитектуры, производительности и стабильности. Обеспечена поддержка правил SpamAssassin. Внесены значительные оптимизации, такие как задействование LuaJIT и PCRE JIT, применение алгоритма Ахо — Корасик (https://ru.wikipedia.org/wiki/%D0%90%D0%... для обеспечения поиска по сотням тысяч масок и переход на использование абстрактного синтаксического дерева (https://ru.wikipedia.org/wiki/%D0%90%D0%... для всех выражений. Обеспечена возможность шифрования всего трафика. Представлена новая архитектура статистической оценки сообщений, применяющая расширенные методы разбиения текста на токены и поддерживающая кэширование результатов обучения.
URL: https://rspamd.com/news/2015/05/15/rspamd-0.9.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=42233
А поддержки OpenSMTPD нет. Ненужно.
Поддержка нужна как раз со стороны OpenSMTPD - с самим rspamd можно общаться хоть банальным curl'ом. А вот интерфейса фильтров в OpenSMTPD я от авторов сервера жду уже больше года, а воз и ныне там.
https://poolp.org/0xa871/The-state-of-filters
> https://poolp.org/0xa871/The-state-of-filtersВот ровно об этом я и говорю. Обещания я слышу уже долгое время и слежу за проектом по мере собственной нагруженности.
|procmail
посмотрел build requirements, не проникся.
Почините action "greylist", сейчас он бесполезен, т.к. сообщение проверяется антиспамом уже после проверок RCPT TO. Внешнему фильтру уже письмо не передать на этом этапе, а сам rspamd состояние попыток доставки не хранит.
Не понимаю, как связаны проверки rcpt to и грейлистинг. Да, rspamd выполняет проверки после end-of-data, но это всего-навсего дает чуть бОльший оверхед, но MTA может ответить 4.7.1 Try again later и после '.', что прекрасно работает на практике.
Напрямую они связаны. Грейлистинг - это собственно связка отправитель - получатель - ip отправителя. На этапе end-of-data уже нет возможности получить отдельного получателя, только всё скопом с копиями, скрытой копией и т.д. Это раз.Второе - даже если ты ответил 471 после end-of-data по указке rspamd - как ты узнаешь, что это письмо тебе уже приходило? Контент при retry будет тот же самый, rspamd опять ответит 471 и так далее до протухания письма в очереди на отправителе. Сам же rspamd такую статистику не ведёт, я смотрел исходники.
> Напрямую они связаны. Грейлистинг - это собственно связка отправитель - получатель -
> ip отправителя. На этапе end-of-data уже нет возможности получить отдельного получателя,
> только всё скопом с копиями, скрытой копией и т.д. Это раз.Вы неправы. Эту информацию передает мильтр непосредственно rspamd через HTTP заголовки. Включая также IP, envelope информацию, helo и многое другое.
> Второе - даже если ты ответил 471 после end-of-data по указке rspamd
> - как ты узнаешь, что это письмо тебе уже приходило? Контент
> при retry будет тот же самый, rspamd опять ответит 471 и
> так далее до протухания письма в очереди на отправителе. Сам же
> rspamd такую статистику не ведёт, я смотрел исходники.Вы не учли, что грейлистинг делает не rspamd, а milter. Rspamd лишь говорит: вот это письмо мне не очень нравится, давай попробуй его погрейлистить. Следовательно, если клиент приходит до истечения таймаута грейлистинга, то фильтруется он уже самим мильтром на стадии rcpt to.
> то фильтруется он уже самим мильтром на стадии rcpt to.Воот, то есть у нас будет 2 разных вызова мильтера, и из rcpt_verify (2+) и из data_verify (1). Не находите, что это несколько кривая и, мягко скажем, нетривиальная в поддержке конфигурация?
>> то фильтруется он уже самим мильтром на стадии rcpt to.
> Воот, то есть у нас будет 2 разных вызова мильтера, и из
> rcpt_verify (2+) и из data_verify (1). Не находите, что это несколько
> кривая и, мягко скажем, нетривиальная в поддержке конфигурация?Простите, я не смог понять ваш комментарий. Либо вы ничего не понимаете в том, как работает milter, либо не можете описать проблему.
Ну бывает, попробую расписать на примере.Первый заход: приходит хост, пытается слать письмо. rcpt_verify его пропускает, доходит до data_verify, там rspamd говорит - "данные левые, а сделай-ка ты greylist". Теперь у нас есть ip-отправителя, адрес отправителя из конверта, и получатели все скопом. Последнее плохо ложится в базу, а ещё в exim'е нет лёгкого способа разлепить обратно получателей на этом этапе. Ну хорошо, допустим отправили 4XX, хост ушёл, письмо не принято.
Второй заход: приходит хост, пытается слать письмо. rcpt_verify опять его пропускает, потому что "почему бы и нет, мне никто не сказал что его надо грейлистить". Доходит до rspamd, тот опять говорит - "данные левые, а сделай-ка ты greylist". Теперь нам опять нужно разлепить получателей, угадать с тем, что мы выбрали в прошлый раз, и пнуть milter с greylisting'ом, чтоб тот проверил, пускать ли его дальше.
Недостатки такого костыля:
* письмо при каждой попытке доставки проходит через антиспам, хотя могло быть остановлено раньше и значительно дешевле по ресурсам. А раньше остановить его при данной схеме не получится, потому что почтовик не может на этапе rcpt_verify магическим образом угадать, что на data_verify его загрейлистят. Ни при первой, ни при последующих попытках доставки.
* кастомный механизм "разлепить получателей" на эксимовском конфиге - это практически write-only. В результате образуется "незаменимый гуру", который после получасовой медитации возможно сможет вспомнить как оно работает.
* как альтернатива предыдущему пункту - брать получателя "как есть", мириться с медленной работой базы грейлистинга, т.к. юзеры любят ставить в копию по 5-10-15 человек.
* необходимость во внешнем мильтере грейлистинга и настройка их связки со rspamd. Конфиг становится "хрупким", и см выше про "гуру".Если уж мы всё равно каждый раз доводим почту до антиспама, так пусть тот сам и ведёт учёт попыток доставки, раз такой умный. По крайней мере это позволит избавиться от внешнего грейлистинга.
// надеюсь понятно расписал
Спасибо, теперь понятно. К сожалению, я сам не использую связку exim+rspamd, но то, что вы описали действительно может быть проблемой, которая решается на уровне rspamd. В следующей версии я планирую сделать несколько уровней фильтрации письма: fast path - на этапе helo .. data и slow path - на этапе end of data. Тогда единственной проблемой будет сохранение состояния между двумя этими фазами, но тут надо смотреть, как это смогут делать MTA. Связка rmilter+postfix+rspamd умеет делать грейлистинг без лишних затрат (кроме самого первого раза).В любом случае, прохождение письма через rspamd зачастую бывает дешевле по ресурсам, чем оптимизация на уровне MTA (в отличие от того же SA).
> прохождение письма через rspamd зачастую бывает дешевле по ресурсамЕсть ещё и намного больший фронт потенциальных уязвимостей в антиспаме, тем более на си.
>> прохождение письма через rspamd зачастую бывает дешевле по ресурсам
> Есть ещё и намного больший фронт потенциальных уязвимостей в антиспаме, тем более
> на си.То есть, MTA на Си, да еще и с собственным тюринг-полным языком конфигурации, вас не смущает, не так ли?
Нет, не смущает. exim'у - 12лет, баги с парсером smtp там уже давно выловили. Передача данных smtp-сессии в обработку без фильтрации - ССЗБизм и не лечится.А вы предлагаете выставить много свеженького, необкатанного и сложного сишного кода прямо к обработке потенциально ненадёжных данных, без особой на то необходимости. Причём не "вместо", а "в дополнение" к exim'у. Простите, но у вас пока нет истории безопасности.
UPD: Даже не 12, а 20, википедия говорит, что первая версия появилась в 95году.
Понятия "история безопасности" не существует. Вот история дыр и уязвимостей да, существует, и она у exim'а довольно богатая. Контент сканнер может запросто работать в отдельной песочнице, и даже при нахождении критических дыр он не взаимодействует с внешним миром никак, кроме DNS запросов и запросов к хранилищу нечетких хешей (что тоже отключается). В этом я вижу существенную разницу с MTA, который вынужден постоянно общаться с внешним миром. Я никак не могу прокомментировать все заявления касательно безопасности кода rspamd, потому как у всех комментаторов заведомо непробиваемая позиция: "наверняка в коде на си есть уязвимости" (причем, я с ней в какой-то мере согласен, но не видеть разницы между ошибкой и *эксплуатируемой* уязвимостью - это характерная черта подобных критиков). Конечно, с такой точки зрения не стоит вообще приближаться к компьютеру ни при каких обстоятельствах.
exim'у нужен только внешний bayes, всё остальное он и сам умеет нативно.
Это так. Но для этого нужны мозги и опыт, чтобы вылизать конфиг.
Учитывая, что примерно половина пользователей rspamd пользуются как раз exim, включая многих серьезных специалистов по этому MTA, я не был бы настолько категоричен. Ну и опять же, цель rspamd - поток в сотни сообщений в секунду. Exim с развесистой конфигурацией неспособен работать на таком потоке (по опыту, впрочем, он и без развесистой конфигурации неспособен, но флейм разводить я не хочу).
не холивара ради, поделитесь опытом!
Кулстори бро, рассказывай ещё.> Exim processes SPF based on raw logic. Thus if a domain uses +all, which means every host will pass, this doesn't provide any useful information.
Насчёт wide mask +all тоже ничего не предпринимается. Предлагаете лепить неподдерживаемые простыни на встроенном perl'е, с кучей acl_m/acl_c?
То же самое насчёт PTR'а - если он есть, но не совпадает с A - считается что его как бы и нет вовсе.
>То же самое насчёт PTR'а - если он есть, но не совпадает с A - считается что его как бы и нет вовсе.Зачем стрелять себе в яйца? Это ситуация и тупо NO_PTR - это две большие разницы!(С)
Да-да, "раз не умеет - не это нужно", проходили уже.
Кто-нибудь на код с точки зрения безопасности смотрел? Производительность конечно хорошо, но использование языка Си вызывает опасения. SpamAssassin хоть и тормозной, но уже проверен вдоль и поперёк, да и perl позволяет не задумываться о переполнении буферов. А с Rspamd боюсь, что может повториться ситуация с clamav, в котором дыра дырой погоняет.
Ещё один с фобией.
Нет, разумное обоснование в этом есть, хотя, конечно, считать, что SA, использующий сишные библиотеки, работающий с сишной libc, в ОС, написанной на Си, и компилирующий свои правила в Си, абсолютно безопасен напоминает мне известный анекдот про феминисток.Впрочем, если бы я начинал этот проект сейчас, то очень бы пристально присматривался бы к rust, но тогда не было не то, что rust, но даже и C++11, а писать production системы на функциональных языках я, к сожалению, до сих пор не научился.
> Впрочем, если бы я начинал этот проект сейчас, то очень бы пристально
> присматривался бы к rust,А что нем известно о безопасности rust? А ничего не известно :) Так что всё правильно сделал. Ди потом - после кернела и (г)либцЫ на сях ... выдохни уже :)
Как в Iredmail засунуть?
Становишься раком и вставляешь его себе в Iredmail.P.S. Гугл твой друг.
Не нужен. Постфикс + грейлист + сапассассин вполне справляются, проходят только "коммерческие предложения" с mail.ru и т.п. российских почтовиков. Штук 5 в неделю.
Справляется, конечно, но SA проц грузит не по-детски под нагрузкой... Может у этого получше ситуация? Даже если нет гибкости SA, скорость - это важно.
> Справляется, конечно, но SA проц грузит не по-детски под нагрузкой... Может у
> этого получше ситуация? Даже если нет гибкости SA, скорость - это
> важно.Вот отчет одного из разработчиков haraka:
https://github.com/baudehlo/Haraka/pull/964#issuecomment-100...0.9 быстрее процентов на 50 (это тестирование делалось для 0.8.3), кроме того, у rspamd гораздо проще получается работать с большим количеством писем параллельно, чем у того же SA, у которого постоянно в пиках кончаются воркеры в пуле.
Да ладно вам, "нинужники" - вон в соседнем треде во всю МС-поделки рекламируют, в другом юникс-утилиты на Го переписывают, в третьем очередной пакетный менеджер на питоне представляют ...А тут - оно на Си, с открытыми сырцами (даже не пришлось пол-часа искать ссылочку на гитхаб - она на видном месте красуется "Fork me on github" https://github.com/vstakhov/rspamd ), да еще и не очередной полузаброшенный проект-лаба.
Так что: годнота! Автар - пиши исчо! (<- говорят, доброе слово даже кошке приятно)
Чем бы дитя не тешилось, лишь бы на java не писало...
А нельзя ли без патчей экзима? Сделать, как у СА - висеть себе тихо на сокете, на вход принимать письма, в ответ выплевывать оценку. И больше ничего.
> А нельзя ли без патчей экзима? Сделать, как у СА - висеть
> себе тихо на сокете, на вход принимать письма, в ответ выплевывать
> оценку. И больше ничего.В будущую версию exim патч уже включен.
Rspamd обратно совместим с протоколом SA. Он не умеет только генерировать отчеты в стиле SA, потому что я счел несовместимым с производительностью модифицировать письмо в rspamd и отсылать его обратно.
> Rspamd обратно совместим с протоколом SA. Он не умеет только генерировать отчеты
> в стиле SA, потому что я счел несовместимым с производительностью модифицировать
> письмо в rspamd и отсылать его обратно.Оно не только с производительностью несовместимо :) Результатом работы анализатора должна быть оценка - и все. А модифицировать тело письма (не хедеры) - вообще идиотизм, тело письма неприкосновенно.
