Peter Donald wrote:
>
> 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.
This is effectively only allowing AND's, isn't it? Do other people think
this is sufficient, or would OR'ing be useful?
> >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.
Yes, I think this could be handy. What do others think?
>
> >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 ;)
Doing something like this would be helpful. For the IMAP stuff, I'm
serializing MessageAttributes and the message, but using the
non-serializable javax.mail.internet.InternetHeaders when required. Are
you serializing your headers, if so, why?
What's the advantage of breaking up the payload automatically? (and, I
guess you mean, storing them seperatley?)
Why not only do that if required?
>
> 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 ;)
>
Yes, I thought you might :-(
I avoided mentioning it because:
1) I haven't got my head around Camelot,yet
2) It looks like a big job
3) There's a whole load of other James stuff to do (making it stop
elegantly, making it reconfigurable on the fly, getting the IMAP stuff
to alpha state)
Charles
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
