Прикрутить можно как угодно. Если это веб сервис, то, наверное, проще использовать rspamd в виде HTTP сервера, который выдает результат в виде json объекта (это настраивается в секции ), если почтовый — то проще использовать описанные в документации способы.
Если обучать статистику спамом с разных аккаунтов, то ее качество, безусловно, повысится, т.к. это даст больше разнообразных спам токенов, которые будут в дальнейшем оцениваться. Главное — обучать реальным спамом, а не тем, что считают «спамом» пользователи — практика показывает, что зачастую это диаметральные противоположности.
Даже проще сделать так: если glib версии меньше, чем 2.16, то компилировать нехватающие возможности отдельно и линковаться с ними динамически, не нарушая лицензионных требований.
Ответить на этот вопрос довольно сложно — иногда даже человек с трудом может понять, спам это или же легитимная рассылка. Я сам обучаю систему спамом с разнообразных источников, предварительно удостоверившись в том, что это действительно спам, и результат мне кажется достаточно неплохим. Но нужно иметь в виду, что для стабильной работы статистики не стоит делать перекос в сторону спама — количество хама должно быть соизмеримым, чтобы статистика работала в обе стороны.
В glib2.14 и glib2.16 были добавлены такие фичи, как обертка вокруг PCRE (GRegex), которая довольно часто используется в rspamd, библиотека хеширования (GCheckSum) и некоторые другие возможности. Встроить их в rspamd для совместимости не позволяет лицензия (LGPL несовместима с BSD). Но я подумаю, что можно сделать, — все эти зависимости достаточно легко реализовать с нуля.
Нет, сейчас возможность per-user статистики (если я правильно Вас понял) не реализована. Сейчас есть только возможность загружать пользовательские настройки — число баллов, пороги срабатывания действий по письмам, «белые» и «черные» списки. Подробно об этом написано тут. Но если Вы всерьез решили использовать rspamd и единственное, чего Вам не хватает, — это per-user статистика, то я могу эту возможность реализовать в следующей версии, так как в текущую архитектуру статистики это вписывается без проблем.
Да, либо создать собственную статистику «с нуля», либо скачать мои статфайлы и, взяв их за основу, дообучить собственным набором. Доработать систему автообучения у меня в ближайших планах — существующая система, взятая из SA, как показала практика, скорее зло, чем полезная фича. В планах создать более гибкую систему, чем обучение на основе баллов, которые набрало письмо. Скорее всего, это будет lua скрипт, в задачи которого войдет мониторинг различных параметров письма: баллов, символов, степени «доверия» к ip адресу отправителя, «полезность» письма для статистики (бесполезно обучать статистику слишком большими или слишком маленькими текстовыми данными).
Дело в том, что rspamd разрабатывался с расчетом на автоматическое управление через веб-морду. Поэтому вещи, которые легко и часто меняются, настраиваются через xml, который с одной стороны более-менее удобно править руками, а с другой — легко распарсить и сгенерировать автоматически. Да, я знаю, что решение перевести конфигурацию с lex/yacc разбираемого формата, напоминающего конфиг bind, на xml было спорным. Однако, сейчас желающие могут настроить практически любые параметры из lua, оставив xml конфигурацию по умолчанию (настройки lua перекрывают настройки xml).
Если обучать статистику спамом с разных аккаунтов, то ее качество, безусловно, повысится, т.к. это даст больше разнообразных спам токенов, которые будут в дальнейшем оцениваться. Главное — обучать реальным спамом, а не тем, что считают «спамом» пользователи — практика показывает, что зачастую это диаметральные противоположности.