- dovecot - dovecot.org

[Dovecot] Dovecot Inactivity Problem
by vipin＠barc.gov.in 09 Sep '07

09 Sep '07

Hi, We are using dovecot version 1.0.3. We have dovecot-ldap configured to authenticate users using ldap database. We are facing the inactivity problem with dovecot. After some hrs of successful working, dovecot logs shows the connection inactive problem with pop3 & imap server, & it starts rejecting the connection requests from clients. The problem goes away once we restart dovecot. The problem occurs again & again after some random time. Please help us in solving this problem. The output of dovecot -n command is as follows: # 1.0.3: /usr/local/etc/dovecot.conf protocols: imap imaps pop3 pop3s listen(default): *:143 listen(imap): *:143 listen(pop3): *:110 ssl_disable: yes disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_max_processes_count: 256 login_max_connections: 512 mail_location: mbox:~/:INBOX=%h/mbox mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv auth default: passdb: driver: ldap args: /usr/local/etc/dovecot-ldap.conf userdb: driver: ldap args: /usr/local/etc/dovecot-ldap.conf Thanks & Regards Vipin Gupta Scientific Officer Computer Division BARC, Trombay Mumbai

2 1

[Dovecot] Dovecot problem
by Raphael Bittencourt S. Costa 09 Sep '07

09 Sep '07

Helo all, Yesterday dovecot began droping connections and there is nothing conclusive in the log file, just the messagens below: Sep 2 11:43:57 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.152.100.77, lip=10.0.3.1 Sep 2 11:44:02 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.204.69.20, lip=10.0.3.1 Sep 2 11:44:19 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.20.236.248, lip=10.0.3.1 Sep 2 11:44:21 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.83.2.206, lip=10.0.3.1 Sep 2 11:44:24 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.158.0.143, lip=10.0.3.1 Sep 2 11:44:25 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.52.200.131, lip=10.0.3.1 Sep 2 11:44:26 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.53.20.53, lip=10.0.3.1, TLS Sep 2 11:44:35 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.0.90.117, lip=10.0.3.1 Sep 2 11:44:41 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=189.33.173.226, lip=10.0.3.1 Sep 2 11:44:45 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.82.135.42, lip=10.0.3.1 Sep 2 11:45:03 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.19.218.250, lip=10.0.3.1 Sep 2 11:45:04 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.83.2.206, lip=10.0.3.1 Sep 2 11:45:05 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.81.250.119, lip=10.0.3.1 Sep 2 11:45:21 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.171.100.233, lip=10.0.3.1 Sep 2 11:45:23 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=64.233.182.131, lip=10.0.3.1 Sep 2 11:45:27 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.43.185.179, lip=10.0.3.1 Sep 2 11:45:40 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.161.155.35, lip=10.0.3.1 Sep 2 11:45:41 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.62.149.20, lip=10.0.3.1 Sep 2 11:45:43 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.83.43.154, lip=10.0.3.1 Sep 2 11:45:47 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=134.171.76.5, lip=10.0.3.1 Sep 2 11:45:49 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.92.248.84, lip=10.0.3.1 Sep 2 11:45:55 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.21.114.120, lip=10.0.3.1 Sep 2 11:45:57 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.229.107.85, lip=10.0.3.1 Sep 2 11:46:04 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.204.69.20, lip=10.0.3.1 Sep 2 11:46:04 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.53.83.146, lip=10.0.3.1 Sep 2 11:46:05 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.152.100.77, lip=10.0.3.1 Sep 2 11:46:35 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.95.95.108, lip=10.0.3.1 Sep 2 11:46:35 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.0.90.117, lip=10.0.3.1 Sep 2 11:46:35 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=200.159.87.122, lip=10.0.3.1 Sep 2 11:46:40 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=83.131.211.245, lip=10.0.3.1 Sep 2 11:46:41 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.6.61.147, lip=10.0.3.1 Sep 2 11:47:13 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.1.153.202, lip=10.0.3.1 Sep 2 11:47:38 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=189.0.252.144, lip=10.0.3.1 Sep 2 11:47:39 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.20.236.248, lip=10.0.3.1 Sep 2 11:47:47 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=134.171.76.5, lip=10.0.3.1 Sep 2 11:47:51 relay01 dovecot: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=201.12.103.67, lip=10.0.3.1 After restart, everything just back working. Any ideia? Raphael Costa

2 1

[Dovecot] shared mailbox subfolder permissions
by David Leuschner 09 Sep '07

