Mark Martinec writes: >> Also, any suggestions from outside the dev team? Anyone got good ideas >> for new SpamAssassin features that would be good to pay someone to work on >> for 3 months? > >Here's another one, to seize the opportunity when internal changes >are being contemplated: > >Split the process into two parts: > >- parsing and munging of mail & rules, resulting in a set of > findings (e.g. a list of rules being hit, perhaps somehow > generalized). This section can be done once per message, > regardless of the number of recipients to the message > (assuming all users use the same rules); > >- based on the above, score the findings, possibly > applying per-recipient scoring to each rule being hit; > This (rather inexpensive) step can be applied for each > recipient individually, without having to re-process > an entire message in multiple-recipient mail. > >...and adjust the API to Mail::SpamAssassin accordingly, so that >MTA-based content filtering (e.g. amavisd-new) could take advantage >of it, while still allowing full per-recipient customization of >individual rules scores (including disabling some by a score of 0). > >Benefits depend on a site, but our stats show 1.46 recipients >per message on the average. The above change (when calling SA >at MTA level) would bring a 46 % increase in througput for free, >while still providing individualized rules scoring.
Mark, could you open a feature-request bug for this? I think it'd be worthwhile, and would definitely be a good SOC project (at least). --j.
