[Dovecot] Re: delivery agent in 1.0?

[Apostolos Papayanakis]

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