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]>
