2010/1/21 Robert Burrell Donkin <[email protected]>: > i think that using sieve to deliver IMAP mail is wrong. i think that > the script should set attributes on the mail (for example, set a > attribute for folder) and with independent delivery.
5 years ago I was proposing (http://markmail.org/message/xkcttgyqmfwpieew) to use a "destination" concept for moving mails around. I think we could use special email addresses (and maybe "forward paths", with reference to the "old" source routing stuff) so to still keep working with mail envelopes (even using a distributed email processor, as multiple james servers) or alternatively using urls. The fact is that "state" is not enough to deal with message routing so we need something more in the mailet api, and we can do this 2 ways: A. add routing methods, B. add some more expressive property than state. >> But I think you are right, the current MailRepository stuff is really >> bad in terms of Performance. > > here's the issues which spring to mind: > > 1. the POP3 protocol stuff is sound enough but MailRepository insists > on instantiating heavy mail objects which kills performance for IMAP > (my server died several times a day before i ripped out this feature) The Mail object should not be so heavy as it tries to lazy load stuff. But I'm not against changing the way it works. > 4. there are subtle semantic differences between the meanings of flags > in POP3, SMTP and IMAP Can you give more detail? I'm not sure I understand POP3 and SMTP "flags" ... > 5. there are subtle differences in rules between a POP3 INBOX and an > IMAP INBOX. not a problem to resolve but the code needs to understand > whether it's been used for IMAP or POP3 so it can behaviour correctly. > i think that this prevents the use of a single functional API. I need details on this too. POP3 does not have big requirements. It needs to be able to retrieve a list of message returning a "name" (persistent) and a size. Do you think this is hard to expose via an imap capable mail store? Or you are thinking of a mailbox api dealing with protocol stuff like "pop3 session", "deletes at the end of the session", "session sequence number for messages". At a glance we can deal with sessions at the protocol level using a very simple data access api. > my thinking is along the lines of: > > 1. introducing a new messaging style interface specifically for mail delivery Are you referring to the MailServer interface or an interface for the "Mail Envelope". With "Mail Envelope" (again something that I was discussing 5 years ago in the previous thread) the concept that we should separate the mime stream to a Message object and the smtp envelope to an envelope object and then reduce the mailrepository to a "message" repository and spool envelopes. So, at low level we could have an incoming message to be envelope+message.. smtp prepare the envelope object and stream the mime to a jcr content. Then puts the jcr url in the envelope and put the envelope in a jms queue. Then we move the envelope from queue to queue. Am I going off topic or is this what you had in mind with "new messaging style for mail delivery" ? > 2. introduce an efficient, simple, streaming POP3 backend API which > can be adapted to MailRepository or other mailbox designs. performance > for MailRepository would still suck but the OpenJPA (and potentially > JCR) backends from IMAP could be used without heavy adaption or > performance loss. IIRC I read multiple times that the current mailbox api is not great for imap: I don't know the imap stuff enough to make any statement on this but I'd like to understand if you think the goal is to improve it by making it more "imap oriented" or improve it by making it more "simple". I remember in past Joachim tried to explain me that imap reference emails with 3 types of identifiers and this make almost impossible to write a simple api for the message store: do you agree with joachim on this? Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
