-
1. Re: Mail injection is evil
acoliver Mar 19, 2005 3:34 PM (in response to pilhuhn)The mail listener chain should be factored out. Presently the mail listeners are their own MBeans but the chain (or ordering/association) is associated very strongly with the properties of the protocol. There ought to be a MailListenerChainMBean (which I kind of lean towards the idea of being itself a MailListener) that does the mail listener calls.
It might be that the process of getting and constructing a mail from an input stream might also be best factored out somewhere somehow.
Eventually we'll need to think about what local "user" fetchmail acts as but for the moment it ought to just construct mail objects and send them to the mail listener chain. (its up to them as to "what" happens from there)
Fetchmail is by definition "local" and never remote or maillist. -
2. Re: Mail injection is evil
pilhuhn Mar 19, 2005 3:42 PM (in response to pilhuhn)The local in 'by definition "local"' depends on your definition on local.
The fetchmail could operate for a bunch of receipients that are not sitting in the same office as the mailhub that is doing the fetchmail, but in a remote office with its own JBMail instance.
I am currently able to fetch several messages and inject the first one before getting a NPE, to expect something to look at soon. -
3. Re: Mail injection is evil
acoliver Mar 19, 2005 5:33 PM (in response to pilhuhn)See I really think this should work with mail listeners and not "inject" anything. It makes total sense that we may have the same or different chains of mail listeners for fetch that we don't otherwise. There should also be both "multi-user" fetchmail and bound fetchmail instances. Meaning that the multi-user mode would take the local user boxname and remote user boxname and password and go get it....where the tied one would do so on a schedule.
local means an account on the fetching server. Eventually fetchmail will need to deal with relays but "not yet" because we still have to make relaying work anyhow (so no point yet). -
4. Re: Mail injection is evil
pilhuhn Mar 20, 2005 3:47 AM (in response to pilhuhn)I may fail to see the big picture. At the moment it looks like the receiver (protocol) for a mail needs to decide which mail listeners a mail is sent to.
Perhaps we should rather follow the MBean+MBeanServer pattern, where the receivers (detached invokers) send the mail into a routing kernel (MBeanServer) which decides what to do with the mail.
On the path between receiver and kernel, interceptors could do mail manipulation like canonicalisation (sp?) of headers or tagging as possible spam.
My code will do bound-fetchmail, but when you call it from a (to be written) scheduler mbean, it can do multiuser. -
5. Re: Mail injection is evil
acoliver Mar 20, 2005 9:58 AM (in response to pilhuhn)That seems like a lot of work.
A simpler thing to do is factor this:
Message msg = mail;
while (mailListeners.hasNext() && msg != null) {
MailListener lsner = (MailListener) mailListeners.next();
jblog.info("sending mail to MailListener: " + lsner);
msg = lsner.send(msg);
}
into its own MBean. You use *that* to pick.
Now for the single mode its obvious that it will be bound to a particular mailbox. Meaning you'll need to manipulate the mail headers and change the "to" and make it a local account (whatever the fetchmail is configured to).
For the unbound you'll need a multitude of users->Box configuration. I suggest a mail listener for that! Then the rules for configuring remote-fetchmail and local-user can be factored out.