> Насчет перла и си: да си быстрее и потенциально более опасен, чем perl, при прочих равных
> условиях.

ну то есть в сферическом вакууме, да ;-) Главное, чтоб этот код ничего полезного ненароком не делал.

> Насчет DNS запросов: вы неверно поняли этот слайд (или я его неверно составил). Посыл был
> в том, что ресурсы на обработку писем нужно лимитировать, иначе будет "ой".

необязательно - не все же бразильские локалвебы, у кого-то просто небольшой почтовик в углу тарахтит - если там даже вообще спамфильтр sig11 по башке завершится, ничего прямо ужасного не произойдет (в крайнем случае потеряется письмо, что тоже не ужасно), к тому же помимо спамфильтра другие ресурсоеды есть, включая сам mta.

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

Существует мульон причин вообще не рассматривать SA как замену rspamd во многих случаях, впрочем, как и наоборот (во всяких микросетапах, где SA и так уже есть и работает - вот совсем не надо открывать для себя и своих юзеров новенькое поле непаханных грабель)

8s, конечно, случай клинический (в смысле, это само по себе признак, что ничего в том письме хорошего не было ;-) но, возможно, если поискать, найдется и для rspamd подобный образчик? (для таргетированной атаки на того же бразильеру - очень даже могут поискать) Понятно, там надо в первую очередь обмануть логику, запускающую отброс на ранних стадиях, то есть оно совсем по-другому должно выглядеть.

btw, про dns: на всяк случай напоминаю, что любой домен в письме, кроме тех что и так анализируются mta, может оказаться валидацией существования почтового ящика (url открывать не надо, достаточно поресолвить <encoded mailid>.roguedomain.com )

> Насчет "не глядя": тут такое дело, что обычный гопник Вася будет лучше, чем самая
> сложная и совершенная система антиспама.

не, он false positives дает при нечетких критериях - subject закорючками, del...ой, это ж от Ли из Синьдзяня письмо...было.

А насчет скорости и прожорливости - так тут вопроса-то нет, просто дело-то не столько в сях, сколько в узкоспециализированном самописном коде вместо собирания из CPAN всего что в рот полезло (кстати, и как там у нас с безопасностью при зависимостях зависимостей от незнамочьих модулей, обновляемых по чесанию левой пятки? Вот того же Net:DNS, хотя бы? ;-) Ну и опять таки - кому-то нужна скорость, потому что иначе можно просто бизнес закрывать и идти по домам, а у кого-то критерий влезть при надобности в потроха самому - и вот тут плюсы резко становятся минусами, ибо разбираться долго и сложно.