February 2009 - dovecot

Re: [Dovecot] Disconnected Log messages I'd like to disable?
by dovecot＠corwyn.net 09 Feb '09

09 Feb '09

I understand what the log message means. I currently have dovecot logging flipped up about as high as I can have it set in about every way that I can. What I'd like to know is which logging setting can I lower to not see this message (or if there is one), and what OTHER things won't log if I decrease that logging setting. thx. rick At 08:43 AM 2/9/2009, Steffen Kaiser wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Mon, 9 Feb 2009, dovecot(a)corwyn.net wrote: > >>Feb 9 08:06:52 mailserver dovecot: IMAP(user(a)example.com): >>Disconnected: Logged out bytes=479/51185 > >Search the archive for a mail from Timo few times ago, it just means >that the user logges out (LOGOUT command). > >Bye, > >- -- Steffen Kaiser >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (GNU/Linux) > >iQEVAwUBSZAzIHWSIuGy1ktrAQKQDQf/S0zCmCuQ+xtJI0o3goUdDo0++yGXRyCp >fGdDKQ7YnOL1VOM1FnBjGJkhfYs/K6WuVFqQzqVrBjCoItsFWIvZCoeGWeHYPQf1 >6qRYngFSJLfdFDg9Ift5UvCnIS9W5jYv6otkJlddoH0SHeypSb9RZbPR20Ywf2da >whV4bB41W8ys/upUkaBd7+gKKcYcbSp+l3ZBXCrLnDbj7pCISnv2sENkTz2df1eE >wQSgpnbazmr9ePCx1cWDdvN5Wy9RN5KoGc+H0axtI7Uav5tkP7nVJ8GSmqBBH54r >nkvOrtmAjTMwp4MbYh6x2wejZJAY8lp72wQOeg3sJak32f3la0ZLgw== >=mLed >-----END PGP SIGNATURE-----

3 2

[Dovecot] Disconnected Log messages I'd like to disable?
by dovecot＠corwyn.net 09 Feb '09

09 Feb '09

I regularly get this message in my logs: Feb 9 08:03:59 mailserver dovecot: imap-login: Login: user=<user(a)example.com>, method=PLAIN, rip=24.213.158.249, lip=192.168.250.80, TLS Feb 9 08:04:49 mailserver dovecot: IMAP(user(a)example.com): Disconnected: Logged out bytes=189/468 Feb 9 08:06:09 mailserver dovecot: imap-login: Login: user=<user(a)example.com>, method=PLAIN, rip=24.213.158.249, lip=192.168.250.80, TLS Feb 9 08:06:52 mailserver dovecot: IMAP(user(a)example.com): Disconnected: Logged out bytes=479/51185 Feb 9 08:06:52 mailserver dovecot: IMAP(user(a)example.com): Disconnected: Logged out bytes=479/51185 (which I think is from my blackberry users) I'd like to not log Feb 9 08:06:52 mailserver dovecot: IMAP(user(a)example.com): Disconnected: Logged out bytes=479/51185 Suggestions? rick Rick Steeves http://www.sinister.net "The journey is the destination"

2 1

[Dovecot] v1.1.11 released
by Timo Sirainen 09 Feb '09

09 Feb '09

http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.11.tar.gz.sig Hopefully this v1.1 release will last a few months. - IMAP: PERMANENTFLAGS list didn't contain \*, causing some clients not to save keywords. - dbox: INTERNALDATE and save date was returned wrong for converted maildir files. - auth: Using "username" or "domain" passdb fields caused problems with cache and blocking passdbs in v1.1.8 .. v1.1.10. - userdb prefetch + blocking passdbs was broken with non-plaintext auth in v1.1.8 .. v1.1.10. - If mail_chroot is set, don't fail at startup in dump-capability.

10 16

[Dovecot] Maildir structure question
by Nicolas KOWALSKI 08 Feb '09

08 Feb '09

Hello, About the INBOX location when using maildir, in the wiki, http://wiki.dovecot.org/MailboxFormat/Maildir, I can read: " Directory Structure ~/Maildir/new, ~/Maildir/cur and ~/Maildir/tmp directories contain the messages for INBOX. The tmp directory is used during delivery, new messages arrive in new and read shall be moved to cur by the clients. " But in my Maildir, I see this: niko@petole:~$ ls -la Maildir/ total 144 drwxr-xr-x 35 niko niko 4096 2009-02-06 08:37 . drwxr-xr-x 25 niko niko 4096 2009-02-06 10:26 .. drwxr-xr-x 5 niko niko 4096 2009-02-06 09:16 .INBOX ... There are no 'cur', 'new' and 'tmp' directories in ~/Maildir, as written in the wiki, but instead this .INBOX directory which contains these 'cur', 'new' and 'tmp'. Is this expected ? Thanks. My configuration: petole:~# dovecot -n # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.28.3 i686 Debian 4.0 ssl_cert_file: /etc/ssl/certs/petole.demisel.net.pem ssl_key_file: /etc/ssl/private/petole.demisel.net.pem login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_location: maildir:~/Maildir namespace: type: private separator: / list: yes subscriptions: yes auth default: passdb: driver: pam userdb: driver: passwd socket: type: listen master: path: /var/run/dovecot/auth-master mode: 384 -- Nicolas

3 8

[Dovecot] Best Imap Transfer Tool?
by Neil 08 Feb '09

08 Feb '09

So I'm looking to do a migration of my IMAP mailboxes, and I'm looking for the best tool to use. I used to use the uw-mailutil tool, a while ago, but that was a bit coarse of a tool. More recently I've used imapsync, but that was giving me some errors. I've sort of tracked those down; but I was wondering if anyone else had any other recommendations...? Thanks.

