Mail injection is evil

[pilhuhn]

I'm currently struggeling with injecting Mail that is received via pop3 from a remote server.
I try to follow the way it is done in CmdDATA, but for me this uses much too much overhead.
What is the easiest way to inject mail in the system?

Actually, I think the fetchmail should not know what happens to the mail in the next step (i.e. not know if the delivery would be local / remote / mailinglist ..).

Thanks
Heiko

[acoliver]

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.

[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.

[acoliver]

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).

[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.

[acoliver]

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.