SMTP with GMail fails with out of memory error in 7.69.1 (works OK in 7.68.0)

[RMerl]

I did this

curl -s -S -4 -v --interface eth0 \
--ssl-reqd \
--url smtp://smtp.gmail.com:587 \
--mail-auth "user@gmail.com" \
--user "user@gmail.com:MyPassword" \
--mail-from "user@gmail.com" \
--mail-rcpt "user@gmail.com" \
--upload-file /jffs/mail.txt

I expected the following

After the early authentication bits, this is a successful session under 7.68.0:

(snip)
< 235 2.7.0 Accepted
} [5 bytes data]
> MAIL FROM:<user@gmail.com> AUTH=user@gmail.com SIZE=135
{ [5 bytes data]
< 250 2.1.0 OK i127sm4454764qkc.93 - gsmtp
} [5 bytes data]
> RCPT TO:<user@gmail.com>
{ [5 bytes data]
< 250 2.1.5 OK i127sm4454764qkc.93 - gsmtp
} [5 bytes data]
> DATA
{ [5 bytes data]
< 354  Go ahead i127sm4454764qkc.93 - gsmtp
} [5 bytes data]
* We are completely uploaded and fine
} [5 bytes data]
< 250 2.0.0 OK  1587760481 i127sm4454764qkc.93 - gsmtp
* Connection #0 to host smtp.gmail.com left intact

However with 7.69.1, it returns this:

(snip)
< 235 2.7.0 Accepted
} [5 bytes data]
> QUIT
{ [5 bytes data]
< 221 2.0.0 closing connection h13sm2593942qti.32 - gsmtp
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
curl: (27) Out of memory

1. Instead of jumping into the MAIL FROM portion, it immediately issues QUIT
2. As the process exits, it reports an Out of memory.

mail.txt contains a very short test file with a From, To,Date, and two lines of content.

This might be server-specific, as my own ISP's server seems to work fine with a similar request.

curl/libcurl version

curl 7.69.1 (arm-unknown-linux-gnu) libcurl/7.69.1 OpenSSL/1.0.2u
Release-Date: 2020-03-11
Protocols: file ftp ftps http https imap imaps pop3 pop3s smb smbs smtp smtps
Features: HTTPS-proxy IPv6 Largefile NTLM SSL TLS-SRP UnixSockets

operating system

Asuswrt-Merlin (Linux-based router firmware).

Tested both on an older uclibc+kernel 2.6.36 and on a glibc+kernel 4.1.51 kernel.

OpenSSL 1.0.2u is used for the SSL/TLS backend.

[RMerl]

I updated the reported OpenSSL version - I incorrectly specified OpenSSL 1.1.1, but I had forgotten that I have curl linked against 1.0.2u for technical reasons.

[RMerl]

Potential cause?

aeb2923#diff-65cc11e82be15630f137b0476644a46b

I will see if I can resolve the issue by reverting this change. BRB...

[RMerl]

Nope, that wasn't it. Will require more digging through changes between 7.68.0 and 7.69.1.

[bagder]

Maybe bisect? Or possibly single-step with a debugger to find which condition that is triggered.

[john9527]

Maybe another possibility
2d137de

[RMerl]

Completed bisect, first bad commit is 68fb25f .

[jay]

Check your encoding

/cc @captain-caveman2k

[RMerl]

Issue tracked down and fixed here (been looking at it with bagder over IRC).