At 06:58 5/1/01 +0000, Charles Benett wrote:
>Here's some ideas on the Mail Engine, for your comments.
>
>At the moment, you can configure a set of processors, each with a list
>of mailets.
>Each mailet config is, in effect an if..then: if (matcher) then
>(mailet).
>There is only one class of processor (Linear Processor). It checks for
>recipients of a Mail that match the matcher. A mail with the matching
>recipients is passed to the mailet. (If there are non-matching
>recipients, a duplicate Mail with them drops through to the next
>matcher) (Matchers such as SubjectInFakeDomain, ir they match, respond
>with all recipients.)
>A mailet passes a Mail to another processor by changing the state of the
>Mail.
>I was simply going to formalize the current structure using the new
>Avalon Interfaces of Stage and Pipeline. But thayt lead me on to a few
>questions about how best to do this processing. Partly reflecting
>comments on the list over the last few months.
>
>How about:
>1) if..then..else stages?
>2) boolean matching criteria, e.g. if (matcher1) && (matcher2) then
>mailet?
How about it is handled in a chain. So you would have something like
<matcher name="m1" ... >
<matcher name="m2" ... >
<matcher name="m3" ... >
<mailet name="mailet1" .../>
</matcher>
</matcher>
<matcher name="m4" ... >
<mailet name="mailet2" .../>
</matcher>
</matcher>
This would build two chains. ie
m1 -> m2 -> m3 -> mailet1
m1 -> m4 -> mailet2
This is more difficult on admin but much more flexable in long run and
allows much better reuse of matcher components.
>3) Would it be useful to have more explicit processors, a bit like a
>Linux 2.2 firewall system, e.g. incoming, forwarding, outgoing?
I am not sure it is worth it - these are conceptual categories and don't
even make sense for some types of mail servers. For instance if you want
JAMES to act as a mail relay then what processors are used? Personally I
would let admin develope the conceptual framework and JAMES just provide
the tools. Thou this is comming from someone who has had to setup a few
non-standard setups so YMMV ;)
>4) Would it then make sense to have matchers that return boolean, e.g.
>for SenderOnSpamBlackList, with an alternative class of processor that
>uses them?
+10000
This is one of the most useful things I found. I was able to get message
traversal going really easy with simple interface for matchers and was a
real no-brainer to operate. This is not case with ccurrent setup as you
have to be aware about how different users are matched/extracted and
when/how need to send mail through multiple times etc.
>5) There was a suggestion, I think from Peter, that it might be more
>efficient to split each Mail by recipient early, then process each
>single-recipient Mail seperately.
+1
fits very well with 4. However I would go one step further - I would setup
the mail to have at least three sections.
Mail envelope - contains the identities indicated in RCPT TO:, MAIL FROM:,
the Message-ID, the source host (ie which host sent it to us), the date
received.
Mail headers - basically the list of relevent headers (relevency indicated
by being required or useful)
Mail payload - the full text of mail possibly in MBox format.
I setup my messagecenter like this and it made it very easy to do most
things. It was also great for keeping an audit trail. I had planned to
break up payload into bodys (alla Multipart-mime bodies) but never got
around to it - however a lot of peeps recommended that to me.
Setting it up the above way also minimizes redundency to a degree allowing
graceful dealing with 12 MB mails ;)
One thing I would like to see is you to test drive the Camelot Container
API in Avalon ;) It would hopefully make it easier to load mailet
components from external jars etc and do all sorts of funky stuff. Besides
I need someone to go through and tell me which bits are stupid ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
