- dovecot - dovecot.org

[Dovecot] quota usage
by Papp Tamás 18 Mar '10

18 Mar '10

hi All! Dovecot's version is 1.2.11-0~auto+0 from http://xi.rename-it.nl/debian/ . dovecot.conf: dict { quota = mysql:/data/apps/dovecot/dict-sql.conf #expire = db:/var/lib/dovecot/expire.db } /data/apps/dovecot/dict-sql.conf: connect = host=127.0.0.1 dbname=db user=user password=pw map { pattern = priv/quota/storage table = quota username_field = username value_field = bytes } map { pattern = priv/quota/messages table = quota username_field = username value_field = messages } The problem is that the mailbox is almost empty: $ du -sh . 228K . But the quota usage show something else: mysql> select bytes,messages from quota where username='<user>'; +-----------+----------+ | bytes | messages | +-----------+----------+ | 217699358 | 987 | +-----------+----------+ What could be a problem, how can I fix this? Thank you very much, tamas

2 1

[Dovecot] .mailboxlist location
by Dave Brenner 18 Mar '10

18 Mar '10

Greetings. On our 1.2.9 setup, we are finding that .mailboxlist (we recompiled to use this name rather than .subscriptions) ends up in the user's ~/mail folder. We'd like this file to be stored in ~/ instead. Is this possible without changing namespaces (for UW compatibility) and/or userdb mail location? Thanks! -- Dave Brenner - david(a)toledotel.com The Toledo Telephone Company, Inc.

2 4

[Dovecot] v1.2.11 released
by Timo Sirainen 18 Mar '10

18 Mar '10

http://dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz http://dovecot.org/releases/1.2/dovecot-1.2.11.tar.gz.sig mbox users really should upgrade, because by sending a message with a huge header you could basically cause a DoS (this problem exists only with v1.2.x, not with v1.0 or v1.1). - mbox: Message header reading was unnecessarily slow. Fetching a huge header could have resulted in Dovecot eating a lot of CPU. Also searching messages was much slower than necessary. - mbox, dbox, cydir: Mail root directory was created with 0770 permissions, instead of 0700. - maildir: Reading uidlist could have ended up in an infinite loop. - IMAP IDLE: v1.2.7+ caused extra load by checking changes every 0.5 seconds after a change had occurred in mailbox

2 2

Re: [Dovecot] I stream read - stale NFS file handle (reboot of server)
by Damon Atkins 18 Mar '10

18 Mar '10

