Sending an email larger than 65536 bytes results in a server response timeout #18798
Description
I did this
I create a dummy email with 65536 bytes and send this mail with curl. For this demonstration I used the official curl docker image to test different curl versions:
tr -dc '[:alnum:]' </dev/urandom | head -c 65536 > email.txt
docker run --rm -it -v "$PWD:/work" curlimages/curl:latest -vvv -s smtp://smtp.example.com:25 --mail-from [email protected] --mail-rcpt [email protected] --max-time 20 --upload-file /work/email.txt
The mail could be sent:
[...]
ff80: s32m9SKiaz2PuYSBQYzO2QYZ4lBkERSyScaKetCOvny9Z9YwfONkkl5pzwXzShVu
ffc0: rhRYkwZjlYM2SKVhUIaHNCeBbfY1vaNoSehpOyHmpM8egNLinnmv6ZQXw4ST3699
20:16:04.698775 [0-0] == Info: [READ] client_read(len=65536) -> 0, nread=5, eos=1
20:16:04.701930 [0-0] => Send data, 5 bytes (0x5)
0000:
0002: .
20:16:04.704880 [0-0] == Info: upload completely sent off: 65541 bytes
20:16:04.706804 [0-0] == Info: [SMTP] state change from STOP to POSTDATA
20:16:04.768086 [0-0] <= Recv header, 36 bytes (0x24)
0000: 250 2.0.0 Ok: queued as 7B63413B66
20:16:04.768850 [0-0] == Info: [WRITE] [OUT] wrote 36 header bytes -> 36
20:16:04.769313 [0-0] == Info: [WRITE] [PAUSE] writing 36/36 bytes of type 2 -> 0
20:16:04.769866 [0-0] == Info: [WRITE] download_write header(type=2, blen=36) -> 0
20:16:04.776946 [0-0] == Info: [WRITE] client_write(type=2, len=36) -> 0
20:16:04.778861 [0-0] == Info: [SMTP] state change from POSTDATA to STOP
20:16:04.781387 [0-0] == Info: [SMTP] smtp_done(status=0, premature=0) -> 0
20:16:04.782944 [0-0] == Info: [WRITE] [OUT] done
20:16:04.785453 [0-0] == Info: [READ] client_reset, clear readers
20:16:04.786531 [0-0] == Info: Connection #0 to host smtp.example.com:25 left intact
I add one byte and send the mail again:
tr -dc '[:alnum:]' </dev/urandom | head -c 65537 > email.txt
docker run --rm -it -v "$PWD:/work" curlimages/curl:latest -vvv -s smtp://smtp.example.com:25 --mail-from [email protected] --mail-rcpt [email protected] --max-time 20 --upload-file /work/email.txt
This time the mail could not be sent and a "server respond timeout" is triggered:
[...]
ff80: OsNSVhSXJWLNzVB9aSqi0fJSiFG5EORzFYhNNZeCW1bj7Y1xhk5a14sgGWp8zbKa
ffc0: eRZjLUKsRiKMmj4aGivie8Tcqre9mO2dQeg3QSPk46YTrCgp5b8GIhM9NkpmLgfe
20:23:07.007799 [0-0] == Info: [READ] cr_in_read(len=1, total=65537, read=65537) -> 0, nread=1, eos=1
20:23:07.010227 [0-0] == Info: [READ] client_read(len=65536) -> 0, nread=1, eos=0
20:23:07.012255 [0-0] => Send data, 1 bytes (0x1)
0000: k
20:23:07.014106 [0-0] == Info: [READ] client_read(len=65536) -> 0, nread=0, eos=1
20:23:07.016047 [0-0] == Info: upload completely sent off: 65537 bytes
20:23:07.017410 [0-0] == Info: [SMTP] state change from STOP to POSTDATA
20:23:24.531480 [0-0] == Info: server response timeout
20:23:24.533028 [0-0] == Info: [SMTP] smtp_done(status=0, premature=0) -> 28
20:23:24.534640 [0-0] == Info: [WRITE] [OUT] done
20:23:24.535307 [0-0] == Info: Connection #0 to host smtp.example.com:25 left intact
The timeout (--max-time) has only been reduced for demonstration purposes. The error also occurs with a much longer timeout (300s).
I expected the following
Mails larger 65536 bytes should be sent correctly.
curl/libcurl version
The latest working version has been curl 8.6.0, all later versions are affected by the bug, e.g. curl 8.14.1-2 in Debian 13 and curl 8.16.0-1~bpo13+1 (trixie-backports).
operating system
Debian 13, Fedora 42/43