09 Sep '07

Hi all, when I create a subfolder in a public mailbox the dovecot-shared file is copied for the newly created subfolder and all mails get the owner, group and permissions from the file. Unfortunately the cur, new and tmp folders only get the permissions from the file but owner and group are set according to the creator. This effectivly makes the folder private to the creator. Is this the intended behavior? Is it a bug that has already been fixed in a later version? I am using 1.0.rc29. An example follows. Thanks for your help! David As an example .foobar was created manually (maildirmake) and permissions were setup using the shell: uml public # ls -al . .foobar .: total 24 drwxrwx--- 6 root pub 4096 Aug 18 13:05 . drwxrwxr-x 3 root mail 4096 Aug 18 11:10 .. drwxrwx--- 5 root pub 4096 Aug 18 11:42 .foobar drwxrwx--- 2 root pub 4096 Aug 18 10:50 cur -rw-rw---- 1 root pub 0 Aug 18 11:40 dovecot-shared drwxrwx--- 2 root pub 4096 Aug 18 10:50 new drwxrwx--- 2 root pub 4096 Aug 18 10:50 tmp .foobar: total 20 drwxrwx--- 5 root pub 4096 Aug 18 11:42 . drwxrwx--- 6 root pub 4096 Aug 18 13:05 .. drwxrwx--- 2 root pub 4096 Aug 18 11:42 cur drwxrwx--- 2 root pub 4096 Aug 18 11:42 new drwxrwx--- 2 root pub 4096 Aug 18 11:42 tmp After creating a subfolder 'baz' with Thunderbird the group of .baz is the group from dovecot-shared but the contained new/cur/tmp directories have the users primary group (instead of pub). uml public # ls -al . .baz .: total 28 drwxrwx--- 7 root pub 4096 Aug 18 13:09 . drwxrwxr-x 3 root mail 4096 Aug 18 11:10 .. drwxrwx--- 5 dleuschner pub 4096 Aug 18 13:09 .baz drwxrwx--- 5 root pub 4096 Aug 18 11:42 .foobar drwxrwx--- 2 root pub 4096 Aug 18 10:50 cur -rw-rw---- 1 root pub 0 Aug 18 11:40 dovecot-shared drwxrwx--- 2 root pub 4096 Aug 18 10:50 new drwxrwx--- 2 root pub 4096 Aug 18 10:50 tmp .baz: total 20 drwxrwx--- 5 dleuschner pub 4096 Aug 18 13:09 . drwxrwx--- 7 root pub 4096 Aug 18 13:09 .. drwxrwx--- 2 dleuschner dleuschner 4096 Aug 18 13:09 cur -rw-rw---- 1 dleuschner pub 0 Aug 18 13:09 dovecot-shared drwxrwx--- 2 dleuschner dleuschner 4096 Aug 18 13:09 new drwxrwx--- 2 dleuschner dleuschner 4096 Aug 18 13:09 tmp Here's my configuration: listen: localhost ssl_listen: * ssl_ca_file: /root/ca/ca.crt ssl_cert_file: /root/ca/crt/uml.crt ssl_key_file: /root/ca/keys/uml.key ssl_verify_client_cert: yes verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login namespace: type: private separator: . prefix: Priv. location: maildir:~/.maildir:CONTROL=~/.maildir/ctrl/priv:INDEX=~/.maildir/idx/priv inbox: yes namespace: type: public separator: . prefix: Pub. location: maildir:/var/mail/public:CONTROL=~/.maildir/ctrl/pub:INDEX=~/.maildir/idx/pub auth default: passdb: driver: pam args: * userdb: driver: passwd socket: type: listen client: path: /var/run/dovecot/auth-client mode: 432 master: -- David Leuschner Meisenweg 7 79211 Denzlingen Tel. 07666/912466

2 1

[Dovecot] SSL connections frozen on Dovecot 1.0.0
by Thibault VINCENT 09 Sep '07

09 Sep '07

