[Dovecot] Re: delivery agent in 1.0?
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. Icould 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 thanits 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 todo without it.
-- Apostolis Papayanakis apap@ccf.auth.gr, 2310-998416
On Thu, 23 Dec 2004 dovecot-request@dovecot.org wrote:
Date: Thu, 23 Dec 2004 11:44:15 -0500 From: Geo Carncross <geocar-dovecot@internetconnection.net> Subject: Re: [Dovecot] delivery agent in 1.0? To: Timo Sirainen <tss@iki.fi> Cc: " Branko F. Gra?nar " <bfg@noviforum.si>, dovecot@dovecot.org Message-ID: <1103820255.3898.126.camel@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:
- the envelope recipient ($RECIPIENT)
- the envelope sender/return-path/errors-to-address ($SENDER)
- 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...
On Mon, 2005-01-10 at 00:36 +0200, Apostolos Papayanakis wrote:
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).
I'll try to get it done soon.
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.
So you're using mboxes? If nothing else than Dovecot is modifying mboxes (adding mail is fine), you could use:
mbox_very_dirty_syncs = yes
Then the mbox is re-read only when absolutely necessary (something else has modified the mbox and mails aren't where they're expected). I've been using it for a few months (or whenever it was I added that feature), works fine.
Thanks Timo,
Indeed in my case INBOXes are mbox format and are only accessed bydovecot and procmail. Procmail only appends new mails onto mboxes. So as you say, mbox_very_dirty_syncs will avoid full index rebuilding.
I eager to use dovecot 1.x stable and to migrate into indexedMaildir. Right now on production servers I use UW-IMAP, and I feel very uncomfortable about it. I have resorted to multi-way disk mirroring and stripping to handle the UW disk load, which causes average 30MB/second rates sustained throughout working hours, with frequent peaks of 80MB/second.
I use dovecot 0.99.12.1 for selected users, and it works ok, but Iknow it will not be developed further, so I don't intend to deploy it further.
Keep up the very good work!
Apostolis Papayanakis apap@ccf.auth.gr, 2310-998416
On Mon, 10 Jan 2005, Timo Sirainen wrote:
On Mon, 2005-01-10 at 00:36 +0200, Apostolos Papayanakis wrote:
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).
I'll try to get it done soon.
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.
So you're using mboxes? If nothing else than Dovecot is modifying mboxes (adding mail is fine), you could use:
mbox_very_dirty_syncs = yes
Then the mbox is re-read only when absolutely necessary (something else has modified the mbox and mails aren't where they're expected). I've been using it for a few months (or whenever it was I added that feature), works fine.
participants (2)
-
Apostolos Papayanakis
-
Timo Sirainen