In the old days NFS Shared Path had a static handle (ie a number), normal based on some number pulled out of the file system/inode. To fix (well work around) a security issue, for about 10+ years now, when a NFS server reboots, it generates a new random handle for the NFS Share. (sever may generate a new random handle per mount request) The NFS Stale Handle happens when the client is still using the old NFS handle, the only fix is a remount Some NFSv3 server let you fix the handle id for NFS share so it does not change over reboots. (this is how NFS clustering works, sometimes you need to install cluster software if the exportfs/share command does not let you hard code the fsid by hand. The other option is to use NFSv4 which is design to handle reboots by servers.

4 6

[Dovecot] dovecot 2.0beta3 installation
by Renaud Allard 17 Mar '10

17 Mar '10

Hello, I tried to install dovecot 2.0 beta3 and deliver seems to look for its config file in unusual places. In my exim logs, I get: 010-03-17 13:39:24 [31257] 1NrsWt-0004T0-1K <email(a)example.com>: dovecot_delivery transport output: lda: Fatal: User lookup failed: net_connect_unix(/opt/dovecot/etc/dovecot/dovecot.conf) failed: No such file or directory 2010-03-17 13:39:24 [31257] 1NrsWt-0004T0-1K == email(a)example.com (email(a)example.com) <email(a)example.com> R=local_user T=dovecot_delivery defer (0): Child process of dovecot_delivery transport returned 75 (could mean temporary error) from command: /opt/dovecot/libexec/dovecot/deliver Dovecot have been started with the following command: /opt/dovecot/sbin/dovecot -F -c /etc/dovecot/dovecot2.conf Furthermore, it has been compiled with: --prefix=/opt/dovecot --sysconfdir=/etc I don't see why it searches for /opt/dovecot/etc/dovecot/dovecot.conf Also, I didn't really find out how to convert the v1.2 config snippet: auth default { mechanisms = digest-md5 cram-md5 ntlm login plain passdb passwd-file { args = /etc/cram.pwd } userdb passwd { } userdb passwd-file { args = /etc/passwd } socket listen { client { path = /var/run/dovecot/auth-client mode = 0666 } } user = exim } I tried the following, but it does not seem to work as I get an authentication socket protocol error service auth { unix_listener /var/run/dovecot/auth-client { mode = 0666 } } Thanks for you help

2 6

[Dovecot] Testing EXTERNAL AUTHENTICATION
by Stephen Feyrer 17 Mar '10

17 Mar '10

Hi. I'm trying to test EXTERNAL AUTHENTICATION in Dovecot. To do this I first configured Thunderbird and Opera to use my server, neither of them were successful. As a result I contacted both organisations to enquire if they supported EXTERNAL AUTHENTICATION in their products. Thunderbird responded and said yes. However, on closer inspection my contact at Thunderbird identified that support for EXTERNAL AUTHENTICATION was poor at best and then only in SMTP. From that point on, my contact has been trying to implement support in Thunderbird. I've also try to test using openssl s_client which is detailed below. As far as I can tell my problems appear after the authentication. I don't know what the problem is only that there is one. [~] # dovecot -n # 1.2.10: /opt/etc/dovecot/dovecot.conf # OS: Linux 2.6.12.6-arm1 armv5tejl ext3 base_dir: /opt/var/run/dovecot/ log_path: /opt/var/log/dovecot/messages info_log_path: /opt/var/log/dovecot/info protocols: imaps listen: [::] ssl_ca_file: /opt/etc/domain.ca/cacrl.pem ssl_cert_file: /opt/etc/domain.ca/newcerts/mail.cer ssl_key_file: /opt/etc/domain.ca/private/mail.key ssl_cipher_list: ALL:!LOW:!SSLv2 ssl_verify_client_cert: yes verbose_ssl: yes login_dir: /opt/var/run/dovecot//login login_executable: /opt/libexec/dovecot/imap-login login_process_size: 32 mail_location: dbox:/share/MD0_DATA/mail/%u mail_debug: yes dbox_rotate_days: 0 imap_id_send: * imap_id_log: * lda: postmaster_address: postmaster(a)ksudra.net auth default: mechanisms: EXTERNAL realms: ksudra.net default_realm: ksudra.net user: admin verbose: yes debug: yes ssl_require_client_cert: yes ssl_username_from_cert: yes passdb: driver: passwd-file args: /opt/etc/dovecot/passwd userdb: driver: passwd [~] # openssl s_client -cert Stephen.pem -connect 10.1.1.245:993 <-- snip --> SSL handshake has read 4460 bytes and written 2451 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 4096 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: [...] Session-ID-ctx: Master-Key: [...] Key-Arg : None Krb5 Principal: None Start Time: 1268756439 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=EXTERNAL] Dovecot ready. 01 AUTHENTICATE EXTERNAL + 01 list "" * 01 NO [ALERT] Invalid base64 data in continued response 01 select inbox 01 BAD Error in IMAP command received by server. 02 select inbox 02 BAD Error in IMAP command received by server. DONE [~] # tail -f /opt/var/log/dovecot/info Mar 16 16:51:14 auth(default): Info: new auth connection: pid=9176 Mar 16 16:51:16 imap-login: Info: Valid certificate: /O=ksudra.net/OU=Ksudra CA/emailAddress=certs(a)ksudra.net/L=Wilmslow/ST=Cheshire/C=GB/CN=ksudra.net Mar 16 16:51:16 imap-login: Info: Valid certificate: /C=GB/ST=Cheshire/O=ksudra.net/OU=Stephen Feyrer/CN=Stephen Mar 16 16:52:06 auth(default): Info: client in: AUTH 1 EXTERNAL service=imap secured valid-client-cert cert_username=Stephen lip=10.1.1.245 rip=10.1.1.4 lport=993 rport=45379 Mar 16 16:52:06 auth(default): Info: client out: CONT 1 Mar 16 16:52:42 imap-login: Info: Valid certificate: /O=ksudra.net/OU=Ksudra CA/emailAddress=certs(a)ksudra.net/L=Wilmslow/ST=Cheshire/C=GB/CN=ksudra.net Mar 16 16:52:42 imap-login: Info: Valid certificate: /C=GB/ST=Cheshire/O=ksudra.net/OU=Stephen Feyrer/CN=Stephen Mar 16 16:52:42 auth(default): Info: client in: AUTH 1 EXTERNAL service=imap secured valid-client-cert cert_username=Stephen lip=10.1.1.245 rip=10.1.1.4 lport=993 rport=45381 Mar 16 16:52:42 auth(default): Info: client out: CONT 1 Mar 16 16:52:42 auth(default): Info: client in: CONT<hidden> Mar 16 16:52:42 auth(default): Info: EXTERNAL(Stephen,10.1.1.4): Invalid base64 data in continued response Mar 16 16:52:42 auth(default): Info: client out: FAIL 1 reason=Invalid base64 data in continued response Mar 16 16:52:42 auth(default): Info: new auth connection: pid=9182 Mar 16 16:52:45 auth(default): Info: client in: CONT<hidden> Mar 16 16:52:45 auth(default): Info: EXTERNAL(Stephen,10.1.1.4): Invalid base64 data in continued response Mar 16 16:52:45 auth(default): Info: client out: FAIL 1 reason=Invalid base64 data in continued response Mar 16 16:52:47 imap-login: Info: Aborted login (cert required, client didn't start TLS): method=EXTERNAL, rip=10.1.1.4, lip=10.1.1.245, TLS Mar 16 16:54:36 imap-login: Info: Valid certificate: /C=GB/ST=Cheshire/O=ksudra.net/OU=Stephen Feyrer/CN=Stephen Mar 16 16:54:36 auth(default): Info: new auth connection: pid=9188 Mar 16 16:54:37 auth(default): Info: client in: AUTH 1 EXTERNAL service=imap secured valid-client-cert cert_username=Stephen lip=10.1.1.245 rip=10.1.1.4 lport=993 rport=49113 Mar 16 16:54:37 auth(default): Info: client out: CONT 1 Mar 16 16:54:37 auth(default): Info: client in: CONT<hidden> Mar 16 16:54:37 auth(default): Info: EXTERNAL(Stephen,10.1.1.4): Invalid base64 data in continued response Mar 16 16:54:37 auth(default): Info: client out: FAIL 1 reason=Invalid base64 data in continued response Mar 16 16:54:42 imap-login: Info: Aborted login (cert required, client didn't start TLS): method=EXTERNAL, rip=10.1.1.4, lip=10.1.1.245, TLS Mar 16 16:54:49 imap-login: Info: Valid certificate: /O=ksudra.net/OU=Ksudra CA/emailAddress=certs(a)ksudra.net/L=Wilmslow/ST=Cheshire/C=GB/CN=ksudra.net Mar 16 16:54:49 imap-login: Info: Valid certificate: /C=GB/ST=Cheshire/O=ksudra.net/OU=Stephen Feyrer/CN=Stephen -- kind regards Stephen Feyrer.

3 12

[Dovecot] sieve fileinto rule (pigeonhole)
by Oliver Eales 17 Mar '10

17 Mar '10

Hello, i discovered that when a sieve rule "fileinto drawer;" tries to deliver a mail into a non existent drawer, the drawer gets created. This is neat, but is there also a way to automatically subcribe to the created folder ? Regards, Oliver Eales

2 4

[Dovecot] qmail-secretary plugin for dovecot deliver
by Rajkumar S 17 Mar '10

17 Mar '10

Hi, I have been using qmail-ldap for quite some time and now moved to postfix/dovecot. One feature that I miss is that provided by qmail-secretary. qmail-secretary basically is a mail list manager with following features: 1 no limit, just explode to all members 2 members only, as the name says; only members are allowed (based on envelope sender, so not very secure, everybody can fake that) 3 sender confirm, sender has to confirm submission and return address like DJBs qmail-secretary 4 moderated, moderator(s) have to accept every message; there are DN and RFC822 moderators All configuration (name, members, moderated etc...) are taken from LDAP. I had gone through the code and from what I understand for each 4 delivery types it works as follows: 1. Just deliver to all recipients (say, inject it via sendmail). 2. verify if envelope sender is in allowed list and proceed as above. 3. 1. create a random hash 2. save the mail in new/ with hash as filename 3. create a new mail with listname-confirm-hash(a)domain.com and send 4. If that mail comes back, deliver the mail to all recipients. 4. 1. as above but using listname-approve-hash and list-name-reject-hash 2. move the msg to cur/ 3. if appropriate reply comes retrieve the mail from cur/ and send to all recipient. qmail-secretary is invoked by qmail-local and thus this is a nice candidate for a deliver plugin. Before I start coding I just want to check if there is any gotchas that I am missing? I assume all these operations can be performed as a deliver plugin and that deliver plugin is the correct place for such functionality. It goes without saying that I would be contributing this plugin back to dovecot. with regards, raj

4 9

Re: [Dovecot] [xmail] XMail + Dovecot
by Sabahattin Gucukoglu 17 Mar '10

17 Mar '10

What, exactly, is the problem? How do you want Dovecot and XMail to work together? I am setting up Dovecot to read from standard Maildirs in user home directories, because I am using a separate delivery agent (TMDA but would work for maildrop, Dovecot's deliver program and others) to deliver mails using mailproc.tab. So, even while XMail runs as root, Dovecot need not and there is no problem getting it to work just like with other MTAs. XMail can't help with delivery to Maildir because it runs as root, and unless you mess about with packet filters to non-root it you'll still end up using for instance XACLs to allow Dovecot to read the mails. For authentication of XMail to Dovecot you would have to write external authentication helpers that use Dovecot's protocol. Or, you can use checkpassword or PAM-POP3 or something else to try getting Dovecot to authenticate against the active XMail list of users. Or you can just do what I do, maintain two databases and keep them in sync. Cheers, Sabahattin

1 0

[Dovecot] Design: Asynchronous I/O for single/multi-dbox
by Timo Sirainen 17 Mar '10

17 Mar '10

The long term plan is to get all of Dovecot disk I/O asynchronous. The first step to that direction would be to make dbox/mdbox I/O asynchronous. This might also allow mbox/maildir to become partially asynchronous. http://www.dovecot.org/list/dovecot/2009-December/045481.html already started describing how the lib-storage API could be changed to support high-latency storages. Adding support for all of the paralellism would be nice, but probably not necessary as the first step. Then again, the API changes are necessary, so the parallelism optimizations probably aren't a huge task on top of that. Besides the API changes described in the above link, another change that's necessary is to add mail_get_nonblocking_stream(). The returned stream can return EAGAIN whenever it would need to block. Whenever sending message data to client, this stream would have to be used. It would also be used internally by all of message parsing/searching code. Luckily all of that already supports nonblocking input or can be easily modified to support it. Below are some thoughts how to go forward with this. I originally thought about writing a more specific plan, but I think this is good enough now to start coding. The target Dovecot version is v2.1, not v2.0. Filesystem API ============== The idea is to first abstract out all POSIX filesystem accessing in dbox/mdbox code. Non-blocking I/O works pretty nicely for socket I/O, so I thought I'd use a similar API for disk I/O as well: handle = open(path, mode) - this function can't fail. it's executed asynchronously. - mode=read-only: no writing to file - mode=append: appending to file is allowed handle = create(path, mode, permissions) - this function can't fail. it's executed asynchronously. - mode=fail-if-exists: commit() fails if file already exists - mode=replace-if-exists: commit() replaces file if it already exists - permissions: i'm not entirely sure how this works yet. but it should contain mode and gid in some format set_input_callback(handle, callback, context) set_output_callback(handle, callback, context) - call the callback when more data can be read/written ret = pread(handle, buf, size, offset) - just like pread(), but can fail with EAGAIN if there are no bytes already buffered. so the idea is that the backend implementation would buffer/readahead data, which would be returned by this call. this would require memcpy()ing all data, but it might get too complex/fragile if it was asynchronously written to given buffer. ret = write(handle, buf, size) - append data to given file and return how many bytes were actually added to write buffer. works in a similar way than writing to socket. data can only be appended to files, there is no support for overwriting data. - no writes will be visible to reads until commit() is called ret = commit(handle, [filename]) - commit all previous writes to disk. either returns success/EAGAIN. - if filename is given and a new file is being created, the filename is changed to the given one instead of using the original path's filename. this is needed because e.g. mdbox saving can write many temp files in a single transaction and only at commit stage it locks the index files and knows what the filenames will be. rollback(handle) - rollback all previous writes. close(handle) - if file was created and not committed, the temp file will be deleted - does implicit rollback ret = try_lock(handle) - this isn't an asynchronous operation! it assumes that locking state is kept in memory, so that the operation will be fast. if backend doesn't support locking or it's slow, single-dbox should be used (instead of multi-dbox), because it doesn't need locking. - returns success or "already locked" - only exclusive locking is possible Async IO streams ================ Async input streams are created with FS API handle, so it's possible to start reading from them before the file has even been open()ed. The callers must be aware of this and realize that read() can fail with ENOENT, etc. Async input streams' read() would work exactly as file_istream works for non-blocking sockets: It would return data that is already buffered in memory. If there's nothing, it returns EAGAIN. The FS API's set_input_callback() can be used to set a callback function that is called whenever there's more data available in the buffer. Async output streams also work the same as non-blocking file_ostreams: write() returns the number of bytes added to buffer. When buffer becomes full, it starts returning EAGAIN. The ostream handles flushing internally the same way as file_ostreams does, although instead of using io_add(IO_WRITE) it uses FS API's set_output_callback(). If callers need to know when more data can be written or when all of the data has been written, it can override the ostream's flush_callback, just like with file_ostreams. Async IO for FS API backend =========================== So now that all of the APIs have been designed, all that's needed to do is to write a simple FS API implementation using kernel's async IO API, right? Wrong. There is no usable async IO API in Linux, and probably nowhere else either: * POSIX AIO isn't supported by Linux kernel. And even if it was, it only supports async reads/writes, not async open(). * Linux kernel has its own native AIO implementation! ..But it only works with direct IO, which makes it pretty much useless for almost everyone. There have been many different attempts to get buffered AIO support to Linux, but all of them have failed. So for now the only practical way is to implement it with threads. There are several libraries that could make this easier.. But all of them enable (and require) full thread safety for libc calls. I don't really like that. Dovecot isn't using threads, I shouldn't pay the penalty of using extra locking when it's really not necessary. So I was thinking about doing the async IO in two ways: 1) For Linux/x86/x86-64 (and maybe others) implement a version that creates threads with clone() and uses lockless queues for communicating between the async io worker threads. The threads won't use malloc() or any other unsafe calls, so this should be pretty nice. 2) Fallback version that uses pthreads with mutexes. Is 2) going to be noticeably slower than 1)? Probably not.. In both cases there is also the problem of how many worker threads to create. I've really no idea, kernel would be so much better in deciding that.. I guess that also depends on how many processes Dovecot is configured to run on (and how busy they are at the moment). Maybe it could be just a globally configurable number of threads/process, defaulting to something like 10. dbox changes ============ Most of the dbox code shouldn't be too difficult to change to using the FS API. The one exception is writing messages. Currently the format looks like: <dbox header magic (2 bytes)> <dbox message header, which contains message size><lf> <message> <dbox metadata magic (2 bytes)><lf> <dbox metadata> <lf> The problem is that the message size isn't always known before the message is written. So currently the code just pwrite()s the size afterwards, but this is no longer possible with the new FS API. One possibility would be to buffer the message in memory, but that could waste a lot of memory since messages can be large. So the only good solution is to change the dbox file format to contain the message size after the message. At the same time the dbox format could be cleaned up from old broken ideas as well. The reading code could support the old version format as well, because reading isn't a problem. The new dbox format could look like: <dbox header magic (2 bytes)> <dbox unique separator (random 16 bytes or so)><lf> <message> <dbox metadata magic (2 bytes)> <dbox unique separator, same as above><message size><lf> <dbox metadata, last item being metadata size> <lf> The unique separator exists there primarily for fixing corrupted dbox storage, so it can (quite) reliably recognize where a message ends. Multi-dbox's indexes contain already the message offset + size of (message+metadata), i.e. offset+size = offset of next message. The size is primarily used to figure out if more data can be appended to the file (so it won't grow too large). This size could just be changed to become message's size and the check just changed to assume metadata size would be e.g. 512 bytes. It won't really matter in practise. So then the reading code could get the message's size from the index. Single-dbox doesn't have such index. There are two ways to solve the problem there (both actually would work for multi-dbox too): 1) Metadata block can be found by reading backwards from end of file. For example read the last 512 bytes of the file and find the metadata magic block. Get the message's size from there. 2) Create an istream that simply reads until it reaches dbox metadata magic and unique separator. And to be absolutely sure it reached the correct end of message, it can also check that the rest of the data in the stream contains only a valid metadata block.

8 28