Hello, We are running Dovecot 1.0.0 (Debian Etch, Backports.org, OpenSSL) in a production environment and we experience sporadic SSL connection problems. At the moment, it's difficult to tell if the server goes back to normal operation after some time or if it can be reproduces at any time because we have to restart it as soon as we get Nagios alerts. Some tests with openssl s_client have shown difficulties to proceed the SSL handshake (hanging at different stages), or no response to IMAP commands. SSL client used: openssl s_client -host imap -port 993 - First case : s_client hangs on the first output "CONNECTED(00000003)" and there is no handshake at all; - Second case : like the first but the handshake starts after a few minutes; - Third case : the handshake goes fine but the "OK" server banner is never sent (no response to commands); - Fourth case : the greeting banner is received but dovecot will never answer. The configuration file is almost identical to the default and SSL certificate is not the autogenerated one. Log files do not show dying process. I've searched the ML archive for SSL issues but not found related bug. Does anyone use the Backport.org package of Dovecot ? Thank you :) -- Thibault VINCENT tibal(a)reloaded.fr thibault.vincent(a)reloaded.fr PGP Key : 0x4BA8A39B

2 3

[Dovecot] postfix + dovecot lda,
by Michael Moritz 09 Sep '07

09 Sep '07

I'm trying to replace procmail with deliver but I'm having problems with the group part of things. I keep getting: Aug 29 16:44:19 dingbat deliver(mimo): open(/var/mail/.temp.dingbat.3969.d1689935a308e0dd) failed: Permission denied Aug 29 16:44:19 dingbat deliver(mimo): file_lock_dotlock() failed with mbox file /var/mail/mimo: Permission denied My primary group is mimo and I think it's trying to use that. I changed it to mail and things work. But I do not want all my users to have a primary group mail. Is there a way I can force deliver to use group mail as group and ignore the per user gid? I tried chmod 6755 /usr/lib/dovecot/deliver but no change. This is on debian/etch, help appreciated.... mimo

3 4

[Dovecot] too many files opened
by Joshua, C.S. Chen 09 Sep '07

09 Sep '07

Hi folks, My institute's mail server was upgraded to RHEL5 with dovecot 1.0-2.1rc5 recently. And it uses PAM authentication which points to LDAP server. Now from time to time it gets Error like dovecot: Aug 29 09:23:59 Error: auth(default): pam(joshua,192.168.177.52): pipe() failed: Too many open files and users can not login. My config is like dovecot -n # /etc/dovecot.conf base_dir: /var/run/dovecot/ log_path: /var/log/dovecot info_log_path: /var/log/dovecot listen: * login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login login_greeting: ASIAA Dovecot ready. login_processes_count: 4 mail_location: mbox:/asiaa/home/%u/:/asiaa/home/%u/mail/:INBOX=/var/mail/%u:INDEX=/asiaa/home/%u/mail/dovecot_indexes mail_debug: yes mail_full_filesystem_access: yes mail_drop_priv_before_exec: yes mail_executable(default): /etc/dovecot_postlogin_beforeimap.sh mail_executable(imap): /etc/dovecot_postlogin_beforeimap.sh mail_executable(pop3): /etc/dovecot_postlogin_beforepop3.sh mail_process_size: 512 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): %08Xv%08Xu auth default: passdb: driver: pam userdb: driver: passwd Any suggestion or help is appreciated Cheers Joshua

3 3

Re: [Dovecot] Dovecot + Sieve
by Marcin Michal Jessa 09 Sep '07

09 Sep '07

> Steffen Kaiser wrote: >>>> Any idea how to fix that? >>> Second: >>> When you remove the compiled Sieve script, is it re-created by deliver? >>> >> I have the same problem with the same config myself. No evidence that >> the script is being compiled automatically. If I remove the >> "sieve=path" global setting from dovecot.conf, deliver complains about >> not finding a per-user sieve or home path - so I assume the sieve module >> is being activated. Is there a particular format for the global sieve >> parameter? Does the script file HAVE to be named ".dovecot.sieve"? >I've got the global script working. Global setting is there in >dovecot.conf. deliver should have write access to that directory, to save >compiled script. > >It's called .dovecot.sieve, but I don't think it's that important: > >require "fileinto"; > >if header :matches ["X-Spam-Flag"] [ > "YES" >] >{ >fileinto "INBOX.Spam"; >stop; >} > >Calling the folder INBOX.Spam is important, if it is to be delivered to >users' Spam folders. It doesn't work with '+' delimited address+extension >(I reported it in this list, but had no replies). Actually I managed to fix this setting global_script_path = /usr/local/etc/sieve/Junk instead of sieve_global_dir = The emails marked as spam were moved to correct directory which is Junk, as listed in user's subscriptions file and not INBOX.Junk. I also correcred my sieve file to say: require ["fileinto"]; # Move spam to Junk folder if header :contains ["X-DSPAM-Result"] "Spam" { fileinto "Junk"; # Stop here so that we do not reply on spams stop; } But now I can see following logs for some of the accounts. Any idea what that may be? This account is not above quota which is set to 51200000 (just to be sure). deliver(lists(a)yazzy.org): Sep 04 18:04:16 Info: sieve runtime error: Keep: Generic Error deliver(lists(a)yazzy.org): Sep 04 18:04:16 Error: sieve_execute_bytecode(/usr/local/etc/sieve/Junkc) failed deliver(lists(a)yazzy.org): Sep 04 18:04:16 Info: msgid=<200709042006.51319.flash(a)preferance.ru>: Rejected: Quota exceeded Some work fine: deliver(abc(a)def.com): Sep 04 19:08:34 Info: msgid=<s6dd58a7.055(a)xyz.abc.state.ga.us>: saved mail to Junk deliver(abc(a)def.org): Sep 04 19:13:37 Info: msgid=<9B1E9600-42CC-49E0-8CB8-AF826257EE1B(a)abc.no>: saved mail to INBOX Cheers, Marcin P.S Becouse of that error I sent the same message twice yesterday and did not receive any follow ups so I had to copy and paste this thread from the web archive.

