February 2010 - dovecot

[Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
by Timo Sirainen 12 Mar '10

12 Mar '10

This is something I figured out a few months ago, mainly because this one guy at work (hi, Stu) kept telling me my multi-master replication plan sucked and we should use some existing scalable database. (I guess it didn't go exactly like that, but that's the result anyway.) So, my current plan is based on a couple of observations: * Index files are really more like memory dumps. They're already in an optimal format for keeping them in memory, so they can be just mmap()ed and used. Doing some kind of translation to another format would just make it more complex and slower. * I can change all indexing and dbox code to not require any locks or overwriting files. I just need very few filesystem operations, primarily the ability to atomically append to a file. * Index and mail data is very different. Index data is accessed constantly and it must be very low latency or performance will be horrible. It practically should be in memory in local machine and there shouldn't normally be any network lookups when accessing it. * Mail data on the other hand is just written once and usually read maybe once or a couple of times. Caching mail data in memory probably doesn't help all that much. Latency isn't such a horrible issue as long as multiple mails can be fetched at once / in parallel, so there's only a single latency wait. So the high level plan is: 1. Change the index/cache/log file formats in a way that allows lockless writes. 2. Abstract out filesystem accessing in index and dbox code and implement a regular POSIX filesystem support. 3. Make lib-storage able to access mails in parallel and send multiple "get mail" requests in advance. (3.5. Implement async I/O filesystem backend.) 4. Implement a multi-master filesystem backend for index files. The idea would be that all servers accessing the same mailbox must be talking to each others via network and every time something is changed, push the change to other servers. This is actually very similar to my previous multi-master plan. One of the servers accessing the mailbox would still act as a master and handle conflict resolution and writing indexes to disk more or less often. 5. Implement filesystem backend for dbox and permanent index storage using some scalable distributed database, such as maybe Cassandra. This is the part I've thought the least about, but it's also the part I hope to (mostly) outsource to someone else. I'm not going to write a distributed database from scratch.. This actually should solve several issues: * Scalability, of course. It'll be as scalable as the distributed database being used to store mails. * NFS reliability! Even if you don't care about any of these alternative databases, this still solves NFS caching problems. You'd keep using the regular POSIX FS API (or async FS api) but with the in-memory index "cache", so only a single server is writing to mailbox indexes at the same time. * Shared mailboxes. The filesystem API is abstracted, so it should be possible to easily add another layer to handle accessing other users' mails from both local and remote servers. This should finally make it possible to easily support shared mailboxes with system users.

17 82

[Dovecot] Dovecot 2.0.beta3: mdbox mailbox crashes upon login
by Thomas Leuxner 04 Mar '10

04 Mar '10

Hi, converted my personal mailbox from 'maildir' to 'mdbox' for testing today: # dsync convert -u user@domain mdbox:~/mdbox Set mail location to mdbox in 'mail.conf' and restarted server: mail_location = mdbox:~/mdbox Dovecot panicked instantly upon login with different clients. Tried to disable several plugins to no avail: Feb 28 14:43:02 spectre dovecot: imap(user@domain): Panic: file mailbox-list-fs.c: line 170 (fs_list_get_path): assertion failed: (mailbox_list_is_valid_pattern(_list, name)) Feb 28 14:43:02 spectre dovecot: imap(user@domain): Raw backtrace: /usr/lib/dovecot/libdovecot.so.0 [0x7f0a0d891e72] -> /usr/lib/dovecot/libdovecot.so.0 [0x7f0a0d891eda] -> /usr/lib/dovecot/libdovecot.so.0(i_error+0) [0x7f0a0d892283] -> /usr/lib/dovecot/libdovecot-storage.so.0 [0x7f0a0db2b2c3] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f0a0ccd70c3] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so(acl_mailbox_list_have_right+0x5c) [0x7f0a0ccdadbc] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f0a0ccdb12c] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_list_iter_next+0xa) [0x7f0a0dafc4da] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f0a0ccdaa2a] -> /usr/lib/dovecot/modules/lib01_acl_plugin.so [0x7f0a0ccdb252] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_list_iter_next+0xa) [0x7f0a0dafc4da] -> dovecot/imap [user@domain 84.58.106.99 LIST] [0x40b549] -> dovecot/imap [user@domain 84.58.106.99 LIST](cmd_list_full+0x4e6) [0x40c446] -> dovecot/imap [user@domain 84.58.106.99 LIST] [0x40f9bc] -> dovecot/imap [user@domain 84.58.106.99 LIST] [0x40fa6d] -> dovecot/imap [user@domain 84.58.106.99 LIST](client_handle_input+0x45) [0x40fbe5] -> dovecot/imap [user@domain 84.58.106.99 LIST](client_input+0x62) [0x410622] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0xcb) [0x7f0a0d89c8fb] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x18) [0x7f0a0d89ba78] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f0a0d88be33] -> dovecot/imap [user@domain 84.58.106.99 LIST](main+0x191) [0x418661] -> /lib/libc.so.6(__libc_start_main+0xe6) [0x7f0a0d1191a6] -> dovecot/imap [user@domain 84.58.106.99 LIST] [0x4084e9] Feb 28 14:43:02 spectre dovecot: master: service(imap): child 10202 killed with signal 6 (core dumps disabled) Regards Thomas

2 5

[Dovecot] Possible CPU Denial-Of-Service attack to dovecot IMAP.
by Kostik 03 Mar '10

03 Mar '10

Hello! >> 5. I can provide download link to this buggy mailbox file if needed. > Yes, that would be helpful. I couldn't reproduce it. I hope this will help: http://user.rol.ru/~koc/buggymbox =koc --- Ванкувер 2010. Новости Олимпиады. http://olympic.aport.ru

2 3

[Dovecot] Dovecot 2.0b3 IDLE not advertised
by Bernhard Schmidt 02 Mar '10

02 Mar '10

Hi, I'm not sure whether the client or the server is at fault (probably the client), but it's clearly a regression for me. I'm using the LCG Profimail (http://lonelycatgames.com/?app=profimail) application for my Symbian smartphone which has quite decent IMAP capabilities. Amongst others it can do IMAP IDLE (which has to be statically enabled in the server settings, so it's not used based on the server capabilities). After upgrading from 1.2.10 to 2.0b3 it does not connect anymore. It throws the error message "This server doesn't support IMAP IDLE connection" in my face, even before it tries to authenticate Feb 27 00:46:45 mail dovecot: imap-login: Disconnected (no auth attempts): rip=93.104.73.132, lip=83.170.x.xx, TLS: Disconnected The main difference seems to be that 1.2 advertises IDLE in capabilities before authentication, but 2.0 does not: 1.2: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. o CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC * ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH QUOTA STARTTLS AUTH=PLAIN o OK Capability completed. 2.0: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. o CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN o OK Capability completed. o LOGIN user password * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 * CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA o OK Logged in I know there is the imap_capability setting which might help here, but that looks like a very big hammer. Bernhard