2 2

[Dovecot] Migrating mail between servers
by Knute Johnson 07 Feb '09

07 Feb '09

I've currently got dovecot running on a Fedora server and I want to move all my mail to my new server running ubuntu. Both use mbox and I have IMAP working in both. Can I just copy the ~user/mail directory and /var/mail/user file and replace them in the new server? Thanks, -- Knute Johnson "The urge to save humanity is almost always a false front for the urge to rule." H.L. Mencken

3 2

[Dovecot] FreeBSD pam auth problems
by Dmitry Samersoff 07 Feb '09

07 Feb '09

I'm impressed by dovecto and try to upgrade my home system from wu-imapd running there for last 5 years to dovecot. It's straghtforward FreeBSD setup with ssl-only auth, inboxes in /var/mail and user mail under %h/Mail But I get some strange error: Fatal: userdb didn't return a home directory, but mail location used it (%h): %h/Mail:INBOX=/var/mail/%u Thank you in advance! -Dmitry mircat:dovecot#./sbin/dovecot -n # 1.1.10: /usr/local/dovecot/etc/dovecot.conf # OS: FreeBSD 6.2-RELEASE i386 base_dir: /var/run/dovecot log_path: /var/log/dovecot_main.log info_log_path: /var/log/dovecot_info.log listen: *:143 ssl_listen: *:993 disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/dovecot/libexec/dovecot/imap-login login_user: nobody login_chroot: no login_max_processes_count: 30 max_mail_processes: 30 first_valid_uid: 1 mail_uid: smmsp mail_gid: smmsp mail_location: mbox:%h/Mail:INBOX=/var/mail/%u mail_debug: yes mbox_lazy_writes: no auth default: failure_delay: 1 verbose: yes debug: yes worker_max_request_count: 1 passdb: driver: pam args: imap -- Dmitry Samersoff dms(a)samersoff.net, http://devnull.samersoff.net * There will come soft rains ...

2 4

[Dovecot] Info regarding conversion of mbox to maildir
by Scott Silva 06 Feb '09

06 Feb '09

When I finally decide to convert to maildir, will I have to set up namespaces during the conversion, or will dovecot figure out where everything is by itself? Should I set up deliver to go to maildir/ globally, or per user? I have considered using the convert plugin, if there are not a lot of negatives. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!

2 3

[Dovecot] Public namespace permissions documentation/questions
by Thomas Hummel 06 Feb '09

06 Feb '09

Hello Timo, In my trials to setup a shared namespace with dovecot-1.1.8/LDAP passdb/userdb (prefetch)/Maildir, I found out that : 1) ACL are mandatory (at least if the acl plugin is triggered in dovecot.conf) Am I correct ? I'm still not sure if we can do without ACL at all (only with unix permissions and system_user userdb extra field). 2) the system_user userdb extra field is supposed to be ...the logname of the user the secondary groups of whom we want to check ! i.e. if user foobar belongs to secondary groups foogid, zgid, wgid and doveshared uid=xxx(foobar) gid=yyy(foogid) groups=zzz(zgid),www(wgid),vvv(doveshared) and we dovecot to take them into account, we have to make the usedb return the system_user extra field with the value foobar. Seems obvious now and said this way, but looking at the wiki : "system_user: If this is given, the user's groups are read from /etc/group (or wherever NSS is configured to taken them from)." I thought 'system_user' was a flag (a boolean) which, when triggered made dovecot look for the secondaries group of the user (user whose name is already known). a) am I correct ? b) why isn't system_user such a boolean ? Is there a case where we'd want system_user to be different than the user dovecot runs as at the moment the check takes place ? 3) same idea with acl_groups : since this extra_field holds a list of groups for the ACL plugin, why not rely on the native unix groups of the system the user belong to ? Thanks (and sorry for the 2 previous threads where I was blindly confused by the system_user thing). -- Thomas Hummel | Institut Pasteur <hummel(a)pasteur.fr> | Pôle informatique - systèmes et réseau

2 1

[Dovecot] dovecot-shared file
by Thomas Hummel 06 Feb '09

06 Feb '09

Hello Timo, About the dovecot-shared file, the wiki says : "Unless you're using a single UID for all the users, you'll need to have a dovecot-shared file in each shared maildir. The group and the file permissions for new files inside the maildir are taken from the dovecot-shared file." but says the following too : "With Maildir dovecot-shared file controls if the \Seen flags are shared or private. If you don't have the file, they're shared." The question is "does it make sense (or is it even possible) not to have the file ?". Why would one not have the file and how would it work then ? By relying on the set-gid bit and umask ? Finally, the wiki says : "If you do have the file, the \Seen flag state is stored only in the user's index files. By making each user have their own private index files, you can make the \Seen flag private for the users." So, my undersanding is that : 1) you have the file 1.a) if INDEX points to the same place, flags are shared but are lost if indexes are lost 1.b) if INDEX points to some user dependant place, flags are private but are lost if indexes are lost 2) you don't have the file flags are shared, whatever INDEX points to and, since they're stored in filename, survive indexes lost. but does shared-mailboxes even work if we don't have that file ? maybe only if the set-gid bit and umask does what the file would have done ? So maybe, if you want to share flags, 2) is safer dans if you want them private, 1.b) is the only choice ? thanks -- Thomas Hummel | Institut Pasteur <hummel(a)pasteur.fr> | Pôle informatique - systèmes et réseau

2 1