-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi :) Is there any plan to include delivery agent in 1.x? I would be very happy, if there would be lmtp delivery agent included with dovecot 1.x... This would make creating large mailsystem cluster creation very simple + indexes would be always up2date. Brane -----BEGIN PGP SIGNATURE----- iD8DBQFBytD9N7LHXgqRB4IRAi67AKCn/A1t3tCsMX0nhL8l4sgzTfDhlACgj1j5 NdgMzA3v0dLx6Bnui62rLRc=4UGm -----END PGP SIGNATURE-----
On 23.12.2004, at 16:06, Branko F. Gra?nar wrote:> Is there any plan to include delivery agent in 1.x?I'll need to implement one in next few months, so yes. Hmm. This brings to my mind again that it would need Sieve, and mvmf might be a good base for it, but it's still not open source (Mark? :)> I would be very happy, if there would be lmtp delivery agent included > with dovecot 1.x... This would make creating large mailsystem cluster > creation very simple + indexes would be always up2date.I'm not sure when I'll get around to implementing LMTP server. It's actually a bit annoying to implement because it needs to be able to deliver mail into multiple accounts, and if each one stores mails with different UID, it needs to either run as root (bad) or launch multiple processes and do IPC with them. I suppose I'd implement it so that the actual LMTP talking would be done in a process very similar to imap/pop3-login processes, ie. completely unprivileged. Then it would tell master process to launch delivery agent processes to specific users, and those delivery agents then would get the mail from lmtp process via .. um. read-only shared memory + semaphores might be better than just copying the data over pipes/sockets? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20041223/180bc452/attachment-0001.bin>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timo Sirainen wrote: | | I'll need to implement one in next few months, so yes. | | Hmm. This brings to my mind again that it would need Sieve, and mvmf | might be a good base for it, but it's still not open source (Mark? :) libsieve is released under double license: http://libsieve.sourceforge.net/license.php New, sieve2_* api supports reading sieve scripts from char * array, therefore it would be very easy to create some sort of sieve script fetching abstraction layer... Brane -----BEGIN PGP SIGNATURE----- iD8DBQFByvS8N7LHXgqRB4IRAgQCAJ0f+/VkNQDz3CjnILpkJTNkpIHCzQCdGuGo m4diYrvpZH4tk31VoVY6Ejg=3zYQ -----END PGP SIGNATURE-----
On Thu, 2004-12-23 at 17:52 +0200, Timo Sirainen wrote:> On 23.12.2004, at 16:06, Branko F. Gra?nar wrote: > > > Is there any plan to include delivery agent in 1.x? > > I'll need to implement one in next few months, so yes. > > Hmm. This brings to my mind again that it would need Sieve, and mvmf > might be a good base for it, but it's still not open source (Mark? :)It may be difficult to please everyone. I could have use for [some elements of] a dovecot-lda but zero use for sieve...> > I would be very happy, if there would be lmtp delivery agent included > > with dovecot 1.x... This would make creating large mailsystem cluster > > creation very simple + indexes would be always up2date. > > I'm not sure when I'll get around to implementing LMTP server. It's > actually a bit annoying to implement because it needs to be able to > deliver mail into multiple accounts, and if each one stores mails with > different UID, it needs to either run as root (bad) or launch multiple > processes and do IPC with them.How about a dovecot-inject tool that writes a message to whatever is considered the $LOCAL user? It wouldn't have to do much but write the message (safely) and update indexes -- something dovecot already has to do. That way: * People who do delivery without LMTP baggage aren't treated as second- class citizens. * Sieve implementations merely have to treat "keep" and "fileinto" as subprocesses. * LMTP implementations can do the work they've already have to do (regarding mapping email addresses to local users) and simply hook into the sieve processor or the dovecot-inject, or anything else the administrator/user likes. Formally, dovecot-inject would need the following information: 1. the envelope recipient ($RECIPIENT) 2. the envelope sender/return-path/errors-to-address ($SENDER) 3. the IMAP folder to write the message to (argv[1]) On systems with shared-uids, dovecot-inject would also need the concept of the "localpart" of the address thats applicable. dovecot already needs to know this in order to ACCESS the maildrop. ($LOCAL) This would keep things very easy to integrate without resorting to shared libraries, "plugin system" nonsense, or forcing people to make extra levels of indirection (lmtpclient) in order to benefit from pre- login indexing...> I suppose I'd implement it so that the actual LMTP talking would be > done in a process very similar to imap/pop3-login processes, ie. > completely unprivileged. Then it would tell master process to launch > delivery agent processes to specific users, and those delivery agents > then would get the mail from lmtp process via .. um. read-only shared > memory + semaphores might be better than just copying the data over > pipes/sockets?blah blah blah... -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
On Thu, Dec 23, 2004 at 05:52:12PM +0200, Timo Sirainen wrote:> On 23.12.2004, at 16:06, Branko F. Gra??nar wrote: > > >Is there any plan to include delivery agent in 1.x? > > I'll need to implement one in next few months, so yes. > > Hmm. This brings to my mind again that it would need Sieve, and mvmf > might be a good base for it, but it's still not open source (Mark? :)Only because I'm too lazy to deal with thinking about terms, certainly that was more true a year ago when it was less well developed. And maybe because I'm not clear on the what the problems are with the terms right now. e.g. qmail is "closed" in similar way. But all the source code is there for the taking. I've done a lot of work on it over the past few months, BTW. http://www.mvmf.org/ for those who don't know what it is. mm
--On Thursday, December 23, 2004 5:52 PM +0200 Timo Sirainen <tss at iki.fi> wrote:> I'll need to implement one in next few months, so yes.Would it be practical to implement it as a new back-end in procmail? Would the procmail maintainers be open to adding new back-ends, or abstracting the mailbox interface to a plugin architecture?
Timo Sirainen wrote:> On 23.12.2004, at 16:06, Branko F. Gra?nar wrote: > >> Is there any plan to include delivery agent in 1.x? > > > I'll need to implement one in next few months, so yes. > > Hmm. This brings to my mind again that it would need Sieve, and mvmf > might be a good base for it, but it's still not open source (Mark? :)FWIW - I know more than one person whose sole reason for not leaving their current IMAP server is Sieve. Now, if there were some way to write Sieve scripts and store them in a special folder... and if only Thunderbird would write its filters to it :) Ah well... I can dream, can't I? :) -- Curtis
"Branko F. Gra?nar" <bfg at noviforum.si> writes:> Is there any plan to include delivery agent in 1.x? > > I would be very happy, if there would be lmtp delivery agent included > with dovecot 1.x... This would make creating large mailsystem cluster > creation very simple + indexes would be always up2date.Anyone considered extending maildrop? It's GPL'd and established. OTOH, I'm not sure if the delivery agent itself needs to understand LMTP. -- Matthias Andree
On Thu, 23 Dec 2004 Geo Carncross wrote:> How about a dovecot-inject tool that writes a message to whatever is > considered the $LOCAL user? It wouldn't have to do much but write the > message (safely) and update indexes -- something dovecot already has to > do.I hope there will soon be a plain delivering tool for dovecot 1.x. I could use it right away as the delivering step with procmail, which would run it under recipient's uid and context (all recipients are real unix users in my case). Without a local delivery agent, dovecot will always seem slower than its rivals when opening INBOXes with new mails, especially large ones, because of index creation delays. A good LMTP implementation has its benefits, but many people have to do without it. -- Apostolis Papayanakis apap at ccf.auth.gr, 2310-998416 On Thu, 23 Dec 2004 dovecot-request at dovecot.org wrote:> Date: Thu, 23 Dec 2004 11:44:15 -0500 > From: Geo Carncross <geocar-dovecot at internetconnection.net> > Subject: Re: [Dovecot] delivery agent in 1.0? > To: Timo Sirainen <tss at iki.fi> > Cc: " Branko F. Gra?nar " <bfg at noviforum.si>, dovecot at dovecot.org > Message-ID: <1103820255.3898.126.camel at midget.intranet> > Content-Type: text/plain; charset=iso-8859-2 > > On Thu, 2004-12-23 at 17:52 +0200, Timo Sirainen wrote: > > On 23.12.2004, at 16:06, Branko F. Gra?nar wrote: > > > > > Is there any plan to include delivery agent in 1.x? > > > > I'll need to implement one in next few months, so yes. > > > > Hmm. This brings to my mind again that it would need Sieve, and mvmf > > might be a good base for it, but it's still not open source (Mark? :) > > It may be difficult to please everyone. I could have use for [some > elements of] a dovecot-lda but zero use for sieve... > > > > > I would be very happy, if there would be lmtp delivery agent included > > > with dovecot 1.x... This would make creating large mailsystem cluster > > > creation very simple + indexes would be always up2date. > > > > I'm not sure when I'll get around to implementing LMTP server. It's > > actually a bit annoying to implement because it needs to be able to > > deliver mail into multiple accounts, and if each one stores mails with > > different UID, it needs to either run as root (bad) or launch multiple > > processes and do IPC with them. > > How about a dovecot-inject tool that writes a message to whatever is > considered the $LOCAL user? It wouldn't have to do much but write the > message (safely) and update indexes -- something dovecot already has to > do. > > That way: > > * People who do delivery without LMTP baggage aren't treated as second- > class citizens. > > * Sieve implementations merely have to treat "keep" and "fileinto" as > subprocesses. > > * LMTP implementations can do the work they've already have to do > (regarding mapping email addresses to local users) and simply hook into > the sieve processor or the dovecot-inject, or anything else the > administrator/user likes. > > Formally, dovecot-inject would need the following information: > > 1. the envelope recipient ($RECIPIENT) > 2. the envelope sender/return-path/errors-to-address ($SENDER) > 3. the IMAP folder to write the message to (argv[1]) > > On systems with shared-uids, dovecot-inject would also need the concept > of the "localpart" of the address thats applicable. dovecot already > needs to know this in order to ACCESS the maildrop. ($LOCAL) > > This would keep things very easy to integrate without resorting to > shared libraries, "plugin system" nonsense, or forcing people to make > extra levels of indirection (lmtpclient) in order to benefit from pre- > login indexing... > > > > I suppose I'd implement it so that the actual LMTP talking would be > > done in a process very similar to imap/pop3-login processes, ie. > > completely unprivileged. Then it would tell master process to launch > > delivery agent processes to specific users, and those delivery agents > > then would get the mail from lmtp process via .. um. read-only shared > > memory + semaphores might be better than just copying the data over > > pipes/sockets? > > blah blah blah... > >