- dovecot - dovecot.org

[Dovecot] imap crash
by Todd Burroughs 17 Jun '05

17 Jun '05

This is from the June 16 CVS, it also happens with June 15 but not with June 8. Basically, imap segfaults when opening my mbox. Some details are below: Core was generated by `imap'. Program terminated with signal 11, Segmentation fault. #0 0x08094e5c in message_parse_header_next (ctx=0x80c8e10, hdr_r=0xbffff64c) at message-parser.c:755 755 if (msg[0] == '\n' || (gdb) bt full #0 0x08094e5c in message_parse_header_next (ctx=0x80c8e10, hdr_r=0xbffff64c) at message-parser.c:755 msg = (const unsigned char *) 0x0 i = Variable "i" is not available. (gdb) p *ctx $1 = {line = {name = 0x0, name_len = 0, value = 0x0, value_len = 0, full_value = 0x0, full_value_len = 0, middle = 0x0, middle_len = 0, name_offset = 14794827, full_value_offset = 0, continues = 0, continued = 0, eoh = 0, no_newline = 0, use_full_value = 0}, input = 0x80c9cfc, hdr_size = 0x0, name = 0x80cf030, value_buf = 0x0, skip = 0, skip_initial_lwsp = 0, has_nuls = 0} (gdb) p *hdr_r $2 = (struct message_header_line *) 0x0 (gdb) bt #0 0x08094e5c in message_parse_header_next (ctx=0x80c8e10, hdr_r=0xbffff64c) at message-parser.c:755 #1 0x0806bfaf in mbox_sync_parse_match_mail (mbox=0x80c3ba8, view=0x80c8ea8, seq=2028) at mbox-sync-parse.c:521 #2 0x080689d0 in mbox_file_seek (mbox=0x80c3ba8, view=0x80c8ea8, seq=2028, deleted_r=0xbffff748) at mbox-file.c:164 #3 0x0806a91f in mbox_mail_seek (mail=0x80c9200) at mbox-mail.c:63 #4 0x0806ab2a in mbox_mail_get_stream (_mail=0x80c9200, hdr_size=0x0, body_size=0x0) at mbox-mail.c:176 #5 0x0808cc55 in mail_get_stream (mail=0xfffffffe, hdr_size=0x0, body_size=0x0) at mail.c:106 #6 0x080760ef in index_mail_get_header_stream (_mail=0x80c9200, _headers=0x80c95d8) at index-mail-headers.c:606 #7 0x0808cc31 in mail_get_header_stream (mail=0xfffffffe, headers=0x80c95d8) at mail.c:97 #8 0x080769d0 in index_storage_search_next (_ctx=0x80c9188, mail=0x80c9200) at index-search.c:492 #9 0x0808d525 in mailbox_search_next (ctx=0x0, mail=0x80c9200) at mail-storage.c:405 #10 0x08057bee in cmd_search (cmd=0x80bcb98) at cmd-search.c:33 #11 0x080594f5 in _client_input (context=0x80bcb58) at client.c:334 #12 0x0809e1ca in io_loop_handler_run (ioloop=0x80bb9b0) at ioloop-poll.c:184 #13 0x0809d8e9 in io_loop_run (ioloop=0x80bb9b0) at ioloop.c:218 #14 0x080603e7 in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at main.c:228

2 1

[Dovecot] dovecot.index.cache 1/3rd of INBOX size
by Chris Wakelin 17 Jun '05

17 Jun '05

I've noticed that my dovecot.index.cache file has got very large (24MB, which is more than 1/3 of my INBOX size). I've tried deleting (well, renaming) the dovecot.index.* files, and re-opening my INBOX, and the new dovecot.index.cache is only 90KB so far. I'm using dovecot-1.0-stable and mbox format. My mail_cache_fields and mail_never_cache_fields are set to the default. Looking back in the list archives, I found a message from Timo that suggested the cache entries are created for each message when the indexes are created, rather than when each message is accessed, so it ought not to grow? What happens when a message is deleted? I "strings/grep" ed through the dovecot.index.cache file and it looks like it's not caching any headers it shouldn't (like Received, X-Spam-XYZ etc.), but they seem to occur multiple times for each message. None of my other dovecot testers seem to have huge cache files (yet!). Anybody else seen this? Best Wishes, Chris -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin(a)reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094

3 4

[Dovecot] Compressed maildir
by Curtis Maloney 17 Jun '05

17 Jun '05

Greetings, I noticed a while back someone posted a patch/plugin that allowed Dovecot to use compressed mbox files. I'm now wondering how far that would put us from having compressed maildir? I have a server with more CPU than disk space, and while I can buy more HDD space, my backup solution doesn't make that practical. It seems to me that when looking for a message file, if it ends in .gz unpack it, and otherwise everything acts as normal. Worst case, this is one strcat() and a stat() slower to find. Newly delivered messages could remain unpacked, and a cron job could come by whenever to compress old/large/un-looked-at-for-months messages. So, new and frequently referenced messages would be as fast as ever, and older messages would be slower. I would love to dive in an do this myself, but 1- my time is very very limited, working two jobs, and 2- I'm not running 1.0 yet, as it apparently still doesn't support my Thunderbird users tagging their messages (am I wrong? please tell me I'm wrong... I want to upgrade! :) -- Curtis Maloney cmaloney(a)cardgate.net

10 15

[Dovecot] SSHA with LDAP?
by Ben Beuchler 16 Jun '05

16 Jun '05

Poking around in the code for dovecot-stable seems to indicate that support has been added for the {SSHA} password scheme. This is not reflected in dovecot-ldap.conf. Is the SSHA code actually functional? Thanks! -Ben

2 2

[Dovecot] small dovecot problem
by Cor Bosman 16 Jun '05

16 Jun '05

Hi all, just noticed a small problem in test70. If you have an mail in your maildir 'new' directory, and use another method to delete that email (for instance pop it through another pop server), dovecot will continue to report that email as being on the server. So if you had 1 email, delete it through pop, dovecot will continue to say that 1 email is on the server, even if you disconnect/reconnect. If that same email is in the 'cur' dir (so its been read), this doesnt happen and dovecot will report 0 emails. Cor

2 1

[Dovecot] Dovecot and openmailadmin ?
by albi＠scii.nl 16 Jun '05

16 Jun '05

hi, wondered whether some people tried dovecot and openmailadmin ? http://www.openmailadmin.org "openMailAdmin is a little administration interface to IMAP mailservers." "openMailAdmin works with most of the popular MTAs, such as Postfix or Sendmail, and with almost every complete IMAP-server, i.e. Cyrus or Courier" a google-search didn't show any useful results so far, i'm just curious whether some people already tried it with dovecot (of course i can try it myself, but quite busy currently)

1 0

[Dovecot] customflags and keywords
by Curtis Maloney 16 Jun '05

16 Jun '05

OK. After checking the 0.99->1.0 migration documentation, it seems I've been a little confused between customflags and keywords. (Though this is partly due to my repeated requests for clarification being ignored.) The page (http://wiki.dovecot.org/moin.cgi/UpgradingDovecot) says 1.0 does not use .customflags any more. Now, I'm hoping they're still supported, in which case I'm curious to know where those details ARE stored? If 1.0 does support custom flags in a usable way, I'll migrate next week (with Andrey's gzip patch applied :) -- Curtis Maloney cmaloney(a)cardgate.net

2 1

Re: [Dovecot] strip realms and force lowercasing of usernames?
by Timo Sirainen 16 Jun '05

16 Jun '05

On Tue, 2005-06-14 at 03:16 -0700, Dan Hollis wrote: > > PAM module only works for PAM passdb, Dovecot still does userdb lookup > > from /etc/passwd or wherever you have it. > > PAM should be given a chance to modify the username dovecot uses to do the > userdb lookup with. Hmm. I remembered PAM wouldn't allow that, but looks like it does. Changed CVS version to support that now (non-tested though, but doesn't at least break the normal behavior).

3 5

[Dovecot] strip realms and force lowercasing of usernames?
by Dan Hollis 15 Jun '05

15 Jun '05

Is it possible for dovecot to strip realms and force lowercasing of usernames? We have a lot of dumb customers who try logging in to pop3 with crap like UsERNAmE and bla(a)nonexistentdomain.com. All our usernames are lowercase and we have no realms. Trying to get hundreds of customers to fix this is hard and is a significant and costly support burden. It would be nice if dovecot could handle this in some way. -Dan

8 14

[Dovecot] 1.0-test73
by Timo Sirainen 15 Jun '05

15 Jun '05

http://dovecot.org/test/ Two potentially dangerous changes: - mbox parser should now be able to handle CR+LF linefeeds. Hopefully doesn't break anything. - Some mail header parser changes. Hopefully doesn't break anything. And other stuff: - COPY shouldn't crash anymore with 64bit systems - If PAM modifies username, keep it - When auth workers died they leaked file descriptors in dovecot-auth - Auth workers were leaking memory for each request - Make MySQL connect abort in 10 seconds if it can't connect - 32bit UID/GIDs were truncated to 31bit value - dovecot-auth reports cache hits and misses on SIGUSR2

3 4