- dovecot - dovecot.org

[Dovecot] Fatal: Unknown userdb type 'pgsql'
by felix.schwarz＠web.de 21 Jul '04

21 Jul '04

Hello, I'm trying to use postgres authentication with dovecot on a linux system running Fedora Core 2. Installation of dovecot was done by installing the rpm included in the fedora distribution ("yum install dovecot"). from /etc/dovecot.conf auth_userdb = pgsql /etc/dovecot-pgsql.conf auth_passdb = pgsql /etc/dovecot-pgsql.conf but the logs tell me: dovecot: Jul 21 19:28:39 Info: Dovecot starting up dovecot-auth: Jul 21 19:28:40 Fatal: Unknown userdb type 'pgsql' dovecot: Jul 21 19:28:40 Error: Auth process died too early - shutting down dovecot: Jul 21 19:28:40 Error: child 5229 (auth) returned error 89 imap-login: Jul 21 19:28:40 Fatal: fd_send(-1) failed: Broken pipe imap-login: Jul 21 19:28:40 Fatal: fd_send(-1) failed: Broken pipe I think that the fedora rpm was compiled without postgresql support. - Is the information given above sufficient for an educated guess? - Would that lead to the above error message? - What other errors may cause this behavior? - How can I check which authentification types are supported by my dovecot-auth? - Are there any other Fedora rpms compiled with postgres support available on the net? thank you for your help :-) -- Felix

3 3

RE: [Dovecot] Probably a bad idea but.....
by Mark Lidstone 21 Jul '04

21 Jul '04

Hi everyone, Just done some testing and thought I'd share the results. I've successfully moved a few test emails from a Mercury/32 Windows server to Maildirs. I created an IMAP folder for each user ".INBOX.Old\ Mail" and put the email in there. It's accessable via IMAP but does not show up as a new email when the user uses POP3 to collect their email - exactly what I was after (they're all using POP3 at the moment, but I will be pushing them to move to IMAP at a later date). I'm going to copy the rest of the email in one go overnight so if you don't get another email from me on here assume it worked. Thanks for the help Timo. Thanks, Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== == -----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi] Sent: 21 July 2004 13:58 To: Mark Lidstone Cc: dovecot(a)dovecot.org Subject: Re: [Dovecot] Probably a bad idea but..... On Wed, 2004-07-21 at 14:11, Mark Lidstone wrote: > Mercury stores mail in a similar way to Maildirs, different folders > with separate files for each mail, stored in plaintext RFC822 format. > How sensible would it be to copy the files over from the Mercury > server to users maildirs on a Linux server? > > The filenames are in a different format but I don't know if that would > cause a problem? You'll lose message flags, but as long as the filenames don't contain ':' characters you can just copy them.

1 0

Re: [Dovecot] 1.0.0-test28 Problem with INDEX
by Tim Southerwood 21 Jul '04

21 Jul '04

On Tue, 20 Jul 2004 20:35:04 +0300 Timo Sirainen <tss(a)iki.fi> wrote: > On Tue, 2004-07-20 at 19:13, Tim Southerwood wrote: > > default_mail_env = > > mbox:%h/IMAP/:INBOX=%h/.email:INDEX=/var/cache/dovecot/%n > > > > The INBOX indexes are being built correctly in /var/cache/dovecot, > > but all other indexes for folders are still being built in the > > user's home directory. > > > > I had it working once - but it seems fragile - almost as if the > > config parser is sensitive to context??? Sorry - seems vague, but I > > can't pin this down reliably. > > Have you set full_filesystem_access = yes? That's the only thing that > I can think of that might make it use different directory (and even > then only if you access the mboxes as "~/IMAP/box"). > > OK - I've been look at the code all day and sticking debug statements in. full_filesystem_access = yes will cause the indexes to stick with the mail files and not be based under INDEX=dir. But - using default_mail_env = mbox:%h/:INBOX=%h/.email:INDEX=/var/cache/dovecot/%n # Note lack of IMAP ^^^ (So clients can use ~/IMAP or ~/Mail - we have a # historic mixture) full_filesystem_access = no namespace private { separator = / prefix = hidden = no location = mbox:IMAP/ } namespace private { separator = / prefix = IMAP/ hidden = no location = mbox:IMAP/ } namespace private { separator = / prefix = ~/IMAP/ hidden = no location = mbox:IMAP/ } Will cause the indexes to also stick with the mail files, not use INDEX=dir Bit of a problem with NFS involved. I know I could use INDEX=MEMORY, but I'm worried about what will happen if the machine exhausts it's VM (not impossible with my site). I'm happy to play with this a bit longer if you could give me a hint: where is the path to the index file computed? Cheers Tim -- Tim J Southerwood

1 0

[Dovecot] Probably a bad idea but.....
by Mark Lidstone 21 Jul '04

21 Jul '04

