jstedfast
commented
10 years ago The correct solution to this is to ignore the octet count and instead keep reading until you get a line that contains only a single '.'.
You can see how I do it in MailKit
Note: When downloading messages via POP3, you ALSO need to unescape lines that begin with 2 periods into a single period.
In other words, if you get a line such as "..some text\r\n", you need to convert it into: ".some text\r\n"
The code I linked above handles all of that.
Sometimes POP-servers report incorrect number of octets. This happens because the email-message can use mixed line breaks (\n and \n\r) in the body. But when the server actually serves the message - it always sends "\n\r" (because this is RFC). This leads to two issues: 1) Message ending not downloaded 2) Next command (for example, "DELE") will not work becasue server is still sending data.
Example: 1) Message is 100 bytes long and has 10 lines. If "\n" are converted to "\r\n" the size would be 110. 1) Server reports 100 octets 2) Client sends RETR 3) Client reads 100 bytes 4) But there's still 10 bytes left unread
I was up all night (testing on several POP servers) and created a "hack-ish" workaround for this... Can send you a pull request if you want me to (it fixes the 2nd issue only - so next commands work)