I would tend to agree with Danny on this... aside from the challenge of making the processor load from a DB, usually it's one or two mailets/matchers that you want dynamic configuration from, not dynamic configuration as a whole. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/
Noel J. Bergman wrote: > Sam, > > >>I was thinking of going ahead and create a db repository version of > > dynamic > >>lookups of mailet configurations [and] give users the control of defining >>mailets at run-time > > > I don't know what it would take to build Processor chains dynamically, but > am I unconvinced that I would want to allow arbitrary mailets to be loaded > without admin authority. It seems to me that there are less radical > approaches than modifying James to build processing chains dynamically based > upon matching. Your salient point was "we may want to impose further mail > restrictions [by] offering Junk Filters at the discretion of [users and > postmasters.]" > > Filters are generally matchers, not mailets. There is already a matcher > (NESSpamCheck) that filters based upon regex patterns. The patterns are > hardcoded in the matcher, but could be moved into a database table. You > could extend the notion to support more sophisticated matching driven by > dynamic, even recipient specific, content in a database. > > --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
