I know user rules aren't real popular with the sa dev community, however that attitude isn't universally shared by sa users. Therefore may I suggest:
Would it be possible when reorganizing things to come up with some semi-persistant storage for compiled user rules, so that they don't have to be rewritten and recompiled in a bunch of evals for every message processed for the user? At the very least it should be moderately trivial to save the text passed to the evals into a file someplace, and then just eval that one file to get everything compiled. Timestamps would indicate if the pre-built stuff was out of date or not. Is there a way that they could be saved in a more-compiled state when used with spamd and similar? Maybe name the rules with the username as part of the procedure name, and just add them to the namespace the first time encountered? If there were a way to make user rules be a subclass of the main rules, then you could just call the user rules for each user, and any user rules (or I presume scores) would override the standard rules, and anything that didn't override would pass through to the main rules. Of course this assumes "the rules" was a class instance of some sort of other, and you could call ruleclass->dorules(message) or the like (however that C++ invocation would be spelled in Perl). Having all user rules remain in memory forever would certainly add some to the bloat of SA memory usage. However, if one assumes most users would have few rules compared to the number of overall system rules, then the increase might be reasonable; especially since you would be trading off that memory for the compile and build overhead on every message. Loren BTW, if "the rules" were in a class, then it would be possible to create the instance of that class at startup in just about exactly the same way user rule subclasses could be created. Then a hup, instead of taking spamd and children down, would just cause the children to discard the current rules instance and fabricate a new instance and continue onward.