On Thu, Nov 24, 2011 at 05:46:19PM +0000, Steve Holme wrote:
> I think I have found a problem with Curl_pop3_write() when receiving an email
> and was wondered if anyone had any advice on how to fix the issue.
>
> The problem has occurred by chance as I happen to have an email that is 15929
> characters long and either my email server (Microsoft Exchange) and / or the
> network layer of my PC is sending the email and terminating CRLF.CRLF over two
> packets (15931 bytes in the first packet and 3 bytes in the second). If one
> packet was to be received with all the data in it (15934 bytes) then the memcmp
> () for the CRLF.CRLF would succeed as it does for smaller emails and the LIST
> command (assuming the results of the list command aren't 15929 characters long
> as well).
>
> As such, libcurl passes all of the first data chunk down to my write function
> (rather than just the 15929 bytes of the email) and then the final 3 bytes in a
> second call to my write function after it has received the second packet. Given
> this, libcurl never finishes the transfer as it then loops round waiting for
> more data.

This problem has been reported before. Adding the SLOWDOWN keyword to test 811
make it easy to reproduce using the curl test harness. I took a stab
at fixing it some months ago and came up with the attached patch as . first
attempt. It's pretty ugly, but it at least allows this test case to pass.

> It might be best to completely rewrite this logic, similar to what Daniel did
> with the EOB when sending SMTP emails but any recommendations / advise would be
> appreciated as I don't fancy doing 4 extra memory compares.

Agreed. It looked to me like doing some buffering in the ping-ping layer
would be the best way to fix it, but I didn't have time to implement that.
Buffering incoming data there until enough has been received to do a comparison
should make the detection logic much cleaner in the POP-3 code. The state
machine after my patch is too convoluted and also incomplete, as mentioned
in the comments in the patch. Feel free to take this over, as I'm not going to
have any time to look at it any more in the near future.

>>> Dan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html