http://mailman1.u.washington.edu/pipermail/imap-uw/2005-November/000292.html
http://mailman1.u.washington.edu/pipermail/imap-uw/2005-November/000295.html On 11/14/05, Mark Crispin <[EMAIL PROTECTED]> wrote: > > I agree that the Status: line should always be at the start of a line and > that an extra blank line should not be written if the message has no body. > The attached ipop3d.patch file has both changes, and these changes will > appear in the next imap-2005 development snapshot. > [............] > There will be one minor change: instead of the previous > retr 2 > +OK 10030 octets > Status: RO > > > . > behavior you will now see > retr 2 > +OK 10030 octets > Status: RO > > . > That is, you'll only see one blank line after the Status: line. > > The octet count will continue to be bogus; that came from the IMAP server. [............] > -- Mark -- Thank you for the patch and for your clear explanation. I am sorry for having delayed so long to answer your email. I've thought it is better to only answer after I will have time to apply the patch, and to perform some more tests. I've tried the patch "ported" to imap-2004; i don't know from where to download the development version of imap-2005. A problem with this patch is that k may be 0, 1 or 2 at this line: if (t[k-3] == '\012') So depending on what garbage is in memory I may get: (12 is expunged) retr 12 +OK 531 octets Status: . (notice a line above Status:) I would rather put something like: if ((k==0) || ((k>2) && (t[k-3]=='\012'))) If the header has size 1 or 0 or the body has size 1 the octet count is wrong, even if the imap server doesn't leave holes in the mailbox; I don't see an easy way around it. Such messages are however not valid emails. I hope robust clients will not crash or truncate if they receive some garbage "message" bigger than the expected size, nor timeout if the "message" is smaller. TOP sometimes still gives an extra line for messages with no body. retr 5 +OK 26 octets Status: RO Status: . top 5 0 +OK Top of message follows Status: RO Status: R . top 5 1 +OK Top of message follows Status: RO Status: R . top 5 99999 +OK Top of message follows Status: RO Status: R . retr 4 +OK 247 octets Return-Path: <> Received: from test (localhost [127.0.0.1]) by xx-xx-xx-xxx (Cyrus v2.2.12) with LMTPA; Thu, 16 Jun 2005 21:53:59 +0300 X-Sieve: CMU Sieve 2.2 Date: Thu Message-ID: <[EMAIL PROTECTED]> Status: . top 4 0 +OK Top of message follows Return-Path: <> Received: from test (localhost [127.0.0.1]) by xx-xx-xx-xxx (Cyrus v2.2.12) with LMTPA; Thu, 16 Jun 2005 21:53:59 +0300 X-Sieve: CMU Sieve 2.2 Date: Thu Message-ID: <[EMAIL PROTECTED]> Status: R . top 4 1 +OK Top of message follows Return-Path: <> Received: from test (localhost [127.0.0.1]) by xx-xx-xx-xxx (Cyrus v2.2.12) with LMTPA; Thu, 16 Jun 2005 21:53:59 +0300 X-Sieve: CMU Sieve 2.2 Date: Thu Message-ID: <[EMAIL PROTECTED]> Status: R . Another issue I've found: if i give a bad username/password, ipop3d will try three times to login to the imap server with that bad pair, than close the pop3 connection. It will make more sense to give an pop3 error after every failed imap login attempt (except perhaps when the error is caused by a busy mailbox, or ipop3d only gets readonly access to the imap server); maybe the pop3 client will ask the user for a new user/pass if given the opportunity. Thank you, Adrian Buciuman _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
