On Tue, 19 Aug 2014, Jacob Champion wrote:

> [I'm a first-time poster; please correct me if I inadvertently break mailing list
> etiquette.]

Thank you for your post and welcome to the mailing list.

> We're in the middle of a large libcurl upgrade (7.26 to 7.37.1) and we ran into
> bug #1389 [1]: after cURL 7.34, CURLOPT_UPLOAD is now required when
> using SMTP to send mail.

Whilst most people use SMTP to send email, it is a two way protocol that can transfer data from the server to the client (for example: the VRFY, EXPN and HELP commands) as well as from the client to the server. In its infancy the SMTP code was always assuming it was in upload mode, as it only supported the MAIL command during a transfer, whilst most other protocols that upload data to the server require the CURLOPT_UPLOAD flag to be set.

> Unfortunately we have libcurl clients in the wild that relied on the old behaviour
> -- they did not set CURLOPT_UPLOAD -- and while it would be _possible_ to
> upgrade all of them, it would also be prohibitively expensive.

I am right in thinking that you are upgrading your libcurl shared library or dll but not your application that calls it?

> So I have two questions:
>
> 1) Can anyone provide guidance on how we might safely revert this behavior in
> our copy of 7.37.1? We can develop a patchset ourselves, certainly, but I'm hoping
> to get a starting point so that we don't introduce other bugs or go in completely the
> wrong direction.

Hopefully, I can... as I tend to maintain the email protocols here in curl ;-)

You can ensure that smtp_perform() always calls smtp_perform_mail() - a 5 line code change including the comments.

> 2) Does libcurl have a policy on behavioral compatibility? From what I can tell from
> the previous conversations [2] on the topic, the official statement seems to be that
> any SMTP client that wasn't setting CURLOPT_UPLOAD was buggy. I'm fine with that,
> if that's the answer (and we'll be adding CURLOPT_UPLOAD to our new client code).
> But as someone looking in from the outside, it seems like it was sort of a retroactive
> decision -- especially since the libcurl SMTP examples didn't have it either.
>
> Put another way: How do I ensure that our current libcurl client code (HTTP, SMTP, or
> otherwise) does not contain other bugs of this nature, so that we won't break in the
> future because of a missing CURLOPT?

I'm not entirely sure I'm the best person to answer the whole of this question and as such may require Daniel's and others' input for some of this - especially as I've only been involved with curl for 3 years myself.

However, I can say that we try to not break compatibility, this was technically a bug and as such the examples on the website were also at fault :( For example: If you use the curl command line utility with --libcurl to generate sample source code you will note it explicitly calls curl_easy_setopt(hnd, CURLOPT_UPLOAD, 1L) even with versions prior to 7.34.0.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-19