Plans for rmilter
Rmilter had been created some years before rspamd development started. Unfortunately, it wasn't actively developed for many years so far. It has several design flaws, it uses archaic configuration system, it uses threads, it contains a lot of duplicated functions with rspamd and, finally, it has a lot of code shared with rspamd (but it's not always up-to-date however). I hasn't found anybody willing to support this code as a separate project, so I think it's a good point to stop and think of what to do afterwards.
After some thinking I've decided to reorganize rmilter project and to integrate it to the rspamd meta-project. However, I need to do the following first:
rmilteruseslibmilterlibrary which is poorly designed, enforces threads mode and has a lot of other issues, for example problems with integration to systemd or operating with the socket.rspamdnow proposes usage ofredisandrmilterstill uses memcached
The first issue is the most complicated one. I need to write a replacement of libmilter library but without the limitations listed above. I plan to do it as a standalone library (like librdns or libucl) for example.
It won't depend on the original libmilter and will have non-blocking IO model.
The second issue is much simplier: redis can be used just as memcached with certain settings. Moreover, the vast majority of rmilter functions could be done using rspamd LUA API, allowing to reduce the amount of work performed on the C side.
In general, I think it would be the proper choice: rmilter code is no longer actively maintained but I still receive feature requests and bug reports. Many of them just involve copy&paste from rspamd code which is the improper way of development process. I would also like to eliminate dependencies on libspf2 and libopendkim, as rspamd has the same functionality so far.
For now, I have no clear timeline for this project. Things would be clearer since I would have finished a new milter library. I'll keep this document updated from time to time when I have updates.