curl POP3 STAT shows 2 minute delay

[ralfjunker]

I did this

curl --request STAT --ssl-reqd -v --insecure -u user:password pop3s://pop.gmx.net

I expected the following

I expect curl to finish immediately, but see a 2 minute delay instead.

This follows up on #14201 (comment), but the actual cause might be unrelated.

Here is the Windows error log.

curl/libcurl version

Windows:

curl 8.9.1 (x86_64-w64-mingw32) libcurl/8.9.1 LibreSSL/3.9.2 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 WinIDN libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.62.1 ngtcp2/1.6.0 nghttp3/1.4.0
Release-Date: 2024-07-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

Debian Bookworm:

curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.13 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u6
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

operating system

Windows 11, Debian Bookworm.

[bagder]

Did this use to work for you in an older version?

[ralfjunker]

No.

On Windows, the oldest version I tested is curl 8.4.0, and the delay is present there as well as all later versions.

On Debian Bookworm I just tested curl 7.88.1, which also has the delay.

I did not test other versions.

[icing]

Looking at the POP3 log, curl just seems to wait for the server to send more lines, whereas 'STAT' only sends a single line back. The 2 minute delay is a timeout at the server that then sends curl a TLS close notify.

RFC 1939 differentiates between multi-line commands, ending with \n.\n and commands that give only a single line. @bagder: I cannot see how pop3.c handles these.

[icing]

I made #14707 as a fix for this.

[bagder]

Just a note on this based on the explanation above: --request was always an option that replaces a command string with another string, without otherwise changing how it behaves.

Thus: --request STAT for POP3 is not a curl bug. It is actually just "wrong use" of curl.

But of course: we might still want to consider supporting this use case so that users actually can send STAT this way.

[ralfjunker]

Thus: --request STAT for POP3 is not a curl bug. It is actually just "wrong use" of curl.

Could you suggest a "correct" use of curl to obtain the result of POP3 STAT?

[bagder]

Could you suggest a "correct" use of curl to obtain the result of POP3 STAT?

I don't believe curl has one.

[bagder]

But with #14707 it should be possible.