[Dovecot] delivery agent in 1.0?
-----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?
-----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 358, 12 23, 2004 at 05:39:24PM +0100, "Branko F. Gra?nar" wrote:
-----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...
I tried to use this library this spring and is was quite terrible experience, like maze of segfaults all different. Parsers (both sieve and mail) were too fragile, long mail headers could easily eat all your core, memory corruptions here and there and constantly changing API ugly as all hell. After two months of horror i migrated to libsieve from GNU mailutils.
I don't know how many of these problems are fixed now... IMHO some of them were simply by design.
The only good thing about this pile of crap^H^H^Hode is that I learned how to use valgrind :)
Best regards.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
On Fri, 2004-12-24 at 09:24 +0300, Andrey Panin wrote:
libsieve is released under double license: http://libsieve.sourceforge.net/license.php
I tried to use this library this spring and is was quite terrible experience, like maze of segfaults all different. Parsers (both sieve and mail) were too fragile, long mail headers could easily eat all your core, memory corruptions here and there and constantly changing API ugly as all hell. After two months of horror i migrated to libsieve from GNU mailutils.
I don't know how many of these problems are fixed now... IMHO some of them were simply by design.
So, do you mean you used libsieve after all, or "from libsieve to GNU mailutils"? How good is mailutils' mail.local then?
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...
-- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
On Thu, 2004-12-23 at 11:44 -0500, 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.
Yes, this would be pretty simple to implement, a few hundred lines of code or so. I almost did it once but back then Dovecot couldn't update indexes directly while saving messages so there wasn't really any use for it.
But having such tool wouldn't exclude from having other LDAs or LMTP server. I'd distribute the Sieve-capable LDA in separate package anyway.
- 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.
I don't think there exists any LMTP servers which aren't highly integrated into some other IMAP server. Actually only LMTP server I know of is in Cyrus.
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])
Why not have them all in argv?
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)
That would probably be what is now in $MAIL / default_mail_env?
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...
Sure. I don't want to use LMTP myself either, but I can see why it would be useful for some people.
On Thu, 2004-12-23 at 19:05 +0200, Timo Sirainen wrote:
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])
Why not have them all in argv?
I suppose you could... However, some MTA's will already have it in an environment variable. Less copying...
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)
That would probably be what is now in $MAIL / default_mail_env?
Probably, but using $MAIL might be problematic if $MAIL was set up wrong by some kind of login/stuff.
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...
Sure. I don't want to use LMTP myself either, but I can see why it would be useful for some people.
I'm not saying it wouldn't be useful for some people- I just like the idea of preindexing, and I'm not going LMTP to do it. I also don't see why LMTP has to be integrated with the IMAP server... because the "cyrus" guys do it seems like an awful reason...
-- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
On Thu, 2004-12-23 at 13:27 -0500, Geo Carncross wrote:
I'm not saying it wouldn't be useful for some people- I just like the idea of preindexing, and I'm not going LMTP to do it. I also don't see why LMTP has to be integrated with the IMAP server... because the "cyrus" guys do it seems like an awful reason...
I don't think Dovecot's LMTP server could necessarily be called "integrated". I have other servers planned to run on top of Dovecot's master and auth processes which have nothing to do with email at all. It's just that Dovecot provides a lot of the needed functionality so it's a good idea to build on top of it.
The LMTP server might as well be distributed in completely separate package, but it probably takes max. 10kB or so of code, so I don't think anyone cares if it's just included in the main package.
Also I'm not aware of any existing standalone LMTP server implementations, so if I needed it I'd have to do it myself anyway.
Cyrus people do it mostly because it gives them much better performance since they can keep their berkeley DBs open all the time. I don't think Dovecot would get any extra performance from using LMTP. It's just a convenient way of transferring mails from one server to another.
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 Thu, December 23, 2004 12:38 pm, Mark E. Mallett said:
On Thu, Dec 23, 2004 at 05:52:12PM +0200, Timo Sirainen wrote:
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.
Well, first it would help if a person could determine what the terms *are* without downloading the source code. Putting the contents of LICENSE on the web site would be a good start.
Jim
Jim Trigg, Lord High Everything Else O- /"
\ / ASCII RIBBON CAMPAIGN
Hostmaster, Huie Kin family website X HELP CURE HTML MAIL
Verger, All Saints Church - Sharon Chapel / \
On Thu, Dec 23, 2004 at 12:55:17PM -0500, Jim Trigg wrote:
On Thu, December 23, 2004 12:38 pm, Mark E. Mallett said:
On Thu, Dec 23, 2004 at 05:52:12PM +0200, Timo Sirainen wrote:
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.
Well, first it would help if a person could determine what the terms *are* without downloading the source code. Putting the contents of LICENSE on the web site would be a good start.
Good point.
It comes back to that lazy thing again.
Plus, what do you say when you don't have anything to say? But yeah, a file that doesn't say much is probably better than the lack of one.
I've added the relevant files.
mm
On Thu, 2004-12-23 at 12:38 -0500, Mark E. Mallett wrote:
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.
Well, just pick either GPL or BSD? :)
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.
My problem is that I'd need to modify and redistribute it, which isn't allowed now. Except maybe as a patch? That's pretty inconvenient in any case (as it is with qmail).
"Mark E. Mallett" <mem@mv.mv.com> writes:
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
Some questions you might want to ask yourself before picking a license:
do you want to make the license "contagious", i. e. are derivative works required to be under an open-source license? (GPL for instance)
should the license state anything about patents?
a. should derivative works be required to bear a different name? b. is a statement that it is a modified work sufficient that names a new support address? c. do you want to require an advertising clause?
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.
qmail is dead, the author doesn't have interest in fixing the bugs (he's occasionally still active denying them, same for most of the other software he wrote, say djbdns), and the route "distribute original tarball, patch and a helper script" that net-qmail follows doesn't seem too popular. Not a big deal, there are good alternatives. Courier, Exim, Postfix, to name them in lexicographical order.
The Debian Free Software Guidelines and www.opensource.org and the 'picking a license' (not sure of the exact title) document from ibiblio.org/Linux should help you figuring out the popular licenses and a VERY rough overview of their differences.
HTH,
-- Matthias Andree (haven't yet looked at mdmv)
On Tue, Dec 28, 2004 at 05:02:18PM +0100, Matthias Andree wrote:
"Mark E. Mallett" <mem@mv.mv.com> writes:
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
Some questions you might want to ask yourself before picking a license:
<etc>
Thanks. Those are all good points that I am not unfamiliar with, although usually I will just put something like "here, use it if you can" with code. I talked about being too lazy and stuff, and while that's always true, mainly I just wanted to grow it some more before inflicting it on people, assuming that anyone wants to be so afflicted. And I did have a specific milestone capability in mind(1). It reached that a while ago, and the code has been out there and available for just about exactly a year now, so it's probably a good a time as any, especially while I'm thinking about it.
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.
qmail is dead, the author doesn't have interest in fixing the bugs (he's occasionally still active denying them, same for most of the other software he wrote, say djbdns), and the route "distribute original tarball, patch and a helper script" that net-qmail follows doesn't seem too popular.
While I agree with a lot of those points, I would say that the pronouncement of death is premature. At any rate that's a fray I don't want to get into here :-)
The Debian Free Software Guidelines and www.opensource.org and the 'picking a license' (not sure of the exact title) document from ibiblio.org/Linux should help you figuring out the popular licenses and a VERY rough overview of their differences.
Thanks. I was familiar with the major ones, including the new BSD license that I went with, but seeing some others was interesting.
The latest mvmf (http://www.mvmf.org/) has open source terms attached.
-mm-
(1) That milestone being the ability to use the scripting language to pick out IP address(es) from the mail message for use in the dnsbl constructs (as opposed to having to change code that did the hardwired extraction that probably only worked here).
--On Thursday, December 23, 2004 5:52 PM +0200 Timo Sirainen <tss@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?
On 23.12.2004, at 20:08, Kenneth Porter wrote:
--On Thursday, December 23, 2004 5:52 PM +0200 Timo Sirainen <tss@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?
The problem with procmail is its code. Once I spent an hour trying to figure out how a certain function in it was called. It only went through a few functions, but the code was unbelievably complex. I'd rather not want to ever look at it again.
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@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
participants (9)
-
"Branko F. Gračnar"
-
Andrey Panin
-
Curtis Maloney
-
Geo Carncross
-
Jim Trigg
-
Kenneth Porter
-
Mark E. Mallett
-
Matthias Andree
-
Timo Sirainen