2010/1/22 Robert Burrell Donkin <[email protected]>: > On Fri, Jan 22, 2010 at 8:52 AM, Stefano Bagnara <[email protected]> wrote: >> 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. > > sounds very interesting. could you write up the design more fully?
Currently we have multiple ways we move emails around: 1) alter the "Mail.state" let us moving from one processor to another (the most used one) 2) call MailetContext.sendMail/MailServer.sendMail to put a copy or the male itself back in the spool (usually done in the forward/autoreply/notify mailets. 3) lookup a repository from the store and put that message to the repository (LocalDelivery, ToRepository, part of RemoteDelivery) 4) have a mailet with special code that transmit the message content using a custom way (like part of RemoteDelivery) James (the spoolmanager) have complete control in case 1 (it is the spoolmanager to really move the message) and partial control on 2 (the spoolmanager knows this, but it doesn't know what is the relationship between the mail being processed and the mail being sent via sendMail). THe spool does not have control on what happens in 3 and 4. Furthermore 3 is something we all like agreed we should fix (remove) because this makes many mailets to be james specific and not generic mailets. In past we had contrasting proposals: A. add repositories to the mailet api, B. extending the state/sendMail behaviour so that inbox delivery is supported without looking up the Store/Repositoryes. Then we have something that we would like to "add" to the current functionalities: 1) being able to process messages based only on their envelope or only on the message headers (in contrast to processing full Mail+MimeMessage objects like we do now) 2) being able to track the flow of a message (so that the spoolmanager can tell us if a message we sent it has been processed and if it is processed what is the status: failed, relayed, delivered to remote host, delivered locally, explanded to list of recipients... etc...). This one is something that would allow us to really implement DSN, but I'm not sure that DSN worth this complexity, so I simply share this possible "requirement" but I'm not saying we should really try to fix (implement) this. 3) We all agreed that we should stop moving around the whole Mail+MimeMessage and instead split this so to move less data as possible. From my understanding this means that an incoming message is placed in a messagestore and its envelope(+maybe metadata) is moved around. I'm not sure whether "inbox delivery" will eventually move the message or if the message will be still referenced to the original place we wrote it, but we all know that we should stop copying the full message at every spooling choice. So, this is the list of current usecases, I need more time to elaborate possible improvements, so I just share this by now. Maybe you like to add usecases, too. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
