[Dovecot] New to dovecot, little luck - signal 10 death for imap

[Jeroen Scheerder]

Hi,

I'm a new prospective dovecot user.  I'm planning to migrate a medium-scale 
mail site (a few thousand users) from UW to something better.

I've set up dovecot on a test system.  I can connect and authenticate just 
fine.  IMAP clients get to see the right mailboxes.

However, whenever a mailbox is selected, the imap subprocess dies.

The log shows:

Jul 13 14:52:05 localhost dovecot: imap-login: Login: js [127.0.0.1]
Jul 13 14:52:07 localhost dovecot: child 8082 (imap) killed with signal 10

When I either telnet to it manually or run the "imap" process in a terminal 
window, everything seems to work:

---- Snip ----
* PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT 
LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as js
x select INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags 
permitted.
* 1300 EXISTS
* 0 RECENT
* OK [UNSEEN 2] First unseen.
* OK [UIDVALIDITY 1119092680] UIDs valid
* OK [UIDNEXT 1590] Predicted next UID
x OK [READ-WRITE] Select completed.
x fetch 1 full
* 1 FETCH (FLAGS (\Seen) INTERNALDATE "18-Jun-2005 05:00:02 +0200" 
RFC822.SIZE 1773 ENVELOPE ("Sat, 18 Jun 2005 05:00:01 +0200 (MET DST)" 
"Waarschuwing: uw inbox overschrijdt 80% van de groottelimiet (18-06-2005)" 
(("Super-User" NIL "helpdesk" "phil.uu.nl")) (("Super-User" NIL "helpdesk" 
"phil.uu.nl")) (("Super-User" NIL "helpdesk" "phil.uu.nl")) ((NIL NIL "js" 
"phil.uu.nl")) NIL NIL NIL 
"<20050618030001.B5F3952048 at goedel.admin.phil.uu.nl>") BODY ("text" "plain" 
("charset" "us-ascii") NIL NIL "7bit" 1082 25))
x OK Fetch completed.
x fetch 1 body[text]
* 1 FETCH (BODY[TEXT] {1082}

Beste Jeroen Scheerder,
[...]
Met vriendelijke groet, het systeembeheer.
)
x OK Fetch completed.
x list * *
* LIST (\Noselect \HasChildren) "/" "Archive/"
[...]
* LIST (\Unmarked) "/" "INBOX"
x OK List completed.
---- Snip ----


I'm at a loss here, and no amount of logging or sniffing with tcpdump has 
revealed anything interesting so far.

Does anyone else see these "signal 10" aborts?  Is there any way in which I 
can force a coredump (in case it's *really* a bus error)?


Regards, Jeroen.