- dovecot - dovecot.org

[Dovecot] how to "hide" mailbox from the IMAP clients
by Kostik 16 Oct '09

16 Oct '09

Hello, everyone! Is it possible to "hide" mailbox from the IMAP clients, so as to prevent any user from subscribing to the some folders? My storages are "mbox maildir". For example, to hide the directory where the personal Sieve scripts are stored or etc. =kostik

4 19

Re: [Dovecot] Dovecot deliver with AD LDAP userdb [SOLVED]
by Mark Schaub 16 Oct '09

16 Oct '09

> Then there's something different what Dovecot and ldapsearch does. They > have the same dn, dnpass, neither uses tls, same base, deref, scope? > I figured it out, there certainly is something different! The AuthDatabase/LDAP documentation on the Dovecot Wiki says "When connecting to AD, use port 3268". Port 3268 is used for Global Catalog searching. By default the Active Directory Global Catalog wouldn't include attributes like otherMailbox, but would include mail and sn. The solution here would be to either use port 389 and search the domain like ldapsearch or to add the otherMailbox attribute (or any others I want to search on) to the global catalog. It might be worth updating the wiki to mention the reasoning behind using port 3268 and the implications it can cause. Thanks for the help!

2 2

[Dovecot] Sendmail and Dovecot Delivery to Virtual Users
by Philipp Hunold 16 Oct '09

16 Oct '09

I'm new to dovecot and sendmail and my server doesn't forward mails to 'dovecot deliver' at all. I was reading http://wiki.dovecot.org/LDA/Sendmail and this http://www.dovecot.org/list/dovecot/2009-June/040353.html from the mailling list but I could figure it out myself. I someone could point me into the right direction. I'm confused with the config for LDA. Basically what I want is every message coming in go to 'deliver' except if there's no dovecot user of course. I'm using 'local_procmail' feature right now, but I tried to comile the dovecot Mailer also. Anyway the dovecot 'deliver' itself works fine. But I cannot receiving emails or messages don't go anywhere. All the debugging I do with telnet right now. first I got 'User Unknown' errors in the maillog so I thought I just missing an alias/virtuser entry. So I create one and forward those to procmail. But now the messages don't go anywhere and the status is sent and I don't seem them in the /var/log/dovecot-deliver.log either, so they are stuck in the middle somewhere. Oct 16 14:26:26 sendmail[29939]: n9GIQQAh029939: to=|/usr/bin/procmail, ctladdr=<mail.address> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=31420, dsn=2.0.0, stat=Sent I don't seem to understand how the message get to dovecot's 'deliver' from sendmail. Some questions I have which may help to solve the problem myself: - how can I tell the LDA to lookup dovecot users too? to it would accept it? - do I need aliases therefore for each dovecot users? - What would the alias look like or is this the wrong way to do it? "test.user: |/usr/bin/procmail" ? - what's the procmail recipe which would work for maildir:/home/vmail/%u mail_location? My Sendmail configuration files: $ grep -v "^dnl" sendmail.mc divert(-1)dnl include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for linux')dnl OSTYPE(`linux')dnl define(`confDEF_USER_ID', ``8:12'')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST', `True')dnl define(`confDONT_PROBE_INTERFACES', `True')dnl define(`ALIAS_FILE', `/etc/aliases')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `goaway,noetrn')dnl define(`confDOUBLE_BOUNCE_ADDRESS', `')dnl define(`confCOPY_ERRORS_TO', `')dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confTO_IDENT', `0')dnl FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl FEATURE(`local_procmail', `/usr/libexec/dovecot/deliver', `deliver -f $g -d $u', `SPhnu9')dnl FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl FEATURE(`blacklist_recipients')dnl EXPOSED_USER(`root')dnl DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl FEATURE(`accept_unresolvable_domains')dnl LOCAL_DOMAIN(`mydomain.com')dnl MODIFY_MAILER_FLAGS(`LOCAL', `-f') MAILER(procmail)dnl # 1.2.4: /etc/dovecot.conf # OS: Linux 2.6.30.5-43.fc11.i586 i686 Fedora release 11 (Leonidas) ext4 log_path: /var/log/dovecot.log info_log_path: /var/log/dovecot-info.log protocols: imap imaps listen: localhost login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login login_greeting: Ciao. mail_uid: 501 mail_gid: 502 mail_location: Maildir:/home/vmail/maildir/%n mail_debug: yes lda: postmaster_address: postmaster(a)mydomain.com hostname: server.mydomain.com log_path: /var/log/dovecot-deliver-errors.log info_log_path: /var/log/dovecot-deliver.log auth default: user: dovecot-login verbose: yes debug: yes passdb: driver: passwd-file args: username_format=%n /etc/dovecot/passwd userdb: driver: static args: uid=vmail gid=vmail socket: type: listen master: path: /var/run/dovecot/auth-master mode: 384 user: vmail please tell me if you need more info. any help, hints and suggestions are welcome. regards. Philipp

