Hi Andy,

Thank you for your bug report.

Daniel has asked me to take a look at this and respond as I tend to look after the email protocols in curl.

There was a fix in 7.24 for the issue you are describing:

POP3: detect when LIST returns no mails

However, it concerns me that the email server you are using seems to be sending you a tab character in the response.

The missing final CRLF that Graeme mentions was also fixed in 7.25:

POP3: Fixed drop of final CRLF in EOB checking

Byte stuffing is a technique used by email server to escape the characters which could be interpreted as an end of email. As such, an email server will send .. instead of . when the full stop (period) character could be interpreted as the end of email. Equally when we send an email to a server, via SMTP, we have to do the same byte stuffing so the server doesn't see the character sequence as the end of the email ;-) This isn't something you need to worry about as curl takes care of this for you.

Have you tried upgrading to a later version of curl? I would recommend 7.26 or later for POP3 operation due to a number of POP3 issues fixed in 7.24, 7.25 and 7.26 as well as support for addition POP3 commands.

However, because of the security advisor that we issued regarding SASL DIGEST-MD5 authentication you might want to use 7.29. Please note there is also an issue introduced in 7.29 which I have fixed for the pending version of 7.30 where curl could hang when performing a LIST on a single message.

Kind Regards

Steve

---
** [bugs:#1211] curl_easy_perform() hangs when receiving an empty list**
**Status:** open
**Created:** Tue Apr 02, 2013 09:08 PM UTC by Andy Wright
**Last Updated:** Tue Apr 02, 2013 09:08 PM UTC
**Owner:** nobody
Date: 2 April 2013
Version: curl 7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Server: pop3s://<myusername>@pop.gmail.com:995
Task: Downloading list of unread messages from Pop3 server using libcurl.
Curl commands and options:
  curl = curl_easy_init();
  curl_easy_setopt(curl, CURLOPT_URL, host.c_str());
  curl_easy_setopt(curl, CURLOPT_USERNAME, user.c_str());
  curl_easy_setopt(curl, CURLOPT_PASSWORD, pwd.c_str());
  curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION , DownloadHandler::execute);
  curl_easy_setopt(curl, CURLOPT_WRITEDATA, &data);
  res = curl_easy_perform(curl);
Handler: Standard format handler, declared as static.
size_t DownloadHandler::execute( void *source , size_t size , size_t nitems , void *userData )
{  
	stringstream* msgout = static_cast<stringstream*>(userData) ;
	char *msgin = static_cast<char*>(source) ;
	const int bufferSize = size * nitems ;
	msgout->write(msgin, bufferSize);
	return bufferSize;
}
Output:
When the Pop3 server has messages, they are successfully downloaded via the handler and control is passed back 
to calling program. However, when there are no messages, the handler receives the following 3 characters - '.' 
'\n' and '\t' and then waits as if expecting more data.
Observations:
I have not inspected the curl source-code. However another developer, Graeme Gill, stated in July 2011 (see 
http://www.mail-archive.com/curl-library@cool.haxx.se/msg09597.html):
>Curl_pop3_write()function [is] not detecting the end of body marker properly.
>
>In curl 7.21.7 it's defined as "\r\n.\r\n", but this assumes
>that there is at least one line of reply in the body to supply
>the first "\r\n". For the LIST command when there are no
>messages, this is not the case, and curl_easy_perform() hangs.
Graeme goes on to state:
>A side effect of this bug is that the final line looses its
>"\r\n" ending.
>
>Another problem is that the byte-stuffed sequence "\r\n.."
>(ie. escaped EOB) is not being un-stuffed.
I must say, I don't quite understand the significance of these last points. From my POV, the first is not an 
issue, as my program never gets access to the content prior to the final line anyway because the curl function 
hangs. I have no idea what byte-stuffing is, but include it for completeness.
The first issue Graeme identifies appears to be the same problem I am experiencing. The only difference is 
that the orphan sequence in my case is .\n\t and not .\r\n as described by Graeme. I am unfamiliar with the 
range of output from mail servers and presume that this is one of the possible variations. In any case, both 
sequences correspond to the standard "dot on a line by its own" control sequence.
I'm guessing that my need for curl to download the list is common to all users of the curl Pop3 routines. I 
use the number of messages in the list to control a loop running calls with the "\1" URL to download messages 
one at a time. If the curl function hangs when the list is empty, it is unusable, and waiting for an 
individual read to fail is too messy to contemplate.
I have temporarily dealt with the issue by having my handler throw an error by returning the wrong number when 
it detects the 3 byte sequence when not preceded by other data. The calling program then treats the error as 
indicating no more messages. This is enough for my purposes at this stage of my project but would obviously not 
be suitable for eventual roll-out.
Naturally, it would be much better if I didn't have to perpetrate this atrocity! If anyone can help Daniel 
with this issue, here is one user who would be extremely grateful!
Andy Wright
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1211/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>