> по существу: такие простые вещи должны делаться - просто. Спасибо за конструктивную критику.
> В идеале -
> работать из коробки.
> А не требовать выкопать где-то в вике почти-подходящий кусок кода со страницу
> размером, требующий детальных объяснений автора, чтобы понять как он вообще работает.
Тут есть несколько проблем.
Первая из них в том, что функциональность модулей развивалась эволюционно: вначале сделали какие-то базовые вещи, потом пользователь A сказал, что ему надо одно, пользователю B другое, через N лет придумали какой-то новый фреймворк обработки данных, и решили его впилить. В итоге получается каша, но зато сохраняется обратная совместимость.
А ручек "вкл-выкл" или, там, "аз-5" не получается добавить просто, так как оно либо сломает совместимость, либо будет еще одной из многих крутилок.
Кое-где я пытаюсь сделать "привычные ручки" - вот в том же dkim_sign, как хотели того пользователи OpenDKIM. Многие вещи делаются "из коробки" по умолчанию, а некоторые делаются из утилиты configwizard - это как раз трансляция простых крутилок в более-менее сложные конфиги.
Для ratelimit такого не просили, зато просили сложных настраиваемых лимитов (в том же Mailcow). Если будет спрос на такие ручки, их можно будет добавить.
А так сложность - следствие желания покрыть все кейсы...
Вторая проблема - это проблема моего когнитивного искажения как автора, когда я пишу документацию и примеры. Я просто не могу себе представить, что у пользователей нет тех знаний, что есть у меня, и они не могут быстро "грепнуть" код, чтобы получить ответ на вопрос. Частично эта проблема решается коммьюнити, но для этого нужны опытные пользователи, которые могут обучать других, а с этим обычно беда - новичков хватает, а профессионалов очень мало.
> При том что это одна мелкая деталька в почтовой системе. Остальные будут
> закопаны в других местах - к великом счастью пришедшего после вас
> админа, получившего задание "поменять поведение вот в этом случае". С exim
> - он просто открывает Configure - и находит искомое (тоже в
> неудобочитаемом виде, но хотя бы - все сразу в одном месте).
> С альтернативами - угадай в каком костыле запилена эта подпорка.
С моей (неизбежно ангажированной) точки зрения, MTA отвечает за SMTP диалог, очередь и верификацию получателей. Фильтрация и модификация контента - это задача некоего отдельного сервиса. В моем представлении этот сервис - Rspamd. И основной плюс такой архитектуры, что этот сервис можно вынести в отдельную песочницу, минимизировав риски найденных уязвимостей. Поэтому ваш подход применим и к моему представлению о системе обработки почты.
> Ваша претензия к архитектуре exim - это претензия к архитектуре unix. exim
> в ней совершенно не виноват. (он, кстати, умеет скинуть рутовые права,
> но местами это ведет к неприятным глюкам, поэтому по умолчанию такое
> поведение и отключено)
Ну нет. Моя претензия к монолитной архитектуре Exim'а, унаследованной от Sendmail, и смешению доставки почты, фильтрации и ведению SMTP диалога. Это все просто невозможно сделать, чтобы дырка в коде не имела катастрофических последствий. Ну и опять же я много работал с кодом Exim'а - он оставляет желать лучшего, мягко говоря. А expand, утекающий для внешних данных, - это просто сплошная дыра, что последние найденные уязвимости подтверждают.
> архитектуру libmilter обсуждать будем?
Она, бесспорно, ужасна. Именно поэтому я НЕ использую libmilter в Rspamd. А сам протокол не такой плохой - он просто повторяет архитектурные проблемы smtp с abort и управлением стейтом.