5 8

[Dovecot] What does mailman do with a 'post' command?
by Masaharu Kawada 02 Mar '10

02 Mar '10

Dear list, I am sorry if this question should not be posted here, but I believe that there are many experts of postfix or any other thing such as mailing lists in this list. I am kind of in hurry and need some advices to know about my questions. Could anyone in this list please answer my questions if you know. My questions are about routing work of mailman. As I am not quite fimiliar with the use of mailman, I am sorry if this is a stupid question. One of my customer gets the following log message into /var/log/maillog at around 12:00 every day. ---</var/log/maillog>--- 12:00:04 relay postfix/pickup[6279]: 244811C805C: uid=41 from=<mailman> 12:00:04 relay postfix/cleanup[21529]: 244811C805C: message-id=<20100215030004.244811C805C(a)example.co.jp> 12:00:04 relay postfix/qmgr[20068]: 244811C805C: from=<mailman(a)example.co.jp>, size=1728, nrcpt=1 (queue active) 12:00:04 relay postfix/local[21232]: 244811C805C: to=<mailman(a)example.co.jp>, orig_to=<mailman>, relay=local, delay=0.17, delays=0.05/0/0/0.12, dsn=2.0.0, status=sent (delivered to command: /usr/lib/mailman/mail/mailman post mailman) ---- This message seems that it delivers a command '/usr/lib/mailman/mail/mailman post' to execute against the mailman mailing list, however, the customer never use mailman mailing list on their system. One thing that I doubt is that a cronjob in /etc/cron.d/mailman does something relevant of this because the post time of the messages is always reight after the following work. ---</etc/cron.d/mailman>--- 0 12 * * * mailman /usr/lib/mailman/cron/senddigests or 0,5,10,15,20,25,30,35,40,45,50,55 * * * * mailman /usr/lib/mailman/cron/gate_news --- I'm afraid that I don't have /etc/mailman/aliases file of cutomer's, but by default(in my test env), it should looks like below. </etc/mailman/aliease> # STANZA START: mailman # CREATED: Mon Jan 25 16:48:18 2010 mailman: "|/usr/lib/mailman/mail/mailman post mailman" mailman-admin: "|/usr/lib/mailman/mail/mailman admin mailman" mailman-bounces: "|/usr/lib/mailman/mail/mailman bounces mailman" mailman-confirm: "|/usr/lib/mailman/mail/mailman confirm mailman" mailman-join: "|/usr/lib/mailman/mail/mailman join mailman" mailman-leave: "|/usr/lib/mailman/mail/mailman leave mailman" mailman-owner: "|/usr/lib/mailman/mail/mailman owner mailman" mailman-request: "|/usr/lib/mailman/mail/mailman request mailman" mailman-subscribe: "|/usr/lib/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/usr/lib/mailman/mail/mailman unsubscribe mailman" # STANZA END: mailman My questions are as follows. 1.What exactly is the cause the message in /var/log/maillog? 2.Why does the messages send to mailman(mailman(a)example.co.jp) user even though that mailing list never be used? OS:RHEL5 postfix-2.3.3-2.1.el5_2 mailman-2.1.9-4.el5 Any comments would be greatly appreciated. Best Regards, -- ------------------- Masaharu Kawada Associate Technical Support Engineer Red Hat K K Ebisu Neonato 5F 1-18 Ebisu 4-chome, Shibuya-ku Tokyo 150-0013, Japan Direct: +81-3-5798-8482

