Hi I noticed in a post that Timo might start work on a LDA Great! If so, here is something I would really like included. Support for PAM There is quite a lengthy reason behind this. In my organisation, user accounts are created on ldap. It is up to the services to create home directories whenever the user first uses them. For instance, Samba will do this the first time they connect to their windows home share. This achieved in other places using pam, using the pam_mkhomedir module. The MTA we run, Exim, is incapable of creating the home directory automatically, or using PAM for local delivery, thus we have the problem that when an account is created in the LDAP directory, it cannot receive email until the user first logs in through IMAP - Dovecot calls pam, which creates the home directory :-) Also attributing to this is the fact that exim is configured to deliver email into $home using maildir format rather than a mbox mail spool. We needed to do this because of the huge size of some of the inboxes of our users. This caused a severe amount of i/o blocking. So far, I have been unable to find a LDA capable of doing this. Since we migrated to dovecot, performance has improved ten-fold. I will give it a week then show you the graphs to prove it! Keep up the great work! Regards -- Chris Hills IT Services North East Worcestershire College
On 218, 08 05, 2004 at 12:08:49PM +0100, news.gmane.org wrote:> Hi > > I noticed in a post that Timo might start work on a LDA Great! If so, > here is something I would really like included.Where is this post ? I want to read it too :))> Support for PAMYeah, let's create long wishlist :) 1. Quota support, especially on maildir storage; 2. Sieve support. I can possibly help with this, as I already have homebrew Sieve enabled MDA using libsieve from GNU mailutils. It works, but only maildir is ssupported and it's a little kludgy. Best regards. -- Andrey Panin | Linux and UNIX system administrator pazke at donpac.ru | PGP key: wwwkeys.pgp.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20040806/0507ccce/attachment-0001.bin>
On 5.8.2004, at 14:08, news.gmane.org wrote:> Support for PAMI'm not sure how exactly this would work. LDA doesn't use any passwords, so it would have to make a PAM call with some dummy password. And that would create a two second delay with most PAM implementations.> There is quite a lengthy reason behind this. In my organisation, user > accounts are created on ldap. It is up to the services to create home > directories whenever the user first uses them. For instance, Samba > will do this the first time they connect to their windows home share. > This achieved in other places using pam, using the pam_mkhomedir > module.I think a better idea would be to just make the LDA create the home directory. -------------- 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/20040806/ed048610/attachment-0001.bin>
Timo Sirainen wrote: > On 5.8.2004, at 14:08, news.gmane.org wrote: > >> Support for PAM > > > I'm not sure how exactly this would work. LDA doesn't use any > passwords, so it would have to make a PAM call with some dummy > password. And that would create a two second delay with most PAM > implementations. Maybe I am all wrong here (you are all so clever on this list), but isn't PAM divided into 4 different areas exactly for the purpose of using only some of them? Password comparison is done in pam_auth (usually, but can be replaced with OTP or other authentication schemes). In Debian at least, you can add a module to the pam_session loop to mount something. Such mounting module is simply ignored if included in auth, account or password loops (as I understand it). As I understand Chris he requests support for the _relevant_ PAM loops, and you, Timo, say that the auth loop is irrelevant. - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er n?r: http://www.shibumi.org/eoti.htm
On Mon, Aug 09, 2004 at 02:07:27AM +0300, Timo Sirainen wrote:> On 7.8.2004, at 07:25, Mark E. Mallett wrote:[ I hope you don't mind me answering this back on the list; it seems like it's relevant. ]> > >That's probably just a result of my poor communications skills. I did > >include very brief LICENSE and FUTURE files with the sources, and those > >files probably led you to that conclusion. For clarification, I do > >intend that the program be open source, but I feel that there are some > >things that I should still finish up myself before foisting it off on > >any potential contributers. It's not a matter of "I don't want you to > >have it" -- it's more a matter of "I don't feel right burdening you > >with > >filling in holes just yet" (for the generic "you"). (That makes it > >sound like it's not usable: it's quite usable right now. There are > >just > >features still left to add.) > > > >Plus, as with many other packages and maintainers, I just want to > >control any official version. > > Well, doesn't that mean that it's currently not really open source? As > in I can't modify and re-distribute it (with possibly different name)?My current goal is to make it mature enough and good enough where people might actually want to do that -- as I say, by finishing up some of the things that are still undone. Also there are a couple of things that are hardwired to the environment here (particularly, the way that the IP addresses are extracted for DNSBL tests), that I felt that I should make more general before making it open. The latest sources are available online to anybody who wants them, for use in your own environment, for experimentation and trial, but not for redistribution; but indeed if there was some demand I would probably open it up sooner than later. So far nobody has been beating down the door for it (admittedly I haven't really mentioned it in very many places; I think only here and on the bsdi-users list). But yeah, the plan is to make it so that you can modify it and redistribute it. I don't have any kind of hard and fast position on when, though. I'm sure most anyone could convince me to open it up most any time, if there was good reason to do so. mm
Timo, a very simple save-only LDA would be enough for many configurations. Other full featured LDAs such as procmail could also use dovecot-LDA as the final delivering program. This would keep gigantic mboxes always indexed, and make access on them snappy always, especially on the important first access. However this should not take many programming resources away from releasing a robust, migration-ready v1.0. I am eager to migrate 25,000 users (~100GB), onto dovecot and then provide them more disk space, which now I dare not allow them. Keep up the excelent work! apap> Date: Mon, 9 Aug 2004 02:03:53 +0300 > From: Timo Sirainen <tss at iki.fi> > Subject: Re: [Dovecot] Dovecot Local Delivery Agent > To: Dovecot mailing list <dovecot at dovecot.org> > ... > Anyway, I'm still hoping someone else to do the LDA so I don't have to > worry about it.
news.gmane.org wrote:> Since we migrated to dovecot, performance has improved ten-fold. I will > give it a week then show you the graphs to prove it!As promised:- http://itservices.ne-worcs.ac.uk/images/dovecot-load.png The daily spikes are due to tape backups. Regards -- Chris Hills IT Services North East Worcestershire College