8 16

[Dovecot] Don't let deliver create index files
by Martin Strand 09 Sep '07

09 Sep '07

For various reasons I want to use deliver with Postfix and Courier-IMAP, and it seems to work fine except for one thing: deliver creates some dovecot.* index files that Courier never uses (and I assume deliver doesn't need them) Is there a way to prevent that? Thanks, Martin

3 2

[Dovecot] Using NID_x500UniqueIdentifier as ssl_username_from_cert
by S. Wefel 09 Sep '07

09 Sep '07

Hi, please have a look at the attached patch for dovecot-1.0.3 These patch modifies ssl_proxy_get_peer_name() to use the NID_x500UniqueIdentifier as username instead of NID_commonName. The reason is, that the Common Name doesn't have to be unique for the whole mailserver. Example; in germany a lot of people got the first name "Andreas" and the last name "Schulz". Therefore a lot of certificates exists with subjects like this: C=DE,O=ABC,CN=Andreas Schulz/emailAddress=andreas.schulz(a)abc.de C=DE,O=DEF,CN=Andreas Schulz/emailAddress=andreas.schulz(a)def.de ... dovecot couldn't distinguish between these users. So we decide to use certificates with an X509v3 extension NID_x500UniqueIdentifier which allows to extend the subject by an unique ID, e.g. the unix-uid or a database unique key. The new certificates may look like this: C=DE,O=ABC,CN=Andreas Schulz/emailAddress=andreas.schulz(a)abc.de/x500UniqueIdentifier=user1 C=DE,O=DEF,CN=Andreas Schulz/emailAddress=andreas.schulz(a)def.de/x500UniqueIdentifier=user2 With the attached patch the user is taken from this extension and e.g. with userdb=ldap you can use the filter string user_filter = (&(objectClass=posixAccount)(uid=%u)) A good solution to use booth, the common name and the UniqueIdentifier is to extend settings like ssl_username_from_cert = no | yes | cn | uid where "yes" is similar to "cn". Regards, Sandro Wefel

2 1

[Dovecot] Server Timed Out: Outlook Express
by Jackie Hunt 09 Sep '07

09 Sep '07

Hi all, We just started running Dovecot this fall here on campus v 1.0. I've started getting some trouble reports from users. An Outlook Express users reported seeing the "Server has not responded in 60 seconds" messages. Waiting longer doesn't help, he has to stop/start Outlook Express to get connected again. Also have a Thunderbird user who is seeing that type of behavior first thing in the morning after being logged in all night. He has to stop/restart Thunderbird. Also, have had some reports of "disconnected" showing up on the Outlook2007 status bar. I've looked at the Dovecot log, and don't see any errors. I do see lots of "Disconnected", "Disconnected in IDLE" and "Disconnected: Logged Out". These last two seem normal, if I just see "Disconnected" is that a flag that we're losing connections abnormally? I know version 1.0.3 is out. I've looked at the changes, and the only one I can see that might be related to what we are seeing is the IDLE commmand fix. Was hoping for some advice on whether upgrading might resolve these issue. Any insight would be greatly appreciated. Jackie --- Jackie Hunt ACNS Voice: (970) 663-3789 Colorado State University FAX: (970) 491-1958 Fort Collins, CO 80523 Email: jackie.hunt(a)colostate.edu

3 2