4 6

[Dovecot] segfault - (imap|pop3)-login during nessus scan
by Todd Rinaldo 01 Mar '10

01 Mar '10

We've been struggling with a problem for the past couple of days which to this point I've only gotten to be able to boil down to this: 1. Install nessus home edition (less pluggins I assume) 2. run all scans (sequentially or in parallel, doesn't seem to matter) 3. about 3 minutes in /var/log/messages will show segfaults on imap and/or pop3 imap-login[22185]: segfault at 000000000000000c rip 0000003c7de610a2 rsp 00007fffa2342068 error 4 or sometimes... pop3-login[24451]: segfault at 000000000000000c rip 0000003c7de610a2 rsp 00007fff07116968 error 4 I'm having a really hard time getting a core dump and I'm having a really hard time narrowing down the list of nessus tests which cause this. So far, I have repeated this failure in 1.1.19 and 1.1.20 Additionally we've seen something similar on 1.2 and reverted back to 1.1 a year ago. At the time we could not re-produce a test case and finally gave up. Has anyone seen something along these lines? Can anyone recommend how I could narrow this down further so we can find the problem? Thanks, Todd

2 7

[Dovecot] Dovecot 2.0.beta3: Child killed with signal 11
by Thomas Leuxner 01 Mar '10

01 Mar '10

Hi, I'm seeing these after the latest Mercurial updates: ==> /var/log/dovecot.info <== Feb 28 16:07:00 spectre dovecot: master: service(lmtp): child 17322 killed with signal 11 (core dumps disabled) Regards Thomas

3 10

Re: [Dovecot] **OFF LIST** Re: body search very slow since upgrade from 1.0.15 to 1.2.10
by Stan Hoeppner 28 Feb '10

28 Feb '10

Stan Hoeppner put forth on 2/24/2010 12:17 AM: > Timo Sirainen put forth on 2/23/2010 11:06 PM: >> No, body searches aren't indexed (without fts plugins). I wish you'd have mentioned the Squat plugin earlier Timo. I feel I've made a fool of myself. I just setup squat and after a long first search on that 50MB, 11K+ messages mbox file, every search after the first has taken less than 5 seconds, most only 2 seconds. It's performing exactly as I'd like. It's amazing. I didn't ever setup any fts plugins on 1.0.15. I'm left wondering how body searches were so fast if I didn't have an fts plugin configured. Anyway, setting up Squat on 1.2.10 sure solved the long search time problem. :) Thanks for the help Timo! -- Stan

4 16

[Dovecot] any limitations running on a Mac?
by Terry Barnum 28 Feb '10

28 Feb '10

I have postfix/dovecot/mysql installed using MacPorts on a quad-core 2.8GHz MacPro running Snow Leopard (10.6.2). I moved the base mail directory to a pair of 10k RPM Raptors that are mirrored (/Volumes/email/) and everything seems to be working fine on an unused domain with very little traffic. I used imapsync to pull everything from the current mailserver to this test server to play with. Our current mailserver's IMAP performance *really* suffers when an IMAP folder exceeds ~500MB or ~5k messages. I've become very tired of being the mailbox police trying to get my 20 users to delete email or divide into smaller mailboxes. Are there folks on the list running postfix/dovecot on similar Mac hardware that can share their experiences? Specifically, are there any limitations (file descriptors, other?) that can impact performance I should be aware of? How does dovecot on the Mac deal with >500GB maildirs? Is there a recommended tool for loading and testing the server? Postal? I have 20 IMAP users, with a total of ~37GB of mail currently. Thanks for any help and insight. -Terry Terry Barnum digital OutPost San Diego, CA http://www.dop.com 800/464-6434

6 14

[Dovecot] Possible CPU Denial-Of-Service attack to dovecot IMAP.
by Kostik 28 Feb '10

28 Feb '10

Hi All! Some time ago, we received e-mail message, which makes our server CPU exhaustion attack. --- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26319 5751796 20 0 2868 1868 1484 R 99.2 0.1 22:04.77 imap --- It happens when I try open mail folder with this buggy message. Our setup: -- slackware 11.0, x86_32 -- linux 2.6.31.6 -- dovecot 1.2.10 -- mailbox(not maildir) via NFS storage. Details: 1. Buggy message 1219733 byte size. And most of this size is mail header. 2. Mail header mostly consists of a repeating block: --- [...] MIME-Version: 1.0 Content-type: text/plain; charset=windows-1251 Content-transfer-encoding: 8bit Date: Thu, 25 Feb 2010 11:13:03 +0300 X-Priority: 0 X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Sender: torrents(a)rutracker.org Reply-to: torrents(a)rutracker.org From: torrents(a)rutracker.org Message-ID: <4052c9f301d0956f3fa1e855cca02d39(a)rutracker.org> [...] MIME-Version: 1.0 Content-type: text/plain; charset=windows-1251 Content-transfer-encoding: 8bit Date: Thu, 25 Feb 2010 11:13:02 +0300 X-Priority: 0 X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Sender: torrents(a)rutracker.org Reply-to: torrents(a)rutracker.org From: torrents(a)rutracker.org Message-ID: <6162ed30245a86b8cb26e4a0bf4de562(a)rutracker.org> [...] --- 3.strace show, that dovecot many-many time do: --- pread64(6, "-Sender: torrents(a)rutracker.org\n"..., 4038, 814845) = 4038 pread64(6, "s(a)rutracker.org\nMessage-ID: <461"..., 4083, 818883) = 4083 pread64(6, "arset=windows-1251\nContent-trans"..., 4068, 822966) = 4068 pread64(6, "ail-Priority: Normal\nX-Mailer: M"..., 4091, 827034) = 4091 --- 4. and gdb in that time: --- (gdb) where #0 0xb7604060 in memset () from /lib/tls/libc.so.6 #1 0x080d7483 in buffer_write (_buf=0x8131db0, pos=135470571, data=0x8132d52, data_size=2) at buffer.c:54 #2 0x080d74fb in buffer_append (buf=0x0, data=0x8132d52, data_size=2) at buffer.c:168 #3 0x080cebfe in read_header (mstream=0x8131be8) at istream-header-filter.c:214 #4 0x080cef07 in i_stream_header_filter_read (stream=0x8131be8) at istream-header-filter.c:301 #5 0x080cef79 in parse_header (mstream=0x8131be8) at istream-header-filter.c:323 #6 0x080cefce in i_stream_header_filter_seek (stream=0x8131be8, v_offset=128810, mark=false) at istream-header-filter.c:337 #7 0x080ddfdb in i_stream_seek (stream=0x8131c10, v_offset=128810) at istream.c:198 #8 0x0809c99c in i_stream_mail_stats_read_mail_stats (stream=0x812c460) at istream-mail-stats.c:43 #9 0x080ddbfc in i_stream_read (stream=0x812c488) at istream.c:85 #10 0x080de389 in i_stream_read_data (stream=0x812c488, data_r=0xbf9d82e4, size_r=0xbf9d82e8, threshold=2) at istream.c:366 #11 0x080d400b in message_get_header_size (input=0x812c488, hdr=0x81298fc, has_nuls=0x0) at message-size.c:56 #12 0x0808f976 in index_mail_init_stream (mail=0x81297d0, hdr_size=0xbf9d83b0, body_size=0xbf9d8390, stream_r=0x0) at index-mail.c:852 #13 0x080838a1 in mbox_mail_get_stream (_mail=0x81297d0, hdr_size=0xbf9d83b0, body_size=0xbf9d8390, stream_r=0xbf9d838c) at mbox-mail.c:322 #14 0x0808e9ac in index_mail_get_virtual_size (_mail=0x81297d0, size_r=0xbf9d8400) at index-mail.c:397 #15 0x080685a3 in fetch_rfc822_size (ctx=0x0, mail=0x81297d0, context=0x0) at imap-fetch-body.c:894 #16 0x0806607c in imap_fetch_more (ctx=0x811e030) at imap-fetch.c:472 #17 0x0805e370 in cmd_fetch (cmd=0x811dec8) at cmd-fetch.c:228 #18 0x0806292b in cmd_uid (cmd=0x811dec8) at cmd-uid.c:27 #19 0x08063726 in client_command_input (cmd=0x811dec8) at client.c:612 #20 0x080636d1 in client_command_input (cmd=0x811dec8) at client.c:661 #21 0x080638b3 in client_handle_input (client=0x811cc08) at client.c:701 #22 0x080642d6 in client_input (client=0x811cc08) at client.c:753 #23 0x080e1bf1 in io_loop_handler_run (ioloop=0x0) at ioloop-epoll.c:208 #24 0x080e0f79 in io_loop_run (ioloop=0x8119ab0) at ioloop.c:335 #25 0x0806c21a in main (argc=3, argv=0xbf9d86b4, envp=0xbf9d86c4) at main.c:327 --- 5. I can provide download link to this buggy mailbox file if needed. =koc

2 1