james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sid Stuart <...@weaselworks.com>
Subject Supporting multiple "root processor"s in James 1.3?
Date Sun, 20 Apr 2003 14:49:15 GMT
Hi,

This suggestion was sparked by Kenny Smith's letter on the James Dev 
mailing list on April 16. In it, he requested a mechanism to reinject 
mail delivered to the error repository.

My first thought was he needed a tool to resubmit the mail to the 
JamesSpoolManager to be run through the "root processor" again. But that 
submits the message to some tests, such as spammerlist matching, that 
really don't need to be done and to other tests that might generate 
erroneous or duplicate error messages.

The cleanest solution would be to have a second "root processor", 
defined specifically to deal with mail queued in the error repository. 
This root-error-message-processor could then be run on a regular 
interval to scan the error-message repository. Changes in the 
configuration, such as new aliases in Mr. Smith's case, would then allow 
the mail to be delivered. One nice aspect of this solution is that 
amailet could be defined that would delete error messages after a 
defined period of time.

I hesitated to suggest this solution though as it did not seem like a 
significant enough requirement to mandate such a major architectural 
change. Then I saw a note on the inclusion of the CMU Sieve mechanism on 
the James Wiki V3 Plans page. 
(http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3) 
<http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3>
Sieve defines a  language to "parse, sort and filter"  a user's mail on 
the server. The mailet package makes implementation of this feature 
quite simple. One simply writes a mailet that runs the user's sieve 
script before final mail delivery.

The problem with this is that one would also like to run new or edited 
sieve scripts on mail that has already been delivered. This creates the 
need for a "root processor" that will process delivered messages. With 
this second feature request, it starts to look a more generalized 
message processor facility is needed.

Sid

Mime
View raw message