dovecot - Mar 2003 - problem with COPY?

hi all,

I've been trying to use dovecot (from cvs 03.mar.2003, linux 2.2.20,
gcc 2.96, openssl 0.9.7a) as an replacement for uw-imap, and it seems
to be doing its job, except for one thing:

I have my mua (sylpheed-claws from cvs) set up so that it will sort
message into certain(imap) directories. so when I check the mail in the
INBOX, new mails will be processed automatically and, for example spamcop
related emails are moved to their own 'folder'. imap session below.

[STARTTLS and LOGIN stuff not included... no errors whatsoever there.]

[18:06:39] IMAP4< 5 OK Logged in.
[18:06:39] IMAP4> 6 SELECT INBOX
[18:06:40] IMAP4< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
[18:06:40] IMAP4< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen
\Draft \*)] Flags permitted.
[18:06:40] IMAP4< * 49 EXISTS
[18:06:40] IMAP4< * 3 RECENT
[18:06:40] IMAP4< * OK [UNSEEN 47] First unseen.
[18:06:40] IMAP4< * OK [UIDVALIDITY 1046109663] UIDs valid
[18:06:40] IMAP4< * OK [UIDNEXT 64] Predicted next UID
[18:06:40] IMAP4< 6 OK [READ-WRITE] Select completed.
[18:06:40] IMAP4> 7 UID SEARCH UID 1:*
[18:06:40] IMAP4< * SEARCH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 49 52 55 56
57 58 61 62 63
[18:06:40] IMAP4< 7 OK Search completed.
[18:06:40] IMAP4> 8 STATUS INBOX (MESSAGES RECENT UIDNEXT UIDVALIDITY
UNSEEN)
[18:06:40] IMAP4< * STATUS "INBOX" (MESSAGES 49 RECENT 3 UIDNEXT 64
UIDVALIDITY 1046109663 UNSEEN 3)
[18:06:40] IMAP4< 8 OK Status completed.
[18:06:40] IMAP4> 9 UID FETCH 61:63 (UID FLAGS RFC822.SIZE
BODY.PEEK[HEADER.FIELDS (Date From To Cc Newsgroups Subject Message-Id
References In-Reply-To Content-Type Seen Status X-Status From)])
[18:06:40] IMAP4< * 47 FETCH (UID 61 FLAGS (\Recent) RFC822.SIZE 3111
BODY[HEADER.FIELDS (DATE FROM TO CC NEWSGROUPS SUBJECT MESSAGE-ID
REFERENCES IN-REPLY-TO CONTENT-TYPE SEEN STATUS X-STATUS FROM)]
{322}
[18:06:40] IMAP4< * 48 FETCH (UID 62 FLAGS (\Recent) RFC822.SIZE 3111
BODY[HEADER.FIELDS (DATE FROM TO CC NEWSGROUPS SUBJECT MESSAGE-ID
REFERENCES IN-REPLY-TO CONTENT-TYPE SEEN STATUS X-STATUS FROM)]
{322}
[18:06:40] IMAP4< * 49 FETCH (UID 63 FLAGS (\Recent) RFC822.SIZE 3109
BODY[HEADER.FIELDS (DATE FROM TO CC NEWSGROUPS SUBJECT MESSAGE-ID
REFERENCES IN-REPLY-TO CONTENT-TYPE SEEN STATUS X-STATUS FROM)]
{322}
[18:06:40] IMAP4< 9 OK Fetch completed.
[18:06:40] IMAP4> 10 STATUS Spamcop (MESSAGES RECENT UIDNEXT UIDVALIDITY
UNSEEN)
[18:06:40] IMAP4< * STATUS "Spamcop" (MESSAGES 14 RECENT 0 UIDNEXT
51 UIDVALIDITY 1046109859 UNSEEN 0)
[18:06:40] IMAP4< 10 OK Status completed.
[18:06:40] IMAP4> 11 UID COPY 61 Spamcop

now after this, the conenction goes unresponsive and the following appears
in the server log:

Mar  4 18:06:42 btp212 imap(jp): file index-save.c: line 61
(write_with_lf): assertion failed:(size > 0 && size <=
SSIZE_T_MAX)
Mar  4 18:06:42 btp212 dovecot: child 6022 (imap) killed with signal 6

any ideas on what might be causing this? dovecot/mua/some else?

regards,

JP

On Tue, 2003-03-04 at 19:53, JP wrote:
> I have my mua (sylpheed-claws from cvs)
Just a few comments on that first:
> [18:06:39] IMAP4> 6 SELECT INBOX
..
> [18:06:40] IMAP4> 8 STATUS INBOX (MESSAGES RECENT UIDNEXT UIDVALIDITY
> UNSEEN)
It's not considered good behaviour to ask STATUS of selected mailbox,
some (old?) servers will break with that. There's also not much reason
since the client already received everything except UNSEEN as reply to
SELECT.
> [18:06:40] IMAP4> 9 UID FETCH 61:63 (UID FLAGS RFC822.SIZE
> BODY.PEEK[HEADER.FIELDS (Date From To Cc Newsgroups Subject Message-Id
> References In-Reply-To Content-Type Seen Status X-Status From)])
Why is it asking From twice? Why is it asking Status and X-Status at
all? These are likely to be fields internally used by mbox format and
shouldn't be sent client even if it asks it (well, Dovecot does send
them currently, but it will be fixed). I don't know what generates
Seen-field, but I think that doesn't belong to Sylpheed either.
> Mar  4 18:06:42 btp212 imap(jp): file index-save.c: line 61
> (write_with_lf): assertion failed:(size > 0 && size <=
SSIZE_T_MAX)
> Mar  4 18:06:42 btp212 dovecot: child 6022 (imap) killed with signal 6
The message probably hasn't been read yet and Dovecot tries to write
empty Status-header which triggers the assert. Stupid assert, I should
have just ignored if size == 0. Fixed in CVS.