Hi all, I've got a few users I'm trying to migrate from a Mercury Mail server to a dovecot IMAP/POP3 setup. I was hoping to use some sort of imap-copy type script to move email from the Mercury server to dovecot server, but the Mercury box is running so slow it's impossible. Mercury stores mail in a similar way to Maildirs, different folders with separate files for each mail, stored in plaintext RFC822 format. How sensible would it be to copy the files over from the Mercury server to users maildirs on a Linux server? The filenames are in a different format but I don't know if that would cause a problem? Any help gratefully appreciated, Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== ==

2 1

[Dovecot] Almost there.
by Tom Ray [Lists] 21 Jul '04

21 Jul '04

Hey Timo- I got everything working now that I can log in properly...but I'm have a permissions issue and I'm not sure how to set it..I've been playing with ownership and permissions and I'm still getting this imap(tom(a)testdomain.com): mkdir_parents(/var/spool/mail/indexes/testdomain.com/tom/.imap/INBOX) failed: Permission denied What's that permission/ownership in that folder supposed to be?

2 1

[Dovecot] imap support question
by Tom Allison 21 Jul '04

21 Jul '04

OK, I'm actually trying to write something which interacts with IMAP. I'm trying to run the FETCH command and it goes OK, but I'm wondering how I might be able to call both RFC822.SIZE and BODY[HEADERS.FIELDS(..) in the same call. Right now I'm only able to get this to work with two calls to the server. I was hoping to avoid making two calls. Any suggestions? (I realize it isn't exactly "on topic" for the mailing list, but I can't think of any list I'm on that's even close to the topic)

3 2

[Dovecot] Newbie question: configuration for virtual users
by Rory Campbell-Lange 21 Jul '04

21 Jul '04

Hi! I'm looking forward to deploying dovecot as an IMAP server. I did some research into the various options and it looks like dovecot is the right daemon for me. I'll be using it with Exim. I am running a few tens of users on my server, most of them small numbers of people part of a small company, e.g. example.com. At present I have exim delivering to mbox in each virtual user's mail folder. So, for chris, john and mandy @ example.com, I have /home/example/Mail/ chris john mandy All of the users in example.com run under the same uid and gid (example). I like to separate these 'virtual' users from the real system users for security reasons. I presently serve up these mboxes via teapop, which allows for per-domain configuration. I couldn't find a similar setup after a cursory read of the config file examples on the dovecot website. I'd like some advice on how to support different non-system users under dovecot, ideally storing mail in a similar configuration to above, except (presumably?) that the user files will be under each user name? Thus: /home/example/Mail/ chris/ john/ mandy/ I may use postgresql to store user configuration data if appropriate. Advice gratefully received. Rory -- Rory Campbell-Lange <rory(a)campbell-lange.net> <www.campbell-lange.net>

2 3

[Dovecot] 1.0.0-test28 Problem with INDEX
by Tim Southerwood 21 Jul '04

21 Jul '04

Hi Using this line in dovecot.conf (ignore linewrap) default_mail_env = mbox:%h/IMAP/:INBOX=%h/.email:INDEX=/var/cache/dovecot/%n The INBOX indexes are being built correctly in /var/cache/dovecot, but all other indexes for folders are still being built in the user's home directory. I had it working once - but it seems fragile - almost as if the config parser is sensitive to context??? Sorry - seems vague, but I can't pin this down reliably. Anyone else had problems? Cheers Tim -- Tim J Southerwood Senior Programmer CSG, Dept of Computing, Imperial College, London

2 2

[Dovecot] Idea to enhance migration from UW-Imap
by Klaus Steinberger 20 Jul '04

20 Jul '04

Hello, i want to migrate from UW-Imap to dovecot, but want to avoid changing clients (that would be really hard to do). All my users have their Mailboxes in ~/Mail. My idea would be now to strip off "Mail" from the imap commands, so that both a client which prepends "Mail" as well as one who doesn't would see the same mailboxes. Can somebody give me a hint where in the dovecot source I could do that stripping (at best some central function, so this stripping has to be done just one time). I would be glad to make the changes and then to contribute that change, I just need a hint where in the sources I will find the right place. Sincerly, Klaus Steinberger -- Klaus Steinberger Maier-Leibnitz Labor Phone: (+49 89)289 14287 Am Coulombwall 6, D-85748 Garching, Germany FAX: (+49 89)289 14280 EMail: Klaus.Steinberger(a)Physik.Uni-Muenchen.DE URL: http://www.physik.uni-muenchen.de/~k2/ In a world without Walls and Fences, who needs Windows and Gates

2 2

[Dovecot] 1.0-test29
by Timo Sirainen 20 Jul '04

20 Jul '04

http://dovecot.org/test/ Huh, I almost got stuck with this one. It's boring to do larger rewrites to things that already kind of work. This time it was rewriting how caching headers work. The old way was kind of ugly and it didn't really guarantee the order in which cached headers could be fetched. So there were a few theoretical problems that could have broken things. 0.99.10 didn't support caching headers at all, so it didn't have this problem. I think the new caching code is finally nearly finished. Just a few small things left and it's done. This release also fixes some other crashes and problems. I've been running it nearly an hour now without problems :)

1 0