1 0

[Dovecot] Sieve question
by CJ Keist 16 Oct '09

16 Oct '09

If there is a separate sieve mailing list let me know. But have question if someone else has done this or not. Right now I have web form people use to setup their vacation replies using Sieve (1.1.6). The form alows them to set what they want their reply address to be, whether to send the reply once, weekly or bi-weekly. I would like to setup another option to let them set the date in which to de-active the vacation replies automatically. Right now they have to remember to log back into the form to turn off the vacation reply. Has anyone set something like this up? -- C. J. Keist Email: cj.keist(a)colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness'

3 3

[Dovecot] Berkely DB authentication?
by Marc Perkel 16 Oct '09

16 Oct '09

Does Dovecot support berkeley DB authentication? I'm looking for something simple that is perhaps a single file for multiple domains and something the Exim can also read.

3 3

[Dovecot] Dovecot lock problem
by Simon Gao 16 Oct '09

16 Oct '09

On Tue, 2009-10-13 at 11:37 -0700, Simon Gao wrote: > We have a few users experiencing locking problem. When starting > Thunderbird, there is no new emails in Inbox. Dovecot createa a lock file > /var/spool/mail/<user>.lock. It never completes openning Inbox. If closing > the mail client, the open imap session does not get closed, nor the lock > file get deleted. >What is the process doing? Check with "strace -p <imap process pid>"? >How large is the user's mailbox? The size of inbox varies. Some is large, some are only a few hundred KB. If the mailbox is large, it may take time to re-generate index and put lock on inbox file until it's done. However, it should not for smaller mailbox file. Deleting index files did not help. The workaround is rename the mailbox file and copy it to ~/mail folder and let MTA re-create the mailbox. Then let mail client subscribes to the new temp mailbox. I will try strace next time. > Here are the errors in log: > > dovecot: Oct 13 11:18:35 Warning: IMAP(user1): Our dotlock file > /var/mail/user1.lock was deleted (kept it 88 secs) > dovecot: Oct 13 11:18:35 Error: IMAP(user1): file_dotlock_delete() > failed with mbox file /var/mail/user1: No such file or directory >I'd guess this is a huge mbox (or your disk I/O is very slow) and >Dovecot takes a long time trying to read it. mbox_very_dirty_syncs=yes >may be helpful. It occurred to mailbox large and small. It should not take very long to read a few hundred KB file.

2 2

[Dovecot] New backend
by Aspra Flavius Adrian 16 Oct '09

16 Oct '09

Hi I intend to write a new virtual backend for dovecot. Are there any hacking docs describing how the code is organized, eventually also important structs and how to hook myself into the system, or do I have to go the classical way? Thanks --Flavius

2 3

[Dovecot] Dovecot can't find users' sieve files
by Bartosz Fenski aka fEnIo 16 Oct '09

16 Oct '09

Hello. I asked for help on #dovecot but one suggestion I got was setting sieve variable explicitly but unfortunatelly that didn't help. I'm trying to set up sieve to be able to use vacation module. So in the lda section I put: mail_plugins = sieve And in plugins section: sieve = ~/.dovecot.sieve Then I put .dovecot.sieve file in the user's directory. This is what I get in Dovecot's log when trying to deliver to that mailbox: 2009-10-16 18:37:52 deliver(test(a)domain.pl): Error: sieve: stat((null)) failed: Bad address (using global script path in stead) 2009-10-16 18:37:52 deliver(test(a)domain.pl): Info: msgid=<20091016163757.GK19565(a)asdy.pl>: saved mail to INBOX Some infos about system: Dovecot 1.2.5 Debian squeeze/testing x86_64 ext3 (root)~#dovecot -n # 1.2.5: /etc/dovecot/dovecot.conf # OS: Linux 2.6.30-1-amd64 x86_64 Debian squeeze/sid ext3 log_path: /var/log/dovecot.log log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_privileged_group: mail mail_location: maildir:/home/vmail/%u mbox_write_locks: fcntl dotlock mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 lda: postmaster_address: postmaster(a)domain.pl mail_plugins: sieve log_path: /var/log/dovecot-deliver.log auth_socket_path: /var/run/dovecot/auth-master auth default: passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail plugin: sieve: ~/.dovecot.sieve (root)~# And dovecot-sql.conf: driver = pgsql connect = host=localhost dbname=postfix user=postfix password = xxxxxxxx password_query = \ SELECT local_part, password \ FROM mailbox WHERE local_part = '%n' AND active = 't' user_query = \ SELECT maildir, 5000 AS uid, 5000 gid \ FROM mailbox WHERE local_part = '%n' AND active = 't' Delivering works perfectly but I can't figure out why it's not able to find that .dovecot.sieve file: (root@germany)~#ls -al /home/vmail/test(a)domain.pl/.dovecot.sieve -rw-r--r-- 1 vmail vmail 314 2009-10-16 13:09 /home/vmail/test(a)domain.pl/.dovecot.sieve (root@germany)~# Any help would be very appreciated. regards fEnIo -- ,''`. Bartosz Fenski | mailto:fenio@debian.org | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://fenski.pl | xmpp:fenio@jabber.org | rlu:172001

1 1

[Dovecot] Better APPEND performance
by Mike Abbott 16 Oct '09

16 Oct '09

Moving a large number of messages into an IMAP folder on a dovecot server takes quite a long time. This is a popular operation for users migrating their stored messages from their old mail servers through a mail user agent, and it causes a poor first impression of dovecot. I'd like your help to speed this up. I have studied this problem in recent versions, including 1.1.[17-19] and 1.2.[4-6] but I'll focus on 1.2.6, using Maildir++. It seems to be caused by O(n^2) behavior in maintaining the UID list, where n is the number of messages. The client selects a folder then sends thousands of individual APPEND commands (no use of multiappend unfortunately). These cause dovecot to behave as follows: 1. For every other APPENDed message, dovecot appends the new UID to the list quickly. No problem here, this is fast. 2. For every other other APPENDed message, dovecot scans the entire UID list. This is an O(n) algorithm. Since it happens every n/2 times it causes O(n^2) behavior across n consecutive APPENDs. More specifically, 1. APPEND a message to a folder that already contains 30,000 messages. maildir_uidlist_refresh_fast_init() takes the fast path. 2. APPEND a second message to the same folder. maildir_uidlist_refresh_fast_init() takes the slow path: it populates the uidlist->files hash table with all the UIDs, checking for duplicates. At the end of the command maildir_uidlist_deinit() destroys the hash table. Note how this APPEND takes much longer than #1. 3. APPEND a third message to the same folder. Just like #1. 4. APPEND a fourth message to the same folder. Just like #2, and since #2 destroyed the hash, it has to do all that work over again. 5. And so on. What can be done to make maildir_uidlist_refresh_fast_init() choose the fast path more often?

3 6

[Dovecot] v2.0.alpha1 released
by Timo Sirainen 16 Oct '09

16 Oct '09

http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz.sig So here's the first alpha version of Dovecot v2.0. There are still a couple of things left to do, but in general it should work for most people. I started using it for my own mails a few days ago and it seems to work without errors. Largest changes since v1.2: * Global ACLs are now looked up using namespace prefixes. For example if you previously had INBOX. namespace prefix and a global ACL for "INBOX.Sent", it's now looked up from "INBOX.Sent" file instead of "Sent" as before. + Redesigned master process. It's now more modular and there is less code running as root. + Configuration supports now per-local/remote ip/network settings. + dsync utility does a two-way mailbox synchronization. + LMTP server and proxying. + Added mdbox (multi-dbox) mail storage backend. + doveadm utility can be used to do all kinds of administration functions. Old dovecotpw and *view utilities now exist in its subcommands. Some things left to do: - Do something about backwards compatibility with v1.x. Either make it read v1.x config files or provide some config conversion utility. - dsync still has some bugs - config process is a bit too slow. config handling in general could use some caching all around. no need to ask configuration for each login unless there are per-remote-ip settings. - some kind of an optional connection policy server could be useful. mainly to finally implement tcp-wrappers support. - mail_uid, mail_gid, mail_chroot settings don't really work now. I think this actually needs a bit larger change, which is probably a good idea in any case: After successfully authenticating, login process needs to get imap/pop3 process executed. Currently this is done by transferring the connection fd to master process, doing userdb lookup and then forking and execing the imap/pop3 process. The new behavior I'm thinking is that after auth, login process would connect to imap/pop3 unix socket in the login/ directory. That would cause master process to fork a new imap/pop3 process (running as root). Login process would send the necessary auth information via the unix socket, possibly transfer also the fd, and imap/pop3 would do the userdb lookup and then drop privileges. This change has some pros: - Master process will no longer temporarily hold some extra fds and use extra memory during auth lookups. If auth process is hanging these could cause problems. - Master process will no longer have any special auth handling code and I can remove type=auth-source and type=auth services. - Of course fixes the mail_* setting issue, because all of this is now done by imap/pop3 process, which knows about these settings. - Creating support for "multiple imap/pop3 post-login connections in a single process" should be pretty easy to implement with this. The imap/pop3 unix socket just needs to be listened by a new process in the middle that keeps track of what imap/pop3 processes exist and can redirect the new connections to those. But also some cons: - drop_priv_before_exec=yes no longer works, unless the uid/gid is hardcoded to the service {} block. - Each imap/pop3 process needs to do a connect() to auth server at startup, adding a bit to the latency.

7 21