- dovecot - dovecot.org

[dovecot] Three *very* strange bugs
by Warren Togami 15 Apr '03

15 Apr '03

* Attached is a mbox file that triggers Bug #1 and #2. * Go here if you want to test dovecot for RH9: https://bugzilla.fedora.us/show_bug.cgi?id=160 * If somebody has a different IMAP server than dovecot, could you please test how Evolution reacts to reading this message? Bug #1 dovecot and #2 evolution-1.2.3 ===================================== I am using dovecot-0.99.9-test3 on RH9, reading mail with evolution-1.2.2-5 on RH9. Whenever I attempt to view this one particular spam message, evolution pops up an error like: Error while 'Retrieving message 4': Server unexpectedly disconnected: No such file or directory Simultaneously this appears in my /var/log/maillog: Apr 15 01:44:50 server dovecot: child 20328 (imap) killed with signal 11 If I attempt to keep reading mail, it logs in again to dovecot and works normally until I attempt to read that spam again. Evolution displays the error popup again though I don't see another signal 11 in maillog. After this point I am unable to log back into dovecot without restarting the daemon. Here's the strange part... I browsed the same IMAP folder from KMail, and kmail has no problem reading that spam message. dovecot's [imap] process does not segmentation fault. Does this mean an evolution bug when reading this particular spam exposed a dovecot segmentation fault? Bug #3 kernel? ============== This is an unrelated bug and perhaps not the fault of dovecot. When I attempted to use strace to get some debugging info on the [imap] process, this happened: [root@server /]# strace -p 20486 trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted detach: ptrace(PTRACE_DETACH, ...): Operation not permitted [root@server /]# This isn't normal right? After doing this, dovecot stops working and I need to restart the daemon in order to establish new connections. That [imap] process becomes unkillable, even kill -9 wont work. Unkillable process usually means kernel bug, right? warren 20345 1 7 01:46 ? 00:00:34 [imap] This is kernel-2.4.20-9 in Red Hat Linux 9. Is dovecot exposing a Red Hat kernel bug when I try to strace that process, or is strace supposed to fail, the dovecot daemon ceases to function and [imap] process becomes completely unkillable? =) Warren Togami warren(a)togami.com

2 1

DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
by Mail System Internal Data 15 Apr '03

15 Apr '03

This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values.

1 0

The Discover(r) Platinum Wildlife Card - Go Wild
by Wild Life 15 Apr '03

15 Apr '03

Offer Expires April 30, 2003 X-Rcpt-To: <warren(a)togami.com> Get a 0% Intro APR* on Purchases and Balance Transfers Youve been selected for a special No-Annual-Fee Discover® Card with all of these privileges: · 0% Intro APR on Purchases and Balance Transfers* · No Annual Fee · Up to 2% Cashback Bonus® award* · Up to $50,000 Credit Limit Start Saving Today APPLY NOW! It's fast, easy and secure. http://ileadmarketing.com/mkt/lead?&l=56217&a=16cc7b&z=57366 To take advantage of this special offer, act by April 30, 2003! * Click here to see information about the APR, fees and other Important Information .................................................................... ILeadMarketing never sends unsolicited email. ILeadMarketing has been given the right to market to you through our Web site partners and their privacy policies. Specifically, you are receiving this correspondence because you have provided consent (via your registration and acceptance of the privacy policies for a newsletter, contest, web-based service or other activity on the web) to receive recurring promotions or offers from various third parties. If you feel that you are receiving this email in error or are not interested in receiving future offers please click here: http://www.ileadmarketing.com/mkt/seeya?email=warren@togami.com&c=57366 , or email us at seeya(a)ileadmarketing.com. ILeadMarketing is not responsible for third party offers, services or products and makes no representations or warranties regarding them. ..................................................................... --=-1kN4J0lqIIqLcGMke0AY--

1 0

[dovecot] dovecot RPM for Red Hat Linux
by Warren Togami 14 Apr '03

14 Apr '03

http://bugzilla.fedora.us/show_bug.cgi?id=160 This .src.rpm is dovecot with RH-specific default settings. I modified Jeremy Katz' dovecot-0.99.8.1 package a bit. When I upgraded from 0.99.8.1 it seemed to be broken until I looked at /var/log/maillog. There it indicated that the dovecot cache files were bad, so I erased /home/*/mail/.imap/ and it seemed to work subsequently. There are a few more RH specific tweaks that I plan on doing for this package. If you have any suggestions to default config tweaks for this package please reply or post in that bugzilla entry above. I would like for this package to be a drop-in replacement for RHL's uw-imapd eventually, but there are a number of migration issues that need to be addressed first. This package will eventually be included in the Fedora tree after it goes through our QA. http://www.fedora.us Fedora Linux is a project of volunteer package developers making 3rd party packages specifically for Red Hat Linux. Warren Togami warren(a)togami.com p.s. Keep up the good work. I absolutely love dovecot!

4 6

[dovecot] Something wrong in SSL ?
by Juha Ylitalo 14 Apr '03

14 Apr '03

Operating system: FreeBSD 4.7-RELEASE-p10 Dovecot: 0.99.8.1 I've used openssl to generate personal CA and I've used that one to generate certificate for my web server. When I tried to go through same pattern for generating certificate for IMAP server from CA, I ended up in situation, where both mutt and evolution keep on rejecting my certificates.

2 2

[Daniel Silverstone <dsilvers@digital-scurf.org>] Re: lua 5.0
by Per Olofsson 13 Apr '03

13 Apr '03

FYI. /Pelle

1 0

[dovecot] Maildir problem?
by Maikel Verheijen 11 Apr '03

11 Apr '03

Hey list, Today I cvs updated to the most recent dovecot, to test with the recent improvements on the dovecot-uidlist file, and came acros the following: Apr 11 12:49:36 pc-5-046 imap(): Corrupted index file (in-memory index for /var/mail/mounted/test.com/maikel/Maildir//.Sent Items): Filename mismatch for UID 1: 1050058115.P3401Q0M675362.pc-5-046.test.nl:2,S vs 1050057888.P3371Q0M138398.pc-5-046.test.nl I am using a front-end back-end construction, But I am testing on the backend only (non-nfs), because the subscriptions file isn't nfs safe yet. shouldn't the uidl files be leading over the indexes? And shouldn't the indexes be updated as well? Thank you, Maikel Verheijen.

1 0

[dovecot] Maildir syncing rewrite
by Timo Sirainen 11 Apr '03

11 Apr '03

It finally seems to be working. I've done some testing now and it seems to be working fine. If you have time, see if you can get it to break (especially with INDEX=memory or by manually modifying the maildir). The UIDs are kept in Courier-compatible dovecot-uidlist file (so "mv courierimapuiddb dovecot-uidlist" should work). The great thing about this code is that we never wait for lock. If we can't lock, we simply use the old uidlist file to sync whatever we can, which should be everything but the very newest mails just being delivered and processed by another Dovecot. Of course, if they share index files, we're still blocking there. I named the file as "dovecot-uidlist" instead of ".uidlist" because I finally realized that files beginning with dot conflict with the mailbox namespace. I should rename .customflags and .subscriptions files as well. Also if I move .imap.index* files into root dir, I'll have to rename them too. new/ directory is now scanned every time to see if there's new mail. cur/ directory is scanned if index file's timestamp differs from cur/ dir's timestamp. uidlist file is reread if it's device/inode changes. You can get the sources from either CVS, or 0.99.9-test2 from http://dovecot.procontrol.fi/test/

3 5

[dovecot] dovecot-0.99.9-test2 probs
by Mark E. Mallett 11 Apr '03

11 Apr '03

Hi- Tried 0.99.9-test2 -- had to go back. Various problems in the log. Here's one: Apr 10 08:56:25 mercury mem[10754]: imap(user0): msync() failed with index data file /users/8b/user0/Maildir/.INBOX/.imap.index.data: Cannot allocate memory Apr 10 08:56:25 mercury mem[10754]: imap(user0): Corrupted index data file /users/8b/user0/Maildir/.INBOX/.imap.index.data: Missing location field for record 156 Apr 10 08:56:25 mercury mem[10754]: imap(user0): msync() failed with index data file /users/8b/user0/Maildir/.INBOX/.imap.index.data: Cannot allocate memory Here's another: Apr 10 18:56:59 mercury mem[13376]: pop3(user1): Corrupted index file /users/30/user1/Maildir/.INBOX/.imap.index: index.next_uid (2365) > uidlist.next_uid (2364) And another: Apr 10 19:09:24 mercury mem[10892]: pop3(user2): Corrupted index file /users/39/user2/Maildir/.INBOX/.imap.index: index.next_uid (10422) > uidlist.next_uid (10420) Apr 10 19:09:24 mercury mem[10892]: pop3(user2): Corrupted index file (in-memory index for /users/39/user2/Maildir): Filename mismatch for UID 1: 1050015983.28176.mercury.mv.net vs 1046192106.460.mercury.mv.net Apr 10 19:09:24 mercury mem[10892]: pop3(user2): No INBOX for user And a ton of these, without any other entry for the process ID (which I assume is the number after "child"): Apr 10 19:09:33 mercury dovecot: child 1645 (imap) killed with signal 11

1 0

[dovecot] compilation errors
by Mark E. Mallett 11 Apr '03

11 Apr '03

Hi- I always encounter the same two minor compilation issues which are easily addressed simply by a quick edit, but this time I figured I'd mention it in case you can work around it. This is on a BSD/OS 4.2 system. First, the generated config.h always creates a definition for OFF_T_MAX which conflicts with the one in the system's limits.h config.h defines: #define OFF_T_MAX LLONG_MAX whereas /usr/include/machine/limits.h defines: #define OFF_T_MAX UQUAD_MAX /* max value for an off_t */ I simply comment out the definition from config.h . Second, in src/lib/mmap-anon.c there's a preprocessor conditional: #if SSIZE_T_MAX >= LLONG_MAX (etc) Unfortunately /usr/include/machine/limits.h defines LLONG_MAX thusly: #define LLONG_MAX (__extension__(9223372036854775807LL)) (evidently to suppress pedantic warnings about the gcc long long constant extension) but the cpp prepreprocessor stumbles over this comparison. This might be fixed in a later gcc, I dunno- it's gcc 2.95.2 here. Yours, -mm-

1 0