Sending an email larger than 65536 bytes results in a server response timeout

[madoe]

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 foo@example.com --mail-rcpt bar@example.com  --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 foo@example.com --mail-rcpt bar@example.com  --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

[bagder]

My attempt to reproduce with a test has not succeeded. It uploads ~80K with no problems.

[madoe]

Thanks for taking the time to look into this issue.

This is strange. I tested the issue from multiple sources to three different smtp servers (all running postfix 3.6.4) always with the same results. Could you also not reproduce this issue in a real world scenario outside test cases?

To make matters worse I found out that larger mails CAN be sent out if the upload file contains the closing "\n.\n"-sequence. In your test this sequence seems not to be added to the upload-file, correct?

Using tcptump on the SMTP-server I could verify that on mails <=64kB the closing sequence will be automatically added, but on larger mail the closing sequence is missing - causing the timeout as the mail ist not correcty terminated.

I can provide the dumps if necessary.

[icing]

@madoe, I believe I found the cause for this and made a fix in #19193. Could you verify that in your setting? Thanks.