Caveat(s): I haven't tested this, in fact I don't even know if
the bug exists in the distributed version. I'm running a patched
version, purhaps that's the only one that has the problem.
But it seems likely the the distributed version does as well, so
if someone could test it I'd appreciate it.
According to rfc-1939 ...
RETR msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the message corresponding to the given
message-number, being careful to byte-stuff the termination
character (as with all multi-line responses).
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
Qmail does...
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: \r\n
S: .
The same thing happens with the TOP command.
Here a proposed, untested fix. Note that if the for loop (not
visible below) ever does output anything, it is always terminated
with a \r\n. (You can just see the "put" in the patch) It should
therefore always be safe to just output .\r\n to terminate
the message.
*** ../../dist/qmail-1.03/qmail-pop3d.c Mon Jun 15 03:53:16 1998
--- /tmp/qmail-pop3d.c Wed Jul 21 19:24:26 1999
***************
*** 105,111 ****
put("\r\n",2);
if (!match) break;
}
! put("\r\n.\r\n",5);
flush();
}
--- 105,111 ----
put("\r\n",2);
if (!match) break;
}
! put(".\r\n",3);
flush();
}
--
Aaron Nabil
