From: Matthias A. <ma...@dt...> - 2004-10-15 14:36:00
|
Brian Candler <B.C...@po...> writes: > On Fri, Oct 15, 2004 at 11:20:28AM +0200, Matthias Andree wrote: >> re-reading Rodolfo's fetchmail hang, it appears as though his POP3 >> server is at fault. >> >> I've looked into the reliability of the SIZE information given by POP3 >> servers, and the first one I checked, qmail-pop3d, failed horribly by >> giving a size that is too short - we cannot use SIZE in POP3 to >> determine how many bytes to read lest we risk reading only part of the >> mail. > > ... and therefore losing command/response synchronisation. Yes, which would be much worse. > The end of a message in POP3 is determined by the sequence "CR LF . CR LF" > and only by that. You are not permitted to perform "LIST n", look at the > size returned, enter "RETR n", read exactly that number of bytes, and expect > to be back in sync with the server at that point. I don't expect such, but qmail hosing the SIZE figures is dangerous if the client allocates a single linear chunk of memory on that basis. qmail is full of warts, DJB doesn't care, but anyways, qmail AFAIK gets the message termination right. I'd asked Rodolfo if it was POP3 that hung and if so, I said his upstream server was broken. We'll see what he can figure next. > qmail-pop3d gives a wrong size because it doesn't count end-of-line as two > bytes; however using the size would not work anyway even if it did, because > lines which start with the termination character use byte-stuffing but don't > count it twice in the size (see RFC1939, section 11) That could be compensated for as the message is read, because it is read